From mmox-bounces@ietf.org Tue Feb 3 11:05:20 2009 Return-Path: X-Original-To: mmox-archive@ietf.org Delivered-To: ietfarch-mmox-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D77723A6A4A; Tue, 3 Feb 2009 11:05:20 -0800 (PST) X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7023F3A6AEA for ; Tue, 3 Feb 2009 11:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BG5fCakdC1IS for ; Tue, 3 Feb 2009 11:05:19 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id DC93D3A6A4A for ; Tue, 3 Feb 2009 11:05:16 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 896B93DBC45A for ; Tue, 3 Feb 2009 11:04:57 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: mmox@ietf.org Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 3 Feb 2009 11:04:53 -0800 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] testing... one... two... three... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mmox-bounces@ietf.org Errors-To: mmox-bounces@ietf.org this thing on? check! check! _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Thu Feb 5 11:41:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B79EA3A688B for ; Thu, 5 Feb 2009 11:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwTnny4QgpyS for ; Thu, 5 Feb 2009 11:41:16 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id BFE913A6806 for ; Thu, 5 Feb 2009 11:41:13 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 540C83DBC063 for ; Thu, 5 Feb 2009 11:41:14 -0800 (PST) Message-Id: <710CF99C-5781-478A-BEE9-20F47FBE7ABA@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: mmox@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 11:41:13 -0800 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 19:41:17 -0000 Dear Participants, As we move forward, I thought it would be useful to have some documents to discuss. First off... the objective for this list and for the meeting at the 74th ietf in San Francisco is to a) gauge overall support for the idea of an IETF WG focused on virtual world interoperability and b) identify a few deliverables we should be working towards. In support of this objective, the following draft working group charter has been proposed. This is a copy of what you'll find on the IETF wiki at http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter . Draft Charter for MMOX Working Group The following is a proposed draft charter for the MMO/Virtual World Interchange (MMOX) Working Group. It is important to understand that this is a _draft_ and the authors are currently seeking substantive input from the technical community. The IETF is the right forum for this work because this work will have a close interaction with existing IETF RFCs and STDs, the IETF has a diversity of viewpoints and experience to ensure a successful protocol, and the IETF has a IPR policy suitable to creation of a viable vendor-neutral suite of standards. Therefore, we are requesting a BoF session at IETF 74 to agree on a working group charter. Working Group Name: Massively Multi-participant Online Technologies Chairs: Meadhbh S. Hamrick David Lavine Area and Area Directors: Applications Area Lisa Dussealt Chris Newman Responsible Area Director: Lisa Dussealt Mailing List: mmox@ietf.org 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 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 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 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. 2) OGP Base, a messaging abstraction to support the unique needs of VW interactions. 3) Guidelines for using a PKIX compliant X.509 infrastructure to authenticate protocol endpoints. 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. 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 OGP suite is layered upon a core that is deployable 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: October 2009 Publication of LLSD Draft as an Informational RFC October 2009 Publication of the PKIX Profile for Inter-Simulator Communicaton Draft as an Informational RFC February 2010 Progression of OGP Base and Event Queue to Proposed Standard February 2010 Progression of OGP Virtual World Primitive Object Format to Proposed Standard June 2010 Progression of OGP Authentication to Proposed Standard June 2010 Progression of OGP Teleport to Proposed Standard From infinity@lindenlab.com Thu Feb 5 11:43:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34BB73A688B for ; Thu, 5 Feb 2009 11:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzisJ00JzDNK for ; Thu, 5 Feb 2009 11:43:38 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 6716E3A6806 for ; Thu, 5 Feb 2009 11:43:38 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 158243DBC064 for ; Thu, 5 Feb 2009 11:43:40 -0800 (PST) Message-Id: <184CF214-CE2D-44EC-BC14-C19A205612CC@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: mmox@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-2-5265885 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 11:43:39 -0800 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Agenda) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 19:43:39 -0000 --Apple-Mail-2-5265885 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Continuing with the administrive theme of the previous message... what follows is our draft agenda for a proposed upcoming BoF session @ the 74th IETF meeting in San Francisco, CA. Proposed Agenda: MMO BoF Agenda BoF Chairs: Meadhbh Hamrick David Levine Agenda: 0:00 - 0:10 : Introduction / Blue Sheets / Agenda Bashing 0:10 - 0:20 : Why a New Protocol? 0:20 - 0:30 : What's in the Pipeline? (LLSD, X.509 Profile, OGP Base and Event Queue) 0:30 - 0:40 : IPR Ramifications 0:40 - 0:45 : Relation to Other Standards Efforts 0:45 - 1:15 : LLSD 1:15 - 1:45 : Open Discussion and Q & A 1:45 - 1:50 : Request for YOUR Participation 1:50 - 2:00 : Next Steps --Apple-Mail-2-5265885 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Continuing with the = administrive theme of the previous message... what follows is our draft = agenda for a proposed upcoming BoF session @ the 74th IETF meeting in = San Francisco, CA.

Proposed Agenda:

MMO BoF Agenda

<insert date/time = here>


Meadhbh = Hamrick <infinity@lindenlab.com>
David Levine = <dwl@watson.ibm.com>

Agenda:

0:00 - 0:10 = : = Introduction / Blue Sheets / Agenda Bashing
0:10 - 0:20 : Why a New Protocol?
0:20 - 0:30 : What's in the Pipeline? (LLSD, = X.509 Profile, OGP Base and Event Queue)
= IPR Ramifications
0:40 - 0:45 = : = Relation to Other Standards Efforts
= LLSD
1:15 - 1:45 : Open = Discussion and Q & A
1:45 - 1:50 = : = Request for YOUR Participation
= Next Steps
To: mmox@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 12:01:12 -0800 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] Work Items and Planning Documents for the MMOX BoF session (LLSD Draft) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 20:01:27 -0000 Fortunately our work is not exclusively administrative.. we are also planning on discussing the draft of the Linden Lab Structured Data (LLSD). LLSD is an abstract type system with serializations in common forms (XML, JSON). The objective of LLSD is two-fold. First, it defines the behavior of idealized typed entities so we may discuss objects and data in protocol flow without having to re-define the general semantics in each usage. In other words, we will be proposing future standards that involve "application layer" objects. We would like these object to be typed, and rather than redefining the semantics of what it means to be an integer (or a real, or a URL) in every document, we define them in one place in an unambiguous manner. LLSD also defines serialization formats for these typed application layer objects. This is important as future protocol work should focus on the semantics of the application layer, not details of the presentation. Defining multiple serializations allows those clients which prefer to consume XML to consume XML and those who wish to consume JSON to consume JSON. By defining application layer objects using the abstract type system and then defining serializations for both XML and JSON, we do not need to define the XML DTD or JSON schema for each application layer protocol message. Finally... LLSD also defines an interface description language for describing RESTful accesses to resources. The current draft is available at http://tools.ietf.org/html/draft-hamrick-llsd-00 . Please note that a number of other resources exist describing LLSD, including the wiki page at wiki.secondlife.com at http://wiki.secondlife.com/wiki/LLSD and the LLSD/LLIDL portion of OGP at http://wiki.secondlife.com/wiki/OGP_LLSD_Draft_3 . Please note that these references are NOT normative. That is... the support the definition of LLSD in the draft mentioned above, but in places where they differ, the draft-hamrick-llsd-00 document is considered authoritative. (i.e. - LLSD as defined by the IETF process will be considered canonical.) -Sincerely, -Meadhbh Hamrick From lenglish5@cox.net Thu Feb 5 12:56:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 529BF28C10A for ; Thu, 5 Feb 2009 12:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alJrcUdP65t1 for ; Thu, 5 Feb 2009 12:56:45 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 94CCA28C0F8 for ; Thu, 5 Feb 2009 12:56:45 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090205205646.XNRJ131.fed1rmmtao107.cox.net@fed1rmimpo03.cox.net>; Thu, 5 Feb 2009 15:56:46 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id CLwm1b00K4N6T0Q04Lwn6N; Thu, 05 Feb 2009 15:56:47 -0500 X-Authority-Analysis: v=1.0 c=1 a=tkuCpmoZL20A:10 a=KlMNsXJlHeQA:10 a=Wajolswj7cQA:10 a=yEKG5JRT13E-5BSraaAA:9 a=TTHExHaX4VSVLiT2VOgA:7 a=Qt-Duer6-S_bMwbF3C8iPc7mODoA:4 a=b8hG5vVbyAkA:10 X-CM-Score: 0.00 Message-ID: <498B528E.10001@cox.net> Date: Thu, 05 Feb 2009 13:56:46 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <7DC56E24-8ACA-4A73-A8CD-FF4D50501F7C@lindenlab.com> In-Reply-To: <7DC56E24-8ACA-4A73-A8CD-FF4D50501F7C@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (LLSD Draft) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 20:56:46 -0000 Hey Infinity, I'm getting your messages but not my own. I set the response to the server after I registered and then seent seeral test messages... Hrrrrm.... Lawson (Saijanai) From lenglish5@cox.net Thu Feb 5 13:03:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 269363A6ABB for ; Thu, 5 Feb 2009 13:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orEg3fHJbKuw for ; Thu, 5 Feb 2009 13:03:44 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 789B43A6AC6 for ; Thu, 5 Feb 2009 13:03:44 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090205210345.YBTE131.fed1rmmtao107.cox.net@fed1rmimpo01.cox.net> for ; Thu, 5 Feb 2009 16:03:45 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id CM3l1b00H4N6T0Q03M3mXp; Thu, 05 Feb 2009 16:03:46 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=Dw_zyQOuFIRLHIDzBiAA:9 a=kdDj9g7Ye-OxCjLrcQcCvBm9VwsA:4 a=f-ADshzQSboA:10 X-CM-Score: 0.00 Message-ID: <498B5431.4080605@cox.net> Date: Thu, 05 Feb 2009 14:03:45 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] yet another test X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:03:45 -0000 so maybe its working now? L From infinity@lindenlab.com Thu Feb 5 13:46:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7E333A6AC8 for ; Thu, 5 Feb 2009 13:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvG+7lnTNO1P for ; Thu, 5 Feb 2009 13:46:37 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 2BA843A69E8 for ; Thu, 5 Feb 2009 13:46:37 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id A45033DBC064; Thu, 5 Feb 2009 13:46:38 -0800 (PST) Message-Id: <045F1D41-F152-42EF-B3D2-6F4123B3C806@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: lenglish5@cox.net In-Reply-To: <498B528E.10001@cox.net> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 13:46:38 -0800 References: <7DC56E24-8ACA-4A73-A8CD-FF4D50501F7C@lindenlab.com> <498B528E.10001@cox.net> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (LLSD Draft) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:46:37 -0000 ack. lemme double-check the list is configured for no moderation. fwiw... i did see one test message come through... the "Yet Another =20 Test Message". -cheers -m/=E2=88=9E On Feb 5, 2009, at 12:56 PM, Lawson English wrote: > Hey Infinity, I'm getting your messages but not my own. I set the =20 > response to the server after I registered and then seent seeral test =20= > messages... > > > > Hrrrrm.... > > > Lawson (Saijanai) > From tme@multicasttech.com Thu Feb 5 13:56:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900113A6A31 for ; Thu, 5 Feb 2009 13:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.464 X-Spam-Level: X-Spam-Status: No, score=-103.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr5YrNdUEpNx for ; Thu, 5 Feb 2009 13:56:47 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id A825B3A68B8 for ; Thu, 5 Feb 2009 13:56:47 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14529315; Thu, 05 Feb 2009 16:56:06 -0500 Message-Id: <31943FDC-BB01-41ED-B931-18F83D025CDC@multicasttech.com> From: Marshall Eubanks To: "Meadhbh Hamrick (Infinity)" In-Reply-To: <045F1D41-F152-42EF-B3D2-6F4123B3C806@lindenlab.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 5 Feb 2009 16:56:48 -0500 References: <7DC56E24-8ACA-4A73-A8CD-FF4D50501F7C@lindenlab.com> <498B528E.10001@cox.net> <045F1D41-F152-42EF-B3D2-6F4123B3C806@lindenlab.com> X-Mailer: Apple Mail (2.930.3) Cc: lenglish5@cox.net, mmox@ietf.org Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (LLSD Draft) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 21:56:48 -0000 If you are the moderator go to http://www1.ietf.org/mailman/admin/mmox and see what messages you have. Regards Marshall On Feb 5, 2009, at 4:46 PM, Meadhbh Hamrick (Infinity) wrote: > ack. lemme double-check the list is configured for no moderation. > > fwiw... i did see one test message come through... the "Yet Another =20= > Test Message". > > -cheers > -m/=E2=88=9E > > On Feb 5, 2009, at 12:56 PM, Lawson English wrote: > >> Hey Infinity, I'm getting your messages but not my own. I set the =20 >> response to the server after I registered and then seent seeral =20 >> test messages... >> >> >> >> Hrrrrm.... >> >> >> Lawson (Saijanai) >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From rthayer@secorix.com Thu Feb 5 14:37:28 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C1828C12A for ; Thu, 5 Feb 2009 14:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VB-gIr1NiAE for ; Thu, 5 Feb 2009 14:37:28 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 429F33A6886 for ; Thu, 5 Feb 2009 14:37:28 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so507843wfd.31 for ; Thu, 05 Feb 2009 14:37:29 -0800 (PST) Received: by 10.142.68.5 with SMTP id q5mr579828wfa.12.1233873449454; Thu, 05 Feb 2009 14:37:29 -0800 (PST) Received: from ?10.252.254.102? (m195-163.dsl.rawbw.com [198.144.195.163]) by mx.google.com with ESMTPS id 22sm1942478wfg.20.2009.02.05.14.37.27 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Feb 2009 14:37:28 -0800 (PST) Message-ID: <498B6A26.6070800@secorix.com> Date: Thu, 05 Feb 2009 14:37:26 -0800 From: Rodney Thayer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mmox@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mmox] ping X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 22:37:28 -0000 testing mailing list. wiki mailto URL was mmox@ietf.org, not mmox-request.ietf.org From rthayer@secorix.com Thu Feb 5 18:51:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B02928C14B for ; Thu, 5 Feb 2009 18:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-E5HzZ5AW9q for ; Thu, 5 Feb 2009 18:51:25 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 4621E28C114 for ; Thu, 5 Feb 2009 18:51:25 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so544531rvf.49 for ; Thu, 05 Feb 2009 18:51:26 -0800 (PST) Received: by 10.143.13.17 with SMTP id q17mr678812wfi.222.1233888686095; Thu, 05 Feb 2009 18:51:26 -0800 (PST) Received: from ?10.252.254.102? (m195-163.dsl.rawbw.com [198.144.195.163]) by mx.google.com with ESMTPS id 28sm1724892wfg.11.2009.02.05.18.51.24 (version=SSLv3 cipher=RC4-MD5); Thu, 05 Feb 2009 18:51:25 -0800 (PST) Message-ID: <498BA5A5.2050401@secorix.com> Date: Thu, 05 Feb 2009 18:51:17 -0800 From: Rodney Thayer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mmox@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mmox] CICP - relevant work? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 02:51:26 -0000 Is this relevant to the proposed charter of this WG? It seems to me it would be. http://ask.slashdot.org/article.pl?sid=09/02/04/1934229 (CICP is "a protocol for interacting with virtual worlds", according to this.) Also, I guess there are patents in this space, given the slashdot post. patents and bofs and protocols, oh my... From morgaine.dinova@googlemail.com Thu Feb 5 21:03:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E9E3A6A05 for ; Thu, 5 Feb 2009 21:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.846 X-Spam-Level: X-Spam-Status: No, score=-1.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pH4wGb7eE6CP for ; Thu, 5 Feb 2009 21:03:38 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 535B33A6901 for ; Thu, 5 Feb 2009 21:03:38 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so271197qwe.31 for ; Thu, 05 Feb 2009 21:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=k4HbccSo0ymkgL1523jRzPnDMDElesBBc1jBHmG0x8Q=; b=ivHD3FnuyI+dSCHr6yPNbPRPIm+FNVLofHhKIRH6625rTxx9i2Zf31zDqE09jDSx1K KA9eFS4ls9j06j80WLGCpt2VHKm5F7YvAtyQTl6GwH5t2wDDY8/1ZHhotjXD6y/e75Mk +8wrBNX3bgPVRVgMdlswkW8uZ8z4U3o6IE7NE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=VikM6i0gDlsjcqmJt5MIJdjcAsdNgqrJ4hrYV/lN1YpzyAhZnTg5Qrw2oI4zP8tzhl xOub0Ez4Jg8rZP200k+FbpsZJSniXDSsLNxIjtb2ZcrQv3upTlfJueJvN/vl7GOqKcHA gcYet/y34V4iQyi/f2aeyqgJqzRAL56BZViIE= MIME-Version: 1.0 Received: by 10.214.44.9 with SMTP id r9mr2010373qar.290.1233896618728; Thu, 05 Feb 2009 21:03:38 -0800 (PST) In-Reply-To: <498BA5A5.2050401@secorix.com> References: <498BA5A5.2050401@secorix.com> Date: Fri, 6 Feb 2009 05:03:38 +0000 Message-ID: From: Morgaine Dinova To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015175cb938a61dd3046238f1da Subject: Re: [mmox] CICP - relevant work? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 05:03:39 -0000 --0015175cb938a61dd3046238f1da Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 6, 2009 at 2:51 AM, Rodney Thayer wrote: > Is this relevant to the proposed charter of this WG? It seems to me it > would be. > > http://ask.slashdot.org/article.pl?sid=09/02/04/1934229 > > (CICP is "a protocol for interacting with virtual worlds", according to > this.) > It would certainly seem to be relevant, Rodney. Even though we don't yet have an official charter in MMOX, we all know that we're here to lay the ground for interoperation of virtual worlds beyond just Second Life and its clones. Indeed, that's why this work has been placed under the aegis of the IETF, to provide a vendor-neutral and flexible, extensible protocol for interop so that it applies to the needs of others as well. Defining an SL-specific protocol would be quite out of order here. We will benefit hugely from collaboration with and input from the developers of other virtual worlds and world systems. Judging from the Project Darkstar materials, their infrastructure will be underpinning many a virtual world (Wonderland is just one), as they seem to have targetted problem areas that Second Life currently addresses poorly, such as certain areas of scalability. I hope that we can gain buy-in from the CICP and MXP people, as well as from Wonderland developers and from the core Darkstar project as well, and others. The usual recommendation of "two reference implementations" will be more meaningful in the context of a protocol for world interop when the worlds in question are not clones. :-) Morgaine. --0015175cb938a61dd3046238f1da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 6, 2009 at 2:51 AM, Rodney T= hayer <rthayer@= secorix.com> wrote:
Is this relevant to the proposed charter of this WG?  It seems to me i= t
would be.

http://ask.slashdot.org/article.pl?sid=3D09/02/04/1934229<= br>
(CICP is "a protocol for interacting with virtual worlds", accord= ing to
this.)

It would certainly seem to be relevant, Rodney.

Even though we don't yet have an official charter in MMOX, we all know that we're = here to lay the ground for interoperation of virtual worlds beyond just Second Life and its clones.  Indeed, that's why this work has been placed under the aegis of the IETF, to provide a vendor-neutral and flexible, extensible protocol for interop so that it applies to the needs of others as well.  Defining an SL-specific protocol would be quite out of order here.

We will benefit hugely from collaboration with and input from the developers of other virtual worlds and world systems.  Judging from th= e Project Darkstar materials, their infrastructure will be underpinning many a virtual world (Wonderland is just one), as they seem to have targetted problem areas that Second Life currently addresses poorly, such as certain areas of scalability.

I hope that we can gain buy-in from the CICP and MXP people, as well as from Wonderland developers and from the core Darkstar project as well, and others.  The usual recommendation of "two reference implementations" will be more meaningful in the context of a protocol for world interop when the worlds in question are not clones. :-)

Morgaine.

--0015175cb938a61dd3046238f1da-- From adam@deepthink.com.au Thu Feb 5 21:28:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA5F3A6971 for ; Thu, 5 Feb 2009 21:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wacINZEzZ7ny for ; Thu, 5 Feb 2009 21:28:41 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 4685A3A6979 for ; Thu, 5 Feb 2009 21:28:35 -0800 (PST) Received: from ntxedgeus01.exchange.xchg (ntxedgeus01.lxa.perfora.net [172.23.130.34]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1LVJGV3CAe-0007NP; Fri, 06 Feb 2009 00:28:36 -0500 Received: from ntxhubus02.exchange.xchg (172.23.130.33) by ntxedgeus01.exchange.xchg (172.23.130.34) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 6 Feb 2009 00:21:00 -0500 Received: from winxbeus19.exchange.xchg ([172.23.130.79]) by ntxhubus02.exchange.xchg ([172.23.130.33]) with mapi; Fri, 6 Feb 2009 00:28:34 -0500 From: "Frisby, Adam" To: "mmox@ietf.org" Date: Fri, 6 Feb 2009 00:28:17 -0500 Thread-Topic: MXP Protocol for SceneGraph Descriptions Thread-Index: AcmIG7dWdwHPFSyURDya9VUP1JnOEw== Message-ID: <63FAD4F222230A4EA79DE9E8BE664735055FC848@winxbeus19.exchange.xchg> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_63FAD4F222230A4EA79DE9E8BE664735055FC848winxbeus19excha_" MIME-Version: 1.0 X-Provags-ID: V01U2FsdGVkX1/bjXcBHDe4FUC//pidHTcatOyWtYwWUdQBmWz EuzsnKzKy3lhG+0Q0oUrApatyjsNZQnIMssjcz2Bz6kOFJFci Subject: [mmox] MXP Protocol for SceneGraph Descriptions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 05:30:54 -0000 --_000_63FAD4F222230A4EA79DE9E8BE664735055FC848winxbeus19excha_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Has MXP been looked at for incorporation into the MMOX proposal as a method= of describing SceneGraph updates? In a large number of respects it is similar to the UDP object update transp= ort employed by Second Life(tm), however is also a good degree simpler, and= does not carry the burden of the 500+ message types currently transported = over that protocol. I would probably suggest some updates to allow a TCP tr= ansport mechanism for 'reliable' updates, and also perhaps UDP multicasting= . There is a reference implementation of the draft protocol on http://www.bub= blecloud.org and some experiments going on at integrating it into OpenSimul= ator (source forthcoming). Regards, Adam --_000_63FAD4F222230A4EA79DE9E8BE664735055FC848winxbeus19excha_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Has MXP been looked at for incorporation into the MMOX proposal as a method of describing SceneGraph updates?

 

In a large number of respects it is similar to the UDP object update transport employed by Second Life™, however is also a g= ood degree simpler, and does not carry the burden of the 500+ message types currently transported over that protocol. I would probably suggest some upd= ates to allow a TCP transport mechanism for ‘reliable’ updates, and = also perhaps UDP multicasting.

 

There is a reference implementation of the draft proto= col on http://www.bubblecloud.org and s= ome experiments going on at integrating it into OpenSimulator (source forthcomi= ng).

 

Regards,

 

Adam

--_000_63FAD4F222230A4EA79DE9E8BE664735055FC848winxbeus19excha_-- From john.hurliman@intel.com Thu Feb 5 23:48:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D9C33A6B6B for ; Thu, 5 Feb 2009 23:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNwBmrWtPaRj for ; Thu, 5 Feb 2009 23:48:21 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 78B513A6985 for ; Thu, 5 Feb 2009 23:47:31 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 05 Feb 2009 23:41:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.37,390,1231142400"; d="scan'208";a="384578478" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga002.jf.intel.com with ESMTP; 05 Feb 2009 23:56:30 -0800 Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by rrsmsx603.amr.corp.intel.com (10.31.0.57) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 6 Feb 2009 00:47:33 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Fri, 6 Feb 2009 00:47:32 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Fri, 6 Feb 2009 00:47:29 -0700 Thread-Topic: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) Thread-Index: AcmHybmLgJVPpprFR6yCAEpko8OvPQAXgH4w Message-ID: <62BFE5680C037E4DA0B0A08946C0933D4FDFBA77@rrsmsx506.amr.corp.intel.com> References: <710CF99C-5781-478A-BEE9-20F47FBE7ABA@lindenlab.com> In-Reply-To: <710CF99C-5781-478A-BEE9-20F47FBE7ABA@lindenlab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 07:48:23 -0000 As it is written, the charter and timeline effectively subverts investigati= on of virtual world platform requirements and the evaluation of different t= echnologies that fulfill those requirements. The charter specifically lists= technology proposals from Linden Lab as established solutions to virtual w= orld interoperability. The goals and milestones section lists a timeline fo= r standardizing those solutions exclusively. I understand the need to trans= ition 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 th= e charter and timeline be changed to ensure the agenda is open to additiona= l proposals. John Hurliman >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Meadhbh Hamrick (Infinity) >Sent: Thursday, February 05, 2009 11:41 AM >To: mmox@ietf.org >Subject: [mmox] Work Items and Planning Documents for the MMOX BoF session >(Draft Charter) > >Dear Participants, > >As we move forward, I thought it would be useful to have some >documents to discuss. > >First off... the objective for this list and for the meeting at the >74th ietf in San Francisco is to a) gauge overall support for the idea >of an IETF WG focused on virtual world interoperability and b) >identify a few deliverables we should be working towards. In support >of this objective, the following draft working group charter has been >proposed. This is a copy of what you'll find on the IETF wiki at >http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter > . > >Draft Charter for MMOX Working Group > >The following is a proposed draft charter for the MMO/Virtual World >Interchange (MMOX) Working Group. It is important to understand that >this is a _draft_ and the authors are currently seeking substantive >input from the technical community. > >The IETF is the right forum for this work because this work will have >a close interaction with existing IETF RFCs and STDs, the IETF has a >diversity of viewpoints and experience to ensure a successful >protocol, and the IETF has a IPR policy suitable to creation of a >viable vendor-neutral suite of standards. Therefore, we are requesting >a BoF session at IETF 74 to agree on a working group charter. > >Working Group Name: >Massively Multi-participant Online Technologies > >Chairs: >Meadhbh S. Hamrick >David Lavine > >Area and Area Directors: >Applications Area >Lisa Dussealt >Chris Newman > >Responsible Area Director: >Lisa Dussealt > >Mailing List: >mmox@ietf.org > >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 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 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 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. >2) OGP Base, a messaging abstraction to support the unique needs of VW >interactions. 3) Guidelines for using a PKIX compliant X.509 >infrastructure to authenticate protocol endpoints. 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. > >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 OGP suite is layered upon a core that is deployable 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: > >October 2009 Publication of LLSD Draft as an Informational RFC >October 2009 Publication of the PKIX Profile for Inter-Simulator >Communicaton Draft as an Informational RFC >February 2010 Progression of OGP Base and Event Queue to Proposed >Standard >February 2010 Progression of OGP Virtual World Primitive Object Format >to Proposed Standard >June 2010 Progression of OGP Authentication to Proposed Standard >June 2010 Progression of OGP Teleport to Proposed Standard > > From morgaine.dinova@googlemail.com Fri Feb 6 01:17:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7BF28C1D7 for ; Fri, 6 Feb 2009 01:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2PUjomg0ior for ; Fri, 6 Feb 2009 01:17:36 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id B8E4728C13C for ; Fri, 6 Feb 2009 01:17:35 -0800 (PST) Received: by qyk4 with SMTP id 4so1060687qyk.13 for ; Fri, 06 Feb 2009 01:17:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SB8+fCFWHUzWumJZcKAO1MlmKFxFV9SRNTI1zauaFkg=; b=YtKz5X8eMhiaQvC1o9Xm/Fe49exqrJ1lfFyvf709v3Og0HryOYHiySPC8jMtyZWjkn hr1LtBQaUcSI9jQdogE1VF7p3RWnSvKImdQFgsc/AMxEH85EdPzMNhCFdrgBCzeMyofs 7muYb03YErSoJc5KatsrvXrSp66ksfEdIqQB4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CGsfqC4aJw4oolhq1mtxToqhFsUm/bIcciJM8+x0iBfY19DNx8NR3jbcB8vMv5iGTT 3lg8mQ5H1s1ffMnoVvnPtKpCuJFlp5BTh1atDGgDUq/5dj8KQaD8fxBgSqOlPgcKAGL+ xZ44R2pOOExIfQIWBDQsZDeXIQJFxVm1Hrl+0= MIME-Version: 1.0 Received: by 10.215.39.16 with SMTP id r16mr2287546qaj.76.1233911856021; Fri, 06 Feb 2009 01:17:36 -0800 (PST) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D4FDFBA77@rrsmsx506.amr.corp.intel.com> References: <710CF99C-5781-478A-BEE9-20F47FBE7ABA@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D4FDFBA77@rrsmsx506.amr.corp.intel.com> Date: Fri, 6 Feb 2009 09:17:35 +0000 Message-ID: From: Morgaine Dinova To: "Hurliman, John" Content-Type: multipart/alternative; boundary=0015175cb24adcc03204623c7db9 Cc: "mmox@ietf.org" Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 09:17:37 -0000 --0015175cb24adcc03204623c7db9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 6, 2009 at 7:47 AM, Hurliman, John 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. --0015175cb24adcc03204623c7db9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 6, 2009 at 7:47 AM, Hurliman= , John <joh= n.hurliman@intel.com> wrote:
As it is written, the charter and timeline effectively subverts investigati= on of virtual world platform requirements and the evaluation of different t= echnologies that fulfill those requirements. The charter specifically lists= technology proposals from Linden Lab as established solutions to virtual w= orld interoperability. The goals and milestones section lists a timeline fo= r standardizing those solutions exclusively. I understand the need to trans= ition 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 th= e charter and timeline be changed to ensure the agenda is open to additiona= l proposals.

John, if the charter, goals and timeline are as you describe, then= I agree with you 100%.  Rubberstamping existing Second Life technolog= y as a standard for virtual worlds would be totally without merit, and endo= rsing 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, b= ecause you will note that the charter is only a draft in expectation of str= ong 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 thi= s 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 inter= operation of diverse virtual worlds, not just now but for several years int= o the future.  That implies extensibility, in breadth and in depth.&nb= sp; 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 b= een 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 ru= sh to establish MMOX.

Let's see how we can improve this.  I think that it's in o= ur court to set the path straight.

Morgaine.
--0015175cb24adcc03204623c7db9-- From morgaine.dinova@googlemail.com Fri Feb 6 02:31:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856543A6BAB for ; Fri, 6 Feb 2009 02:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SunrbSTJqGe for ; Fri, 6 Feb 2009 02:31:40 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 6F8523A6B46 for ; Fri, 6 Feb 2009 02:31:40 -0800 (PST) Received: by qyk4 with SMTP id 4so1080332qyk.13 for ; Fri, 06 Feb 2009 02:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5/0Ng3YkG11i9proP6aSW3RW9Faqe73hsVjH9t+UcBk=; b=JwvVTbTv03LcoVSY8ftO0dHOw2SioJWuqru6SdQ685TgqGL1kSr1dtBABkRDMld+HW oB4IHa/vmvYhFDs1vLT4UNBK1lSpfOHXHJNqoCD5byW++MRPvWlmEwTWIG3zK23stBNz 8lD7YP9NDJc4JKd5QMaaBDHpGiF6g8ODgqyrY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DJpSLhqBxetxKPq+rZB/zEqhZf5lwBO6YYgi7GuQ+tIQwghEbo3UMT+o96f9vM5Sbh etQVOWfWisoI+CJWJnJgNk0gZwXy+Xje91C+za7+RkpFy4uO6Qv+lVDN2DAQElLd3qgy JdxCITfDtdc98nYqbiSw1sc/K2vklCI/iG8PM= MIME-Version: 1.0 Received: by 10.215.41.2 with SMTP id t2mr2319536qaj.371.1233916301019; Fri, 06 Feb 2009 02:31:41 -0800 (PST) In-Reply-To: <710CF99C-5781-478A-BEE9-20F47FBE7ABA@lindenlab.com> References: <710CF99C-5781-478A-BEE9-20F47FBE7ABA@lindenlab.com> Date: Fri, 6 Feb 2009 10:31:40 +0000 Message-ID: From: Morgaine Dinova To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=0015175cb11ece0dc304623d8628 Cc: mmox@ietf.org Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 10:31:41 -0000 --0015175cb11ece0dc304623d8628 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 5, 2009 at 7:41 PM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > ... > October 2009 Publication of the PKIX Profile for Inter-Simulator > Communicaton Draft as an Informational RFC > Let's not get ahead of ourselves here. Simulators are an artifact of Linden Lab's design choice to expose their static mapping of regions onto IP-addressable hardware --- an implementation detail. What's worse, this little implementation detail has resulted in the disastrous lack of region scalability that we suffer in Second Life, which most certainly should not be hardwired into an Internet protocol standard. This potential RFC document was described earlier in the post as "Guidelines for using a PKIX compliant X.509 infrastructure to authenticate protocol endpoints". That is good enough, as endpoints are necessary. What is not necessary is to identify communication endpoints with regions or simulators, when the regions may be virtual. Please defer the naming of publication titles until we have had a chance to iron out the wrinkles. Morgaine. --0015175cb11ece0dc304623d8628 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 5, 2009 at 7:41 PM, Meadhbh = Hamrick (Infinity) <infinity@lindenlab.com> wrote:
...
October 2009    Publication of the PKIX Profile for Inter-Simulat= or Communicaton Draft as an Informational RFC

Let= 's not get ahead of ourselves here.

Simulators are an artifact o= f Linden Lab's design choice to expose their static mapping of regions = onto IP-addressable hardware --- an implementation detail.  What's= worse, this little implementation detail has resulted in the disastrous la= ck of region scalability that we suffer in Second Life, which most certainl= y should not be hardwired into an Internet protocol standard.

This potential RFC document was described earlier in the post as "= Guidelines for using a PKIX compliant X.509 infrastructure to authenticate = protocol endpoints".  That is good enough, as endpoints are neces= sary.  What is not necessary is to identify communication endpoints wi= th regions or simulators, when the regions may be virtual.

Please defer the naming of publication titles until we have had a chanc= e to iron out the wrinkles.

Morgaine.
--0015175cb11ece0dc304623d8628-- From infinity@lindenlab.com Fri Feb 6 02:34:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE37B3A69AF for ; Fri, 6 Feb 2009 02:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCUKtehCC8gF for ; Fri, 6 Feb 2009 02:34:50 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 0B99A3A6BAB for ; Fri, 6 Feb 2009 02:34:50 -0800 (PST) Received: from localhost (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 441C73DBC44B; Fri, 6 Feb 2009 02:34:51 -0800 (PST) Message-ID: From: "Infinity Linden (Meadhbh S. Hamrick)" Date: Fri, 06 Feb 2009 02:34:45 -0800 To: Morgaine Dinova , "Hurliman, John" Content-Type: multipart/mixed; boundary="----8YKJ29FSG4WRDFVAV1TXSAFWR6AFX9" MIME-Version: 1.0 Cc: "mmox@ietf.org" Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 10:34:51 -0000 ------8YKJ29FSG4WRDFVAV1TXSAFWR6AFX9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgSm9obiwgTW9yZ2FpbmUsCgpZZXMuIFNwZWFraW5nIGFzIHRoZSBjby1jaGFpciBvZiB0aGUg Qm9GLCBJIHNoYXJlIHlvdXIgY29uY2VybnMuIFRoZSBkcmFmdCBncm91cCBjaGFydGVyIGlzIGV4 YWN0bHkgdGhhdCwgYSBkcmFmdC4gSSB0aGluayB3ZSBleHBlY3QgaXQgdG8gYmUgbW9kaWZpZWQg YmVmb3JlIHRoZSBXRyBpcyBmb3JtZWQuIFRoZSBkcmFmdCBkb2VzIHRha2UgYSB2ZXJ5IExpbmRl bi1JQk0gcGVyc3BlY3RpdmUgYXMgdGhvc2Ugd2VyZSB0aGUgYXV0aG9ycyBvZiB0aGUgZHJhZnQu IFRoZSBJRVRGIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIFJFUVVJUkVTIGNvbnNlbnN1cywgc28g SSBkb24ndCB0aGluayB3ZSdyZSBleHBlY3RpbmcgYSBydWJiZXItc3RhbXAuCgpCdXQsIHdlIHdv dWxkIGxpa2UgdG8gZ2V0IHBlb3BsZSB0byBzdWJtaXQgY29uY3JldGUgcHJvcG9zYWxzLiBTbyBs ZXQgbWUgYXNrOyBkbyB5b3UgdGhpbmsgeW91IGd1eXMgY291bGQgY29tZSB1cCB3aXRoIHZlcmJp YWdlIHRoYXQgY291bGQgYmUgaW5zZXJ0ZWQgaW50byB0aGUgY2hhcnRlciB0aGF0IHdvdWxkIGFk ZHJlc3MgeW91ciBjb25jZXJucz8gSWYgeW91IGxvb2sgYXQgdGhlIGNoYXJ0ZXJzIG9mIG90aGVy IGdyb3VwcywgeW91J2xsIHNvbWV0aW1lcyBmaW5kIHdvcmRpbmcgaW5kaWNhdGluZyB0aGUgZ3Jv dXAgaGFzIGFuIGV4cGxvcmF0b3J5IG1pc3Npb24gYXMgd2VsbCBhcyBvbmUgdG8gd29yayBvbiBl eHBsaWNpdCBwcm9wb3NhbHMuIEl0IHNvdW5kcyBsaWtlIHlvdSBib3RoIHdvdWxkIGJlIGludGVy ZXN0ZWQgaW4gc3VjaCBsYW5ndWFnZS4gU28sIHBsZWFzZSBzdWJtaXQgY2hhbmdlcyB0byB0aGUg ZHJhZnQgZG9jdW1lbnRzIHlvdSB3aXNoIHRvIGRpc2N1c3MgaGVyZS4gSWYgeW91IHdpbGwgYXR0 ZW5kIHRoZSBtZWV0aW5nIGluIFNhbiBGcmFuY2lzY28sIHRoZXJlJ3Mgc3BhY2UgaW4gdGhlIGFn ZW5kYSBmb3Igb3BlbiBkaXNjdXNzaW9uIGFuZCBRJkEgc2hvdWxkIHlvdXIgY29uY2VybnMgbm90 IGJlIGFkZHJlc3NlZCBvbiB0aGUgbGlzdC4KCldpdGggcmVzcGVjdCB0byBMTFNELCB0aGVyZSBp cyBhIHByZWNlZGVudCBmb3IgaW5jbHVkaW5nIHZlbmRvciBuYW1lcyBpbiB0aGUgbmFtZXMgb2Yg ZHJhZnRzIGFuZCBSRkNzLiBSRkMyNDM3IFBLQ1MjMSA6IFJTQSBDcnlwdG9ncmFwaHkgU3BlY2lm aWNhdGlvbnMgYW5kIFJGQzIwNDAgZGVzY3JpYmluZyB0aGUgUkM1IGNpcGhlciAoUkM1IHN0YW5k cyBmb3IgYm90aCAiUm9uJ3MgQ29kZSA1IiBhbmQgIlJpdmVzdCBDaXBoZXIgNSkKCldlIGJyb3Vn aHQgTExTRCBpbnRvIHRoZSBwdWJsaWMgYXMgcGFydCBvZiBPR1AgYW5kIGFzIGFuIGludGVybmV0 IGRyYWZ0IHNvIHdlIGNvdWxkIGdldCBjb21tZW50cyBmcm9tIHRoZSBpbnRlcm5ldCBjb21tdW5p dHkuIEl0IG1pZ2h0IGJlIGFkdmFudGFnZW91cyBpZiB5b3UgY291bGQgZGVzY3JpYmUgd2hpY2gg cG9ydGlvbnMgb2YgdGhlIExMU0QgZHJhZnQgeW91IHRoaW5rIG5lZWQgbW9kaWZpY2F0aW9uLgoK V2l0aCByZWdhcmRzIHRvIGh5cGVyZ3JpZCwgY2FuIGl0IGJlIHNwZWNpZmllZCBpbiB0aGUgZm9y bSBvZiBhbiBpbnRlcm5ldCBkcmFmdCBhbmQgZGlzY3Vzc2VkIGhlcmU/IElzIHRoZXJlIGEgd2ls bGluZ25lc3MgYnkgaXRzIGF1dGhvcnMgdG8gc3VibWl0IGl0IGFzIGEgc3RhbmRhcmQ/CgpDaGVl cnMhCk1lYWRoYmgKCk1vcmdhaW5lIERpbm92YSA8bW9yZ2FpbmUuZGlub3ZhQGdvb2dsZW1haWwu Y29tPiB3cm90ZToKCj5PbiBGcmksIEZlYiA2LCAyMDA5IGF0IDc6NDcgQU0sIEh1cmxpbWFuLCBK b2huIDxqb2huLmh1cmxpbWFuQGludGVsLmNvbT53cm90ZToNCj4NCj4+IEFzIGl0IGlzIHdyaXR0 ZW4sIHRoZSBjaGFydGVyIGFuZCB0aW1lbGluZSBlZmZlY3RpdmVseSBzdWJ2ZXJ0cw0KPj4gaW52 ZXN0aWdhdGlvbiBvZiB2aXJ0dWFsIHdvcmxkIHBsYXRmb3JtIHJlcXVpcmVtZW50cyBhbmQgdGhl IGV2YWx1YXRpb24gb2YNCj4+IGRpZmZlcmVudCB0ZWNobm9sb2dpZXMgdGhhdCBmdWxmaWxsIHRo b3NlIHJlcXVpcmVtZW50cy4gVGhlIGNoYXJ0ZXINCj4+IHNwZWNpZmljYWxseSBsaXN0cyB0ZWNo bm9sb2d5IHByb3Bvc2FscyBmcm9tIExpbmRlbiBMYWIgYXMgZXN0YWJsaXNoZWQNCj4+IHNvbHV0 aW9ucyB0byB2aXJ0dWFsIHdvcmxkIGludGVyb3BlcmFiaWxpdHkuIFRoZSBnb2FscyBhbmQgbWls ZXN0b25lcw0KPj4gc2VjdGlvbiBsaXN0cyBhIHRpbWVsaW5lIGZvciBzdGFuZGFyZGl6aW5nIHRo b3NlIHNvbHV0aW9ucyBleGNsdXNpdmVseS4gSQ0KPj4gdW5kZXJzdGFuZCB0aGUgbmVlZCB0byB0 cmFuc2l0aW9uIExpbmRlbiBMYWIgcHJvcG9zYWxzIHRvIHN0YW5kYXJkcywgYW5kIEkNCj4+IHN1 cHBvcnQgc3VjaCBhIG1vdmUgYnV0IG5vdCBhdCB0aGUgZXhwZW5zZSBvZiBleGNsdWRpbmcgYWxs IG90aGVyIHBvc3NpYmxlDQo+PiBzb2x1dGlvbnMuIEkgcHJvcG9zZSB0aGF0IHRoZSBjaGFydGVy IGFuZCB0aW1lbGluZSBiZSBjaGFuZ2VkIHRvIGVuc3VyZSB0aGUNCj4+IGFnZW5kYSBpcyBvcGVu IHRvIGFkZGl0aW9uYWwgcHJvcG9zYWxzLg0KPg0KPg0KPkpvaG4sIGlmIHRoZSBjaGFydGVyLCBn b2FscyBhbmQgdGltZWxpbmUgYXJlIGFzIHlvdSBkZXNjcmliZSwgdGhlbiBJIGFncmVlDQo+d2l0 aCB5b3UgMTAwJS4gIFJ1YmJlcnN0YW1waW5nIGV4aXN0aW5nIFNlY29uZCBMaWZlIHRlY2hub2xv Z3kgYXMgYSBzdGFuZGFyZA0KPmZvciB2aXJ0dWFsIHdvcmxkcyB3b3VsZCBiZSB0b3RhbGx5IHdp dGhvdXQgbWVyaXQsIGFuZCBlbmRvcnNpbmcgTEwncw0KPmN1cnJlbnQgdmVyeSBuYXJyb3cgYW5k IHVucHJvdmVuIE9HUCBzb2x1dGlvbiBhcyBUSEUgZnV0dXJlIEludGVybmV0DQo+c3RhbmRhcmQg dW5kZXIgdGhlIGFlZ2lzIG9mIHRoZSBJRVRGIHdvdWxkIGJlIC4uLiB3ZWxsLCBsZXQncyBub3Qg Z28gdGhlcmUuDQo+SXQgd291bGQgY2xlYXJseSBiZSBpbmFwcHJvcHJpYXRlLCBhbmQgdW5oZWxw ZnVsIHRvIHRoZSBkZXZlbG9wbWVudCBvZg0KPnZpcnR1YWwgd29ybGRzLg0KPg0KPkhvd2V2ZXIs IEkgZG8gbm90IGJlbGlldmUgdGhhdCB0aGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoaXMgd29ya2dy b3VwLA0KPmJlY2F1c2UgeW91IHdpbGwgbm90ZSB0aGF0IHRoZSBjaGFydGVyIGlzIG9ubHkgYSBk cmFmdCBpbiBleHBlY3RhdGlvbiBvZg0KPnN0cm9uZyBpbnB1dCBmcm9tIE1NT1ggbWVtYmVycyAo YW5kIE9HUCBpcyBXb3JrIGluIFByb2dyZXNzIGFueXdheSkuICBMZXQncw0KPnByb3ZpZGUgdGhh dCBpbnB1dCBpbW1lZGlhdGVseSwgdG8gcHJldmVudCB0aGlzIHN0YXJ0aW5nIG9mZiBvbiB0aGUg d3JvbmcNCj5mb290Lg0KPg0KPlRoZSBjaGFydGVyIG5lZWRzIHRvIGJlIHBocmFzZWQgdW5hbWJp Z3VvdXNseSB0byBtYWtlIGl0IGNsZWFyIHRoYXQgdGhpcw0KPndvcmtncm91cCBpcyBub3QgYW4g SUVURiBQUiBhbm5leCBvZiBMaW5kZW4gTGFiLCBidXQgdGhhdCBpdCBpcyBkZWRpY2F0ZWQNCj5o b25lc3RseSB0byB0aGUgY3JlYXRpb24gb2YgYSBmbGV4aWJsZSwgdmVuZG9yLWFnbm9zdGljIHBy b3RvY29sIGZvcg0KPmludGVyb3BlcmF0aW9uIG9mIGRpdmVyc2UgdmlydHVhbCB3b3JsZHMsIG5v dCBqdXN0IG5vdyBidXQgZm9yIHNldmVyYWwgeWVhcnMNCj5pbnRvIHRoZSBmdXR1cmUuICBUaGF0 IGltcGxpZXMgZXh0ZW5zaWJpbGl0eSwgaW4gYnJlYWR0aCBhbmQgaW4gZGVwdGguICBBbmQNCj5p dCBpbXBsaWVzIG9wZW5lc3MgdG8gYWx0ZXJuYXRpdmVzLCBhbmQgYSBkZXNpcmUgdG8gZW1icmFj ZSB0aGVtLA0KPg0KPkFuZCBpbiBwYXJ0aWN1bGFyLCBpdCBpbXBsaWVzIGEgZm9jdXMgb24gdGVj aG5pY2FsIG1lcml0IG9mIHNvbHV0aW9ucywgYW5kDQo+bm90IGN1cnJlbnQgYnVzaW5lc3MgaW50 ZXJlc3RzLg0KPg0KPkkgYWdyZWUgdGhhdCB3ZSBhcHBlYXIgdG8gaGF2ZSBiZWVuIGdpdmVuIGEg c2xpZ2h0bHkgcXVlc3Rpb25hYmxlIGJhc2VsaW5lDQo+aW4gTExTRCAoIkxpbmRlbiBMYWIgU3Ry dWN0dXJlZCBEYXRhIiBpcyBoYXJkbHkgYSB2ZW5kb3ItYWdub3N0aWMgbmFtZSkgYW5kDQo+T0dQ IChMaW5kZW4gTGFiJ3Mgb3duIGRldmVsb3BpbmcgcHJvdG9jb2wpIHdpdGhvdXQgYW55IG1lbnRp b24gb2YNCj5hbHRlcm5hdGl2ZSBhcHByb2FjaGVzIGxpa2UgSHlwZXJncmlkIHRoYXQgYXJlIGFs cmVhZHkgaW4gb3BlcmF0aW9uLg0KPkhvd2V2ZXIsIHRoZXNlIHNrZXdzIGFuZCBvbWlzc2lvbnMg YXJlIChJIGJlbGlldmUpIGp1c3QgYXJ0aWZhY3RzIG9mIHRoZQ0KPnJ1c2ggdG8gZXN0YWJsaXNo IE1NT1guDQo+DQo+TGV0J3Mgc2VlIGhvdyB3ZSBjYW4gaW1wcm92ZSB0aGlzLiAgSSB0aGluayB0 aGF0IGl0J3MgaW4gb3VyIGNvdXJ0IHRvIHNldA0KPnRoZSBwYXRoIHN0cmFpZ2h0Lg0KPg0KPk1v cmdhaW5lLg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+bW1veCBtYWlsaW5nIGxpc3QNCj5tbW94QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbW94DQo= ------8YKJ29FSG4WRDFVAV1TXSAFWR6AFX9-- From morgaine.dinova@googlemail.com Fri Feb 6 03:41:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1AA3A6BB0 for ; Fri, 6 Feb 2009 03:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM30dvP-ZRxY for ; Fri, 6 Feb 2009 03:41:11 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 20C3F28B23E for ; Fri, 6 Feb 2009 03:41:11 -0800 (PST) Received: by qyk4 with SMTP id 4so1104109qyk.13 for ; Fri, 06 Feb 2009 03:41:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=hyLLVAjUubu1lSM/zKdLgv/WW7NCbOAtHQYqpU8vqQI=; b=FxKJtpXo8/W1+L0Q3XsCXxm4Nf7x3Onpd2tqZzwPlGXwPn7a6iEXsFBCI+MG+Ic0/G uul5p+pj4gYNep8M9Ppzi9elFTz3BGV6f/vUkiggV4hne8rzk/xSvTTLNuCqeWHxEKjh o6i7Qah5gWpYV50YgwvO9y4GvzUhdxGrvXLFE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JmbppJzeeaoTTrr1OkmdnmC7V9KOeLSANGmK3bvLMQ/gkgm55CBJ5vttIzP7vpTE6v W7VnsQ/bB9nB5ZRZAFLOElH1b7+MQ7WArz3Yiv5NfX13hPbP7t/bxBKOjI2kmv1b656B Lm0anwjwtycvnqXAw94f7EFL4mUS3rk/oqcc8= MIME-Version: 1.0 Received: by 10.215.38.7 with SMTP id q7mr2434494qaj.193.1233920472244; Fri, 06 Feb 2009 03:41:12 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Feb 2009 11:41:12 +0000 Message-ID: From: Morgaine Dinova To: "Infinity Linden (Meadhbh S. Hamrick)" Content-Type: multipart/alternative; boundary=0015175cbabc6de1e704623e7fcb Cc: "mmox@ietf.org" Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 11:41:12 -0000 --0015175cbabc6de1e704623e7fcb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 6, 2009 at 10:34 AM, Infinity Linden (Meadhbh S. Hamrick) < infinity@lindenlab.com> wrote: > 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. Good, that is of course what I was hoping (and expecting) to hear. Let's make sure that the charter reflects our openness and makes our work of value to more parties than just the current participants in the SL ecosystem. 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? Yes, I'll try to help with this. Getting the charter right is largely just a matter of naming the end goal and cutting out SL-specifics. 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) > While the use of "Linden Lab" in the name is not vendor-agnostic and hence might well cause problems of adoption by your competitors (and you cannot seriously be suggesting that LL ranks alongside Rivest!), that is not the key problem with the name, which is the following. LLSD is in current use inside LL/SL, and so it cannot be both that production format and a modified extensible format that we will be refining at the same time. (It may not change, but at this stage we cannot know that.) To use John's form of words in the LLSD context, using this established technology PRECLUDES CHANGE if we find that change is required. After all, it is not within our scope to modify LL's current internal format. Personally I would have avoided the issue by replacing all occurrences of "Linden Lab" by "Open Grid" in this Structured Data spec for MMOX as a sign that the OGP protocol is fully independent of LL, and to avoid any friction with other companies. "Open Grid Structured Data" also happens to fit in with "Open Grid Protocol" like hand in glove. Morgaine. --0015175cbabc6de1e704623e7fcb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 6, 2009 at 10:34 AM, Infinit= y Linden (Meadhbh S. Hamrick) <infinity@lindenlab.com> wrote:
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 R= EQUIRES consensus, so I don't think we're expecting a rubber-stamp.=

Good, that is of course what I was hoping (and expecting) to hear.=   Let's make sure that the charter reflects our openness and makes= our work of value to more parties than just the current participants in th= e SL ecosystem.

But, w= e 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?

Yes, I'll try to help with this.  Getting the charter rig= ht is largely just a matter of naming the end goal and cutting out SL-speci= fics.

On Fri, Feb 6, = 2009 at 5:55 AM, Dr Scofield <DrScofield@xyzzyxyzzy.net> wrote:
hi,

OpenSim has for quite some time now been supporting GridInfo
(http:= //opensimulator.org/wiki/GridInfo) which provides a way of
obtaining grid details such as welcome page, login URI, grid platform
(e.g., SecondLife, OpenSim), etc and use that to automatically configure a client (the Hippo viewer, for example, supports GridInfo, as does the
rezzme protocol handler).

i'd like to propose including this in MMOX.

   dirk

--
dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab<= br> SL: dr scofield ---- drscofiel= d@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/
RL: hud@zurich.ibm.com - +41 44 7= 24 8573 - h= ttp://www.zurich.ibm.com/~hud/

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--0015175cb0368379c204623faf65-- From robla@lindenlab.com Fri Feb 6 10:09:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0ED28C198 for ; Fri, 6 Feb 2009 10:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZsqFXVNgpdy for ; Fri, 6 Feb 2009 10:09:21 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id B39633A689A for ; Fri, 6 Feb 2009 10:09:21 -0800 (PST) Received: from synergy.local (synergy.lindenlab.com [10.1.23.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 958611414001; Fri, 6 Feb 2009 10:09:23 -0800 (PST) Message-ID: <498C7CCE.4040309@lindenlab.com> Date: Fri, 06 Feb 2009 10:09:18 -0800 From: Rob Lanphier User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Morgaine Dinova References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 18:09:22 -0000 On 2/6/09 3:41 AM, Morgaine Dinova wrote: > LLSD is in current use inside LL/SL, and so it cannot be both that > production format and a modified extensible format that we will be > refining at the same time. (It may not change, but at this stage we > cannot know that.) To use John's form of words in the LLSD context, > using this established technology PRECLUDES CHANGE if we find that > change is required. After all, it is not within our scope to modify > LL's current internal format. A common activity in the IETF is work on Informational RFCs, which aren't intended to be standards track proposals, but as formalized specifications of technology already in widespread use. These are especially helpful for things like MIME-type registrations, and provide good reference works for future standards-track specifications. You'll see from the draft that LLSD is being proposed as Informational track. That doesn't preclude the creation of a future specification, also called LLSD, that is a standards track specification, but that's going to be something that the proposed working group can sort out. Given how widely used LLSD is already in several independent implementations, it seems like it's at least worthy of an Informational RFC and a MIME-type registration, no? Rob From lisa.dusseault@gmail.com Fri Feb 6 11:22:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780E428C14E for ; Fri, 6 Feb 2009 11:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.865 X-Spam-Level: X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmMC05BADJQf for ; Fri, 6 Feb 2009 11:22:18 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 1927028C250 for ; Fri, 6 Feb 2009 11:22:17 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so881829rvf.49 for ; Fri, 06 Feb 2009 11:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oUreL7dHNwdoOsx5YrlsxH6zNJBcuoLd9lOXOCGyATk=; b=IjRmJd2EPsavIljawnBcLwNVd0sC5U2g02/PPMN72d+CSMfBTLkIY7qn/eBrtSdL9C JngV+5vpDaxsCmloGHWH/EIEIMxlgQj8CBL7UtyXzq7G0sgilimFeYNlLjR1M88fiNlw evbO0AQQ321Qi5TbeOzkcEpq/n4ZmZfPi/L7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dQcjEZCcXAH0fXAa+/1r0Hg4fyLqV0isGqB92Fgd/783U7pYZmdOkBW1uFtVYw9f2O BPSBPPk/vSP3feWsvYBjSgCi7VYsJbpcqoQ9L+fvRIYUXMEXf7FVyVd4SWlvz0LIvGc3 GUnjZM1Sp4WVnnB7zUS7ThRnWp2GC0InbbC0o= MIME-Version: 1.0 Received: by 10.141.210.2 with SMTP id m2mr1511878rvq.284.1233948139631; Fri, 06 Feb 2009 11:22:19 -0800 (PST) In-Reply-To: References: Date: Fri, 6 Feb 2009 11:22:19 -0800 Message-ID: From: Lisa Dusseault To: Morgaine Dinova Content-Type: multipart/alternative; boundary=000e0cd29bf088b5ba046244f041 Cc: "mmox@ietf.org" Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 19:22:19 -0000 --000e0cd29bf088b5ba046244f041 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm the sponsoring AD for this BOF, and I'm glad to see work on making the charter more generic already. It wasn't clear to me how interested other parties besides Linden Labs were, and what they want, but that's what the BOF process (not just the meeting, but also the mailing list and its charter discussions ) is for. The goal is to figure out The Right Thing to do, and nothing is set in stone yet. The right thing could even be more than one WG, for example. It's worth pointing out very early that the deadline for submitting new Internet-Drafts is March 2, and there's a tradition of only considering material that has been published in Internet-Drafts at IETF meetings. Thus, if there's any other material that can be put in the form of an Internet-Draft and published by March 2, then that document is referenced in the agenda, a lot of IETF people will read that material and be better prepared for this BOF. In particular, people like me who haven't been involved in this area will need a bit more introduction somehow. I actually have read some of this Open Grid stuff before, and yet I'm still struggling with what it means for two nodes to share perceptions of things or to handoff control of virtual objects. What about trust between nodes? What about differences in how things are modeled and what metadata they have? thanks, Lisa On Fri, Feb 6, 2009 at 3:41 AM, Morgaine Dinova < morgaine.dinova@googlemail.com> wrote: > > > On Fri, Feb 6, 2009 at 10:34 AM, Infinity Linden (Meadhbh S. Hamrick) < > infinity@lindenlab.com> wrote: > >> 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. > > > Good, that is of course what I was hoping (and expecting) to hear. Let's > make sure that the charter reflects our openness and makes our work of value > to more parties than just the current participants in the SL ecosystem. > > 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? > > > Yes, I'll try to help with this. Getting the charter right is largely just > a matter of naming the end goal and cutting out SL-specifics. > > 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) >> > > While the use of "Linden Lab" in the name is not vendor-agnostic and hence > might well cause problems of adoption by your competitors (and you cannot > seriously be suggesting that LL ranks alongside Rivest!), that is not the > key problem with the name, which is the following. > > LLSD is in current use inside LL/SL, and so it cannot be both that > production format and a modified extensible format that we will be refining > at the same time. (It may not change, but at this stage we cannot know > that.) To use John's form of words in the LLSD context, using this > established technology PRECLUDES CHANGE if we find that change is required. > After all, it is not within our scope to modify LL's current internal > format. > > Personally I would have avoided the issue by replacing all occurrences of > "Linden Lab" by "Open Grid" in this Structured Data spec for MMOX as a sign > that the OGP protocol is fully independent of LL, and to avoid any friction > with other companies. "Open Grid Structured Data" also happens to fit in > with "Open Grid Protocol" like hand in glove. > > Morgaine. > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --000e0cd29bf088b5ba046244f041 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm the sponsoring AD for this BOF, and I'm glad to see work on mak= ing the charter more generic already.  It wasn't clear to me how i= nterested other parties besides Linden Labs were, and what they want, but t= hat's what the BOF process (not just the meeting, but also the mailing = list and its charter discussions ) is for.  The goal is to figure out = The Right Thing to do, and nothing is set in stone yet.  The right thi= ng could even be more than one WG, for example.

It's worth pointing out very early that the deadline for submitting= new Internet-Drafts is March 2, and there's a tradition of only consid= ering material that has been published in Internet-Drafts at IETF meetings.=   Thus, if there's any other material that can be put in the form = of an Internet-Draft and published by March 2, then that document is refere= nced in the agenda, a lot of IETF people will read that material and be bet= ter prepared for this BOF. 

In particular, people like me who haven't been involved in this are= a will need a bit more introduction somehow.  I actually have read som= e of this Open Grid stuff before, and yet I'm still struggling with wha= t it means for two nodes to share perceptions of things or to handoff contr= ol of virtual objects.  What about trust between nodes?  What abo= ut differences in how things are modeled and what metadata they have?

thanks,

Lisa

On Fri, Feb 6, 20= 09 at 3:41 AM, Morgaine Dinova <morgaine.dinova@googlemail.com> w= rote:


On Fri, Feb 6, 2009 at 10:34 AM, In= finity Linden (Meadhbh S. Hamrick) <infinity@lindenlab.com> wrote:
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 R= EQUIRES consensus, so I don't think we're expecting a rubber-stamp.=

Good, that is of course what I was hoping (and expecting) to= hear.  Let's make sure that the charter reflects our openness and= makes our work of value to more parties than just the current participants= in the SL ecosystem.

But, we would like to get people to submit concrete proposa= ls. So let me ask; do you think you guys could come up with verbiage that c= ould be inserted into the charter that would address your concerns?

Yes, I'll try to help with this.  Getting the chart= er right is largely just a matter of naming the end goal and cutting out SL= -specifics.

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

While the use of "Linden Lab" in the = name is not vendor-agnostic and hence might well cause problems of adoption= by your competitors (and you cannot seriously be suggesting that LL ranks = alongside Rivest!), that is not the key problem with the name, which is the= following.

LLSD is in current use inside LL/SL, and so it cannot be both that prod= uction format and a modified extensible format that we will be refining at = the same time.  (It may not change, but at this stage we cannot know t= hat.)  To use John's form of words in the LLSD context, using this= established technology PRECLUDES CHANGE if we find that change is required= .  After all, it is not within our scope to modify LL's current in= ternal format.

Personally I would have avoided the issue by replacing all occurrences = of "Linden Lab" by "Open Grid" in this Structured Data = spec for MMOX as a sign that the OGP protocol is fully independent of LL, a= nd to avoid any friction with other companies.  "Open Grid Struct= ured Data" also happens to fit in with "Open Grid Protocol" = like hand in glove.

Morgaine.

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--000e0cd29bf088b5ba046244f041-- From tinselsilvera@frontiernet.net Fri Feb 6 11:49:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AFE53A6B4A for ; Fri, 6 Feb 2009 11:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ9wBDhmLNTn for ; Fri, 6 Feb 2009 11:49:38 -0800 (PST) Received: from mx12.roch.ny.frontiernet.net (mx12.roch.ny.frontiernet.net [66.133.183.243]) by core3.amsl.com (Postfix) with ESMTP id A4AB43A6982 for ; Fri, 6 Feb 2009 11:49:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcDADYjjElChbqG/2dsb2JhbACTNbsahBYG Received: from relay01.roch.ny.frontiernet.net ([66.133.182.164]) by mx12.roch.ny.frontiernet.net with ESMTP; 06 Feb 2009 19:49:40 +0000 X-Virus-Scanned: by amavisd-new-2.6.1 at filter05.roch.ny.frontiernet.net Received: from cl05-zms03.roch.ny.frontiernet.net (cl05-host03.roch.ny.frontiernet.net [66.133.186.134]) by relay01.roch.ny.frontiernet.net (Postfix) with ESMTP id 53871AD065 for ; Fri, 6 Feb 2009 19:49:40 +0000 (UTC) Date: Fri, 6 Feb 2009 19:50:00 +0000 (UTC) From: tinselsilvera@frontiernet.net To: mmox@ietf.org Message-ID: <344133581.199671233949800649.JavaMail.root@cl05-host03.roch.ny.frontiernet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [66.133.141.41] X-Mailer: Zimbra 5.0.9_GA_2533.UBUNTU8_64 (zclient/5.0.9_GA_2533.UBUNTU8_64) Subject: Re: [mmox] GridInfo work and re: rezzme URI scheme X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 19:49:39 -0000 I agree that it would be nice to see MMOX add a "GridInfo" type page - it's a quick and easy way to get the info one needs without sorting through a multitude of pages. Great proposal! As for the url's, even though I like the rezzme:// and its very catchy - I don't see that it applies to all virtual worlds so it would seem to exclude those worlds that don't "rezz" in some form or manner. Something more simple and generic like vwtp:// or vwurl's would be more broad and inclusive of all virtual worlds. Tinsel Silvera From jack@martinelli.org Fri Feb 6 12:14:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9694D3A6823 for ; Fri, 6 Feb 2009 12:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nQqFjNJQrAp for ; Fri, 6 Feb 2009 12:14:34 -0800 (PST) Received: from 95228-web1.designerscience.com (unknown [72.32.122.42]) by core3.amsl.com (Postfix) with ESMTP id 60C5F3A67FD for ; Fri, 6 Feb 2009 12:14:34 -0800 (PST) Received: (qmail 29411 invoked from network); 6 Feb 2009 14:14:36 -0600 Received: from localhost (127.0.0.1) by localhost with SMTP; 6 Feb 2009 14:14:36 -0600 Received: from host-206-206-59-29.ns1.spro.net (host-206-206-59-29.ns1.spro.net [206.206.59.29]) by webmail.martinelli.org (Horde MIME library) with HTTP; Fri, 6 Feb 2009 14:14:36 -0600 Message-ID: <20090206141436.kj48j6rfhcgg8kog@webmail.martinelli.org> Date: Fri, 6 Feb 2009 14:14:36 -0600 From: jack@martinelli.org To: mmox@ietf.org References: <498C2777.4090506@xyzzyxyzzy.net> In-Reply-To: <498C2777.4090506@xyzzyxyzzy.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1) Subject: Re: [mmox] rezzme URI scheme: addressing locations/grids (SLURLs are bad, bad, bad) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 20:14:35 -0000 hmmm... my 2 cents... Coordinates are abstract labels. Assigning URI's to world cooddinates =20 adds another layer of abstraction. That a VWURI (virtual world =20 uniform resouce identifier) is a reference to a GridInfo object is a =20 start. Note that URI's on the www have several components and all =20 relate to objects of various MIME types, protocols, (http, https, et. =20 al. ) and addresses within the www. That is, a URI is an address to =20 very specific objects. a SLURL is a generic location in the context =20 defined by SL. There really are two differnt intents to these two =20 very different kinds of references. I am quite certain two kinds of =20 addresses are needed. 1. A Vicinity address that anyone can use as a teleportation =20 destination - like rezzme. 2. An object address that anyone can use to construct a client viewer =20 from. ...with of course new MIME types - like GEOM? and EGEOM for =20 embeded geometry. Imagine a med student entering a patient's ear... =20 visiting an aural nerve .. entering the cytoplasm of the nerve... =20 watching the molecules as they respond to a sound... going in the =20 nerve's nucleus & replaceing a neucleotide or two... watching the =20 results of his genetic surgury. Note that EGEOM's can act as a user =20 defined kind of leveling. (use a psuedo object for outside viewing, =20 and load the contents of the EGEOM for display if inside the object... =20 ala iframe) I have to admit I haven't looked at the GridInfo structure. But it =20 sounds like it describes the content of a sim. I.e., limited to the =20 objects stored at a single CPU. I'd prefer to use a model similar to =20 the WWW where an object may be referenced by a VW page. This idea, for example, turns out to be very useful for load balancing =20 ( see Mod-Rewrite for example) and obviously ... failovers... virtual =20 page construction ala CGI technologies like .asp, .net, .jsp etc... etc. And I am seeing a need to begin a wiki dictionary for this project. I =20 think it might be useful to see the URL for the dictionary at the =20 bottom of each email for this list. here's a few ideas for your darts... HGML -- for Hyper Geometry Markup Language & as a mime type and is a =20 container for other grid objects of various other MIME types. =20 Obviously along the same lines as SGML & XML. VWURI -- for VW mime types (hmmmmm do we really need a new concept =20 for this????) Oh & btw... an HGML page that refers to an object via =20 its coordinates becomes obsolete if the object is moved. Object names =20 ala SL won't work since the names are not unique. So for =20 interoperability objects really do need to be refered to by their =20 GUID's. & so HGML pages then should have UUID's.. so in a sense a =20 GUID becomes similar to an IP. hmmmmm - do I hear a can of worms =20 opening - or an opportunity? (reverse GUID lookup?) OR... should =20 there be relative resource ID's? -- some restrictions may apply eh? =20 This might end up as a requirement. (BTW... where's the requirements document?) VIC -- for vicinity locations that may be used for teleport =20 destinations ala rezzme. VIC might not be good though - I think in =20 Swedish it means %$@#. alternatives (VWC - virtual world coordinates) (TPC - teleport =20 coordinates) (VWL for virtual world location) VWN - virtual world node (rather than sim). VWC - virtual world cluster Sorry I can't write up a document... I don't even have time for this :( BTW - thank you Dr. Scofield. Your post to the group was productive. Quoting Dr Scofield : > i think we need a virtual world independent way of addressing locations > in virtual worlds. Linden Labs did coin the SLURL way of doing this for > the linden lab grid --- unfortunately SLURLs don't allow us to address > locations on other grids, let alone other virtual world platforms (e.g., > OpenSim grids). > > we'd like to propose the rezzme:// URI scheme > (http://xyzzyxyzzy.net/2009/01/07/addressing-places-in-virtual-worldsor-wh= y-slurls-are-bad/) > --- a reference implementation of a rezzme protocol handler is available > (http://forge.opensimulator.org/gf/project/rezzme/). > > we've been using it to address OpenSim grids, Linden Lab main and beta > (and other) grids. the rezzme protocol handler utilizes GridInfo. > > dirk > > -- > dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab > SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/ > RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From cenji.neutra@gmail.com Fri Feb 6 12:24:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124023A6C09 for ; Fri, 6 Feb 2009 12:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PITlQLe5H-gS for ; Fri, 6 Feb 2009 12:24:56 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 7F34D3A6AC5 for ; Fri, 6 Feb 2009 12:24:56 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so156811ywh.49 for ; Fri, 06 Feb 2009 12:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=adDmaJQBcDfydrun+GjvNN7dg7EAU9Z3MeozduscQ1E=; b=cBkSBl7JuaCUeRF4SoDFT3Tm5O75mmivLYWc9KWyP2wdvsD9o3fGDQI9PxCCAFaFu+ JB5Pz2zraGUEqcUeudPpm2gh7bbjwYcfFB4CnarnQ4C6RoSqwf5YIAvMjWL9F6svt0UQ aEL1mBUZOI+CU1/zvDnSpbBRmmsdCAfIUsGqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=qMQ/jGdrOK/uASA/dBO2eaBd986+JRd2Dm2FqFxA1eFMB+CxWjXYPQg2kI0f1C/Ilj WWiAi/RfVfd4GzXEBJD7RMxfuQvLP28rcEUkl7bX69HxJs/vKIcyb5PrOhiuZYT3hub8 1z1KYQKgHStzeSi4gVaTg0Dd2/4fs/SOno1Y4= MIME-Version: 1.0 Received: by 10.143.157.12 with SMTP id j12mr1163474wfo.228.1233951898026; Fri, 06 Feb 2009 12:24:58 -0800 (PST) Date: Fri, 6 Feb 2009 15:24:57 -0500 Message-ID: From: Cenji Neutra To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] rezzme URI scheme: addressing locations/grids (SLURLs are bad, bad, bad) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 20:24:58 -0000 It seems unlikely to me that virtual world implementations of the (moderate) future will include any fixed 1-1 correspondence between named locations used by people and particular geographically distributed simulation processes (if they do, they'll soon give way to the more computationally efficient implementations of their competitors). I think we all know that LLs decision to expose an implementation detail like sims/regions (which correspond to a process responsible for simulating a fixed-size geographic area and the physical objects within it) in the user interface of SL as named regions, was motivated by the trade-off between generality for the future vs expedience and simplicity of development / time-to-market. So, the question is, does a location addressing scheme like (region-name,x,y,z) even belong in such a forward-looking standard? While any virtual world that employs a 2D land-area can have such an addressing scheme overlaid on it, I would think it isn't appropriate to include it at such a low level as to force other implementations into using such a scheme. There exist implementations for which simulation resources are distributed dynamically over the entities that need to be simulated, rather than fixed geographic areas - as in SL, and for which a such a mapping may not be practical to implement or desirable. Obviously, the standards process has to agree on some basic properties of what constitutes the X in MMOX. Is that going to imply some simulated 3D space? If so, perhaps a global x,y,z is all that is needed (and vendors can map vendor-centric schemes over that if desired). If not, and the 'space' is not constrained to physical space analogues at all, then perhaps dictating 'location' addressing schemes is outside the scope? (for example, an application agent space where agents move according to the interaction patterns dictated by the application logic wouldn't fit into a geographic scheme well) My personal preference would be that we limit the scope of the X in MMOX to systems that simulate some analogue of 3D physical space (not necessarily continuous or simply-connected). That way, if location addressing is within the scope, something like a global x,y,z can be used and then vendors can easily map other schemes over that (or not) as desired. -David SL: Cenji Neutra -- Apez - we make your virtual life easier http://www.apez.biz > Date: Fri, 06 Feb 2009 13:05:11 +0100 > From: Dr Scofield > Subject: [mmox] rezzme URI scheme: addressing locations/grids (SLURLs > are bad, bad, bad) > To: mmox@ietf.org > Message-ID: <498C2777.4090506@xyzzyxyzzy.net> > Content-Type: text/plain; charset=ISO-8859-15 > > i think we need a virtual world independent way of addressing locations > in virtual worlds. Linden Labs did coin the SLURL way of doing this for > the linden lab grid --- unfortunately SLURLs don't allow us to address > locations on other grids, let alone other virtual world platforms (e.g., > OpenSim grids). > > we'd like to propose the rezzme:// URI scheme > (http://xyzzyxyzzy.net/2009/01/07/addressing-places-in-virtual-worldsor-why-slurls-are-bad/) > --- a reference implementation of a rezzme protocol handler is available > (http://forge.opensimulator.org/gf/project/rezzme/). > > we've been using it to address OpenSim grids, Linden Lab main and beta > (and other) grids. the rezzme protocol handler utilizes GridInfo. > > dirk > > -- > dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab > SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/ > RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ > From dwl@us.ibm.com Fri Feb 6 12:32:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F69C3A6B2E; Fri, 6 Feb 2009 12:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=-0.941, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpbT9yyBBeF4; Fri, 6 Feb 2009 12:32:25 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id D6D4C3A6AC5; Fri, 6 Feb 2009 12:32:24 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n16KPJrZ011166; Fri, 6 Feb 2009 15:25:19 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n16KWQdX189402; Fri, 6 Feb 2009 15:32:26 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n16KWQWL003427; Fri, 6 Feb 2009 15:32:26 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n16KWQi0003421; Fri, 6 Feb 2009 15:32:26 -0500 To: "mmox@ietf.org" , mmox-bounces@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Fri, 6 Feb 2009 15:32:24 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/06/2009 15:32:25, Serialize complete at 02/06/2009 15:32:25 Content-Type: multipart/alternative; boundary="=_alternative 0070D49B85257555_=" Subject: [mmox] Greetings, MMOX Charter, Scope, Activities.. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 20:32:30 -0000 This is a multipart message in MIME format. --=_alternative 0070D49B85257555_= Content-Type: text/plain; charset="US-ASCII" Greetings, all, quite a few familiar names going by.. For anyone who doesn't keep track of the RL/SL mapping you'll find me in SL under Zha Ewry. (Hey, you never know, someone might not be paying attention.) I'd like to start with some perspective on what I expect out of an IETF Working Group in this space, and then, follow up with several notes on specific issues, one per note. The reason to bring work to the IETF is to help establish it as a usable specification for interop between as large a community as possible. My personal and professional interest in this work, is not to codify the current state of the Linden Lab grid, or to codify the next iteration of that codebase. I think of the goal as parallel to one of the goals of the OpenSim code base itself, establishing a set of specifications from which a broad range of immersive, virtual spaces can be created. If MMOX only addresses the concerns of Linden Lab, or the OpenSim community, or a small set of corporate players, I see little point in the exercise. OpenSim and Linden Lab have different code bases, sometimes strikingly so as the OpenSim community has been creative and original in solving problems. But, both groups share a common heritage, linked by the client, and shaped by Linden Lab's initial design choices. This may well be too narrow to fully engage the larger community. The proposed Charter that Infinity provided, is a starting point for discussion, and the work items are those Linden has offered to the MMOX effort. The point of a BOF, and using the mailing list and developing a charter, is to sort out what the entire community of interest thinks belongs in the charter, the workgroup and the work items. My hope is that we end up with a set of specifications, which define three broad sets of items. Low level encoding and formats specifications, and protocols aimed at building blocks for moving content around. Sets of services, such as Inventory management, asset Storage, Messaging, presence, and so forth, which can be deployed in a wide variety of combinations to get useful effects. finally, there is a set of services centering around that Linden calls a region simulator, which, are in essence, the mechanisms used to manage a shared scene graph. Please note, that the current deployment of these services within the Linden Lab Grid, and on OpenSim grids, is one model for how a scene graph can be shared. The core problem, of accepting control inputs from many sources, creating a stream of updated states and sharing them back out to concerned parties, is, I believe, the nub of the problem. Many variations can be imagined, with more or less detail handled centrally, peer to peer simulations, and largely client side simulations. Our challenge is to capture a set of services and models which lets us describe these various implementation choices at the services and protocol level, and, as much as possible, separate deployment and implementation choices from the interoperable building blocks we define. I strongly encourage everyone to share news of the BOF, and of the proposed working group as widely as possible. While there is a clear danger in boiling the ocean, if we end up with too diverse a set of interests, I think that danger is far less than the danger of creating a small focused set of specifications which don't allow the majority of possible virtual worlds environments to interoperate. Finally, a small word on process and participation. The IETF works by "rough consensus" how rough, and how broad, is somewhat ill defined. It is not unanimity, nor is there a precise measure of what is meant by the phrase. My personal belief is that standards live and die by the ability of the working group to attract sufficient participants to the consensus. Standards which unify multiple approaches and allow a diversity of implementations are of much higher value than ones which codify a single approach, no matter how well they define that approach. The broader a set of participants we attract, and the broader a set of possibilities we enable, the more impact we can have. I don't expect that a successful IETF working group will define a set of specifications which maps exactly to any one implementation. I expect we will, as a community, begin the process of creating a set of shared building blocks from which we can compose many implementations. The balancing acts between generality and efficiency, between learning from the existing code bases, and imagining better ones will be some of the biggest challenge we face. The goal is not a single homogenous grid, but rather defining a broad set of possible virtual spaces, and enabling as fluid and transparent movement between them as we can manage. - David W. Levine ~ Zha Ewry (ISL) --=_alternative 0070D49B85257555_= Content-Type: text/html; charset="US-ASCII"
Greetings, all, quite a few familiar names going by.. For anyone who doesn't keep track of the RL/SL mapping you'll find me in SL under Zha Ewry. (Hey, you never know,
someone might not be paying attention.)

I'd like to start with some perspective on what I expect out of an IETF Working Group in this space, and then, follow up with several notes on specific issues, one per note.

The reason to bring work to the IETF is to help establish it as a usable specification for interop between as large a community as possible. My personal and professional interest in this work, is not to codify the current state of the Linden Lab grid, or to codify the next iteration of that codebase. I think of the goal as parallel to one of the goals of the OpenSim code base itself, establishing a set of specifications from which a broad range of immersive, virtual spaces can be created.  If MMOX only addresses the concerns of Linden Lab, or the OpenSim community, or a small set of corporate players, I see little point in the exercise.
OpenSim and Linden Lab have different code bases, sometimes strikingly so as the OpenSim community has been creative and original in solving problems. But, both groups share a common heritage, linked by the client, and shaped by Linden Lab's initial design choices. This may well be too narrow to fully engage the larger community.

The proposed Charter that Infinity provided, is a starting point for discussion, and the work items are those Linden has offered to the MMOX effort. The point of a BOF, and using the mailing list and developing a charter, is to sort out what the entire community of interest thinks belongs in the charter, the workgroup and the work items.

My hope is that we end up with a set of specifications, which define three broad sets of items. Low level encoding and formats specifications, and protocols aimed at building blocks for moving content around.  Sets of services, such as Inventory management, asset Storage, Messaging, presence, and so forth, which can be deployed in a wide variety of combinations to get useful effects. finally, there is a set of services centering around that Linden calls a region simulator, which, are in essence, the mechanisms used to manage a shared scene graph. Please note, that the current deployment of these services within the Linden Lab Grid, and on OpenSim grids, is one model for how a scene graph can be shared. The core problem, of accepting control inputs from many sources, creating a stream of updated states and sharing them back out to concerned parties, is, I believe, the nub of the problem. Many variations can be imagined, with more or less detail handled centrally, peer to peer simulations, and largely client side simulations. Our challenge is to capture a set of services and models which lets us describe these various implementation choices at the services and protocol level, and, as much as possible, separate deployment and implementation choices from the interoperable building blocks we define.

I strongly encourage everyone to share news of the BOF, and of the proposed working group as widely as possible. While there is a clear danger in boiling the ocean, if we end up with too diverse a set of interests, I think that danger is far less than the danger of creating a small focused set of specifications which don't allow the majority of possible virtual worlds environments to interoperate.

Finally, a small word on process and participation. The IETF works by "rough consensus" how rough, and how broad, is somewhat ill defined. It is not unanimity, nor is there a precise measure of what is meant by the phrase. My personal belief is that standards live and die by the ability of the working group to attract sufficient  participants to the consensus.  Standards which unify multiple approaches and allow a diversity of implementations are of much higher value than ones which codify a single approach, no matter how well they define that approach.  The broader a set of participants we attract, and the broader a set of possibilities we enable, the more impact we can have.

I don't expect that a successful IETF working group will define a set of specifications which maps exactly to any one implementation. I expect  we will, as a community, begin the process of creating a set of shared building blocks from which we can compose many implementations. The balancing acts between generality and efficiency, between learning from the existing code bases, and imagining better ones
will be some of the biggest challenge we face. The goal is not  a single homogenous grid, but rather defining a broad set of possible virtual spaces, and enabling as fluid and transparent movement between them as we can manage.


- David W. Levine
~ Zha Ewry (ISL) --=_alternative 0070D49B85257555_=-- From lenglish5@cox.net Fri Feb 6 13:04:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252B13A6A68 for ; Fri, 6 Feb 2009 13:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9fpjdWF58U8 for ; Fri, 6 Feb 2009 13:04:09 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id F2C4F3A67FC for ; Fri, 6 Feb 2009 13:04:08 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090206210410.OPKN12838.fed1rmmtao103.cox.net@fed1rmimpo03.cox.net>; Fri, 6 Feb 2009 16:04:10 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id Cl481b00U4N6T0Q04l49Me; Fri, 06 Feb 2009 16:04:09 -0500 X-Authority-Analysis: v=1.0 c=1 a=jEABC7uB4WUA:10 a=KlMNsXJlHeQA:10 a=Wajolswj7cQA:10 a=cfHPFXhNAAAA:8 a=48vgC7mUAAAA:8 a=7ckCfXbLQjcrWj39UAoA:9 a=oPvPdOA2hZJQ9o1At3kA:7 a=fUpvn3Okba55v8-4Ivd8k7daeNMA:4 a=oXxgVVfU3OUA:10 a=9xyTavCNlvEA:10 a=x6U5xrJgyBEA:10 a=lZB815dzVvQA:10 a=DLWQtoLnVnAA:10 X-CM-Score: 0.00 Message-ID: <498CA5C8.3090601@cox.net> Date: Fri, 06 Feb 2009 14:04:08 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Lisa Dusseault References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 21:04:10 -0000 Lisa Dusseault wrote: > I'm the sponsoring AD for this BOF, and I'm glad to see work on making > the charter more generic already. It wasn't clear to me how > interested other parties besides Linden Labs were, and what they want, > but that's what the BOF process (not just the meeting, but also the > mailing list and its charter discussions ) is for. The goal is to > figure out The Right Thing to do, and nothing is set in stone yet. > The right thing could even be more than one WG, for example. > > It's worth pointing out very early that the deadline for submitting > new Internet-Drafts is March 2, and there's a tradition of only > considering material that has been published in Internet-Drafts at > IETF meetings. Thus, if there's any other material that can be put in > the form of an Internet-Draft and published by March 2, then that > document is referenced in the agenda, a lot of IETF people will read > that material and be better prepared for this BOF. > > In particular, people like me who haven't been involved in this area > will need a bit more introduction somehow. I actually have read some > of this Open Grid stuff before, and yet I'm still struggling with what > it means for two nodes to share perceptions of things or to handoff > control of virtual objects. What about trust between nodes? What > about differences in how things are modeled and what metadata they have? > Those are hot-button questions, Lisa, due to the "live" economy that Second LIfe uses. There's been more discussions on those topics than anything else, I suspect. Here's an index to most of the discussions I'm aware of about these topics: https://wiki.secondlife.com/wiki/AW_Groupies#Chat_Logs key words: permissions, perms, IP, intellectual property, content creation, content creators, inventory, assets, copybot... See alsp: https://wiki.secondlife.com/wiki/Category:AW_Groupies_User_Pages > thanks, > > Lisa > > On Fri, Feb 6, 2009 at 3:41 AM, Morgaine Dinova > > wrote: > > > > On Fri, Feb 6, 2009 at 10:34 AM, Infinity Linden (Meadhbh S. > Hamrick) > > wrote: > > 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. > > > Good, that is of course what I was hoping (and expecting) to > hear. Let's make sure that the charter reflects our openness and > makes our work of value to more parties than just the current > participants in the SL ecosystem. > > 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? > > > Yes, I'll try to help with this. Getting the charter right is > largely just a matter of naming the end goal and cutting out > SL-specifics. > > 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) > > > While the use of "Linden Lab" in the name is not vendor-agnostic > and hence might well cause problems of adoption by your > competitors (and you cannot seriously be suggesting that LL ranks > alongside Rivest!), that is not the key problem with the name, > which is the following. > > LLSD is in current use inside LL/SL, and so it cannot be both that > production format and a modified extensible format that we will be > refining at the same time. (It may not change, but at this stage > we cannot know that.) To use John's form of words in the LLSD > context, using this established technology PRECLUDES CHANGE if we > find that change is required. After all, it is not within our > scope to modify LL's current internal format. > > Personally I would have avoided the issue by replacing all > occurrences of "Linden Lab" by "Open Grid" in this Structured Data > spec for MMOX as a sign that the OGP protocol is fully independent > of LL, and to avoid any friction with other companies. "Open Grid > Structured Data" also happens to fit in with "Open Grid Protocol" > like hand in glove. > > Morgaine. > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From infinity@lindenlab.com Fri Feb 6 14:28:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9CFF3A6B96 for ; Fri, 6 Feb 2009 14:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkmDQPgU-Og5 for ; Fri, 6 Feb 2009 14:28:14 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id EECF03A6C57 for ; Fri, 6 Feb 2009 14:28:14 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 2E8A63DBC43E; Fri, 6 Feb 2009 14:28:17 -0800 (PST) Message-Id: <298C62B3-F45F-4FF7-B192-C308225B263B@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Dr Scofield In-Reply-To: <498C251D.7030107@xyzzyxyzzy.net> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Feb 2009 14:28:14 -0800 References: <498C251D.7030107@xyzzyxyzzy.net> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] GridInfo work X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:28:15 -0000 awesome! thanks for the suggestion. as we work out some of the specs =20 regarding connecting to grids, this should definitely be discussed. =20 exactly what spec it would live in is unclear at this early stage. but =20= it sounds like there's a good discussion regarding work items to =20 include in the charter, so as we start that discussion, we should =20 remember to make sure we define a document whose scope include grid =20 meta-info. Morgaine has spoken in support of the work too, so we're =20 off to a good start. -cheers, -m/=E2=88=9E On Feb 6, 2009, at 3:55 AM, Dr Scofield wrote: > hi, > > OpenSim has for quite some time now been supporting GridInfo > (http://opensimulator.org/wiki/GridInfo) which provides a way of > obtaining grid details such as welcome page, login URI, grid platform > (e.g., SecondLife, OpenSim), etc and use that to automatically =20 > configure > a client (the Hippo viewer, for example, supports GridInfo, as does =20= > the > rezzme protocol handler). > > i'd like to propose including this in MMOX. > > dirk > > --=20 > dr dirk husemann ---- virtual worlds research ---- ibm zurich =20 > research lab > SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- = http://xyzzyxyzzy.net/ > RL: hud@zurich.ibm.com - +41 44 724 8573 - = http://www.zurich.ibm.com/~hud/ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From djshag@hotmail.com Fri Feb 6 14:43:43 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F01303A6967 for ; Fri, 6 Feb 2009 14:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_FWDLOOK=1.666, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh2wwyIvNYCa for ; Fri, 6 Feb 2009 14:43:42 -0800 (PST) Received: from bay0-omc1-s19.bay0.hotmail.com (bay0-omc1-s19.bay0.hotmail.com [65.54.246.91]) by core3.amsl.com (Postfix) with ESMTP id EC4393A6810 for ; Fri, 6 Feb 2009 14:43:41 -0800 (PST) Received: from BAY136-DS6 ([65.55.141.33]) by bay0-omc1-s19.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Feb 2009 14:43:44 -0800 X-Originating-IP: [74.57.138.6] X-Originating-Email: [djshag@hotmail.com] Message-ID: From: "Patrick N." To: References: In-Reply-To: Date: Fri, 6 Feb 2009 17:43:38 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8050.1202 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8050.1202 X-OriginalArrivalTime: 06 Feb 2009 22:43:44.0875 (UTC) FILETIME=[5DF353B0:01C988AC] Subject: Re: [mmox] mmox Digest, Vol 1, Issue 7 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:43:44 -0000 There is an interesting concept that is pretty much the same as SLURL's for OpenSim right now available in beta. You can find more information here: http://lab.newworldgrid.com/index.php/OSURL The way they have the URL is like this: http://osurl.org/grid.newworldgrid.com:8002/Faelwen/128/130/50 I personally think it is a good start and maybe it could work also with SL Urls. SL: Patnad Babii -------------------------------------------------- From: Sent: Friday, February 06, 2009 4:04 PM To: Subject: mmox Digest, Vol 1, Issue 7 > Send mmox mailing list submissions to > mmox@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/mmox > or, via email, send a message with subject or body 'help' to > mmox-request@ietf.org > > You can reach the person managing the list at > mmox-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mmox digest..." > > > Today's Topics: > > 1. Re: rezzme URI scheme: addressing locations/grids (SLURLs are > bad, bad, bad) (jack@martinelli.org) > 2. Re: rezzme URI scheme: addressing locations/grids (SLURLs are > bad, bad, bad) (Cenji Neutra) > 3. Greetings, MMOX Charter, Scope, Activities.. (David W Levine) > 4. Re: Work Items and Planning Documents for the MMOX BoF > session (Draft Charter) (Lawson English) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 6 Feb 2009 14:14:36 -0600 > From: jack@martinelli.org > Subject: Re: [mmox] rezzme URI scheme: addressing locations/grids > (SLURLs are bad, bad, bad) > To: mmox@ietf.org > Message-ID: <20090206141436.kj48j6rfhcgg8kog@webmail.martinelli.org> > Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; > format="flowed" > > > hmmm... my 2 cents... > > Coordinates are abstract labels. Assigning URI's to world cooddinates > adds another layer of abstraction. That a VWURI (virtual world > uniform resouce identifier) is a reference to a GridInfo object is a > start. Note that URI's on the www have several components and all > relate to objects of various MIME types, protocols, (http, https, et. > al. ) and addresses within the www. That is, a URI is an address to > very specific objects. a SLURL is a generic location in the context > defined by SL. There really are two differnt intents to these two > very different kinds of references. I am quite certain two kinds of > addresses are needed. > > 1. A Vicinity address that anyone can use as a teleportation > destination - like rezzme. > 2. An object address that anyone can use to construct a client viewer > from. ...with of course new MIME types - like GEOM? and EGEOM for > embeded geometry. Imagine a med student entering a patient's ear... > visiting an aural nerve .. entering the cytoplasm of the nerve... > watching the molecules as they respond to a sound... going in the > nerve's nucleus & replaceing a neucleotide or two... watching the > results of his genetic surgury. Note that EGEOM's can act as a user > defined kind of leveling. (use a psuedo object for outside viewing, > and load the contents of the EGEOM for display if inside the object... > ala iframe) > > I have to admit I haven't looked at the GridInfo structure. But it > sounds like it describes the content of a sim. I.e., limited to the > objects stored at a single CPU. I'd prefer to use a model similar to > the WWW where an object may be referenced by a VW page. > > This idea, for example, turns out to be very useful for load balancing > ( see Mod-Rewrite for example) and obviously ... failovers... virtual > page construction ala CGI technologies like .asp, .net, .jsp etc... etc. > > And I am seeing a need to begin a wiki dictionary for this project. I > think it might be useful to see the URL for the dictionary at the > bottom of each email for this list. > > here's a few ideas for your darts... > > HGML -- for Hyper Geometry Markup Language & as a mime type and is a > container for other grid objects of various other MIME types. > Obviously along the same lines as SGML & XML. > > VWURI -- for VW mime types (hmmmmm do we really need a new concept > for this????) Oh & btw... an HGML page that refers to an object via > its coordinates becomes obsolete if the object is moved. Object names > ala SL won't work since the names are not unique. So for > interoperability objects really do need to be refered to by their > GUID's. & so HGML pages then should have UUID's.. so in a sense a > GUID becomes similar to an IP. hmmmmm - do I hear a can of worms > opening - or an opportunity? (reverse GUID lookup?) OR... should > there be relative resource ID's? -- some restrictions may apply eh? > This might end up as a requirement. > > (BTW... where's the requirements document?) > > VIC -- for vicinity locations that may be used for teleport > destinations ala rezzme. VIC might not be good though - I think in > Swedish it means %$@#. > alternatives (VWC - virtual world coordinates) (TPC - teleport > coordinates) (VWL for virtual world location) > > VWN - virtual world node (rather than sim). > > VWC - virtual world cluster > > Sorry I can't write up a document... I don't even have time for this :( > > BTW - thank you Dr. Scofield. Your post to the group was productive. > > Quoting Dr Scofield : > >> i think we need a virtual world independent way of addressing locations >> in virtual worlds. Linden Labs did coin the SLURL way of doing this for >> the linden lab grid --- unfortunately SLURLs don't allow us to address >> locations on other grids, let alone other virtual world platforms (e.g., >> OpenSim grids). >> >> we'd like to propose the rezzme:// URI scheme >> (http://xyzzyxyzzy.net/2009/01/07/addressing-places-in-virtual-worldsor-why-slurls-are-bad/) >> --- a reference implementation of a rezzme protocol handler is available >> (http://forge.opensimulator.org/gf/project/rezzme/). >> >> we've been using it to address OpenSim grids, Linden Lab main and beta >> (and other) grids. the rezzme protocol handler utilizes GridInfo. >> >> dirk >> >> -- >> dr dirk husemann ---- virtual worlds research ---- ibm zurich research >> lab >> SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- >> http://xyzzyxyzzy.net/ >> RL: hud@zurich.ibm.com - +41 44 724 8573 - >> http://www.zurich.ibm.com/~hud/ >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 6 Feb 2009 15:24:57 -0500 > From: Cenji Neutra > Subject: Re: [mmox] rezzme URI scheme: addressing locations/grids > (SLURLs are bad, bad, bad) > To: mmox@ietf.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > It seems unlikely to me that virtual world implementations of the > (moderate) future will include any fixed 1-1 correspondence between > named locations used by people and particular geographically > distributed simulation processes (if they do, they'll soon give way to > the more computationally efficient implementations of their > competitors). > > I think we all know that LLs decision to expose an implementation > detail like sims/regions (which correspond to a process responsible > for simulating a fixed-size geographic area and the physical objects > within it) in the user interface of SL as named regions, was motivated > by the trade-off between generality for the future vs expedience and > simplicity of development / time-to-market. > > So, the question is, does a location addressing scheme like > (region-name,x,y,z) even belong in such a forward-looking standard? > While any virtual world that employs a 2D land-area can have such an > addressing scheme overlaid on it, I would think it isn't appropriate > to include it at such a low level as to force other implementations > into using such a scheme. There exist implementations for which > simulation resources are distributed dynamically over the entities > that need to be simulated, rather than fixed geographic areas - as in > SL, and for which a such a mapping may not be practical to implement > or desirable. > > Obviously, the standards process has to agree on some basic properties > of what constitutes the X in MMOX. Is that going to imply some > simulated 3D space? If so, perhaps a global x,y,z is all that is > needed (and vendors can map vendor-centric schemes over that if > desired). If not, and the 'space' is not constrained to physical > space analogues at all, then perhaps dictating 'location' addressing > schemes is outside the scope? (for example, an application agent space > where agents move according to the interaction patterns dictated by > the application logic wouldn't fit into a geographic scheme well) > > My personal preference would be that we limit the scope of the X in > MMOX to systems that simulate some analogue of 3D physical space (not > necessarily continuous or simply-connected). That way, if location > addressing is within the scope, something like a global x,y,z can be > used and then vendors can easily map other schemes over that (or not) > as desired. > > -David > > SL: Cenji Neutra > -- > Apez - we make your virtual life easier > http://www.apez.biz > >> Date: Fri, 06 Feb 2009 13:05:11 +0100 >> From: Dr Scofield >> Subject: [mmox] rezzme URI scheme: addressing locations/grids (SLURLs >> are bad, bad, bad) >> To: mmox@ietf.org >> Message-ID: <498C2777.4090506@xyzzyxyzzy.net> >> Content-Type: text/plain; charset=ISO-8859-15 >> >> i think we need a virtual world independent way of addressing locations >> in virtual worlds. Linden Labs did coin the SLURL way of doing this for >> the linden lab grid --- unfortunately SLURLs don't allow us to address >> locations on other grids, let alone other virtual world platforms (e.g., >> OpenSim grids). >> >> we'd like to propose the rezzme:// URI scheme >> (http://xyzzyxyzzy.net/2009/01/07/addressing-places-in-virtual-worldsor-why-slurls-are-bad/) >> --- a reference implementation of a rezzme protocol handler is available >> (http://forge.opensimulator.org/gf/project/rezzme/). >> >> we've been using it to address OpenSim grids, Linden Lab main and beta >> (and other) grids. the rezzme protocol handler utilizes GridInfo. >> >> dirk >> >> -- >> dr dirk husemann ---- virtual worlds research ---- ibm zurich research >> lab >> SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- >> http://xyzzyxyzzy.net/ >> RL: hud@zurich.ibm.com - +41 44 724 8573 - >> http://www.zurich.ibm.com/~hud/ >> > > > ------------------------------ > > Message: 3 > Date: Fri, 6 Feb 2009 15:32:24 -0500 > From: David W Levine > Subject: [mmox] Greetings, MMOX Charter, Scope, Activities.. > To: "mmox@ietf.org" , mmox-bounces@ietf.org > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > Greetings, all, quite a few familiar names going by.. For anyone who > doesn't keep track of the RL/SL mapping you'll find me in SL under Zha > Ewry. (Hey, you never know, > someone might not be paying attention.) > > I'd like to start with some perspective on what I expect out of an IETF > Working Group in this space, and then, follow up with several notes on > specific issues, one per note. > > The reason to bring work to the IETF is to help establish it as a usable > specification for interop between as large a community as possible. My > personal and professional interest in this work, is not to codify the > current state of the Linden Lab grid, or to codify the next iteration of > that codebase. I think of the goal as parallel to one of the goals of the > OpenSim code base itself, establishing a set of specifications from which > a broad range of immersive, virtual spaces can be created. If MMOX only > addresses the concerns of Linden Lab, or the OpenSim community, or a small > set of corporate players, I see little point in the exercise. > OpenSim and Linden Lab have different code bases, sometimes strikingly so > as the OpenSim community has been creative and original in solving > problems. But, both groups share a common heritage, linked by the client, > and shaped by Linden Lab's initial design choices. This may well be too > narrow to fully engage the larger community. > > The proposed Charter that Infinity provided, is a starting point for > discussion, and the work items are those Linden has offered to the MMOX > effort. The point of a BOF, and using the mailing list and developing a > charter, is to sort out what the entire community of interest thinks > belongs in the charter, the workgroup and the work items. > > My hope is that we end up with a set of specifications, which define three > broad sets of items. Low level encoding and formats specifications, and > protocols aimed at building blocks for moving content around. Sets of > services, such as Inventory management, asset Storage, Messaging, > presence, and so forth, which can be deployed in a wide variety of > combinations to get useful effects. finally, there is a set of services > centering around that Linden calls a region simulator, which, are in > essence, the mechanisms used to manage a shared scene graph. Please note, > that the current deployment of these services within the Linden Lab Grid, > and on OpenSim grids, is one model for how a scene graph can be shared. > The core problem, of accepting control inputs from many sources, creating > a stream of updated states and sharing them back out to concerned parties, > is, I believe, the nub of the problem. Many variations can be imagined, > with more or less detail handled centrally, peer to peer simulations, and > largely client side simulations. Our challenge is to capture a set of > services and models which lets us describe these various implementation > choices at the services and protocol level, and, as much as possible, > separate deployment and implementation choices from the interoperable > building blocks we define. > > I strongly encourage everyone to share news of the BOF, and of the > proposed working group as widely as possible. While there is a clear > danger in boiling the ocean, if we end up with too diverse a set of > interests, I think that danger is far less than the danger of creating a > small focused set of specifications which don't allow the majority of > possible virtual worlds environments to interoperate. > > Finally, a small word on process and participation. The IETF works by > "rough consensus" how rough, and how broad, is somewhat ill defined. It is > not unanimity, nor is there a precise measure of what is meant by the > phrase. My personal belief is that standards live and die by the ability > of the working group to attract sufficient participants to the consensus. > Standards which unify multiple approaches and allow a diversity of > implementations are of much higher value than ones which codify a single > approach, no matter how well they define that approach. The broader a set > of participants we attract, and the broader a set of possibilities we > enable, the more impact we can have. > > I don't expect that a successful IETF working group will define a set of > specifications which maps exactly to any one implementation. I expect we > will, as a community, begin the process of creating a set of shared > building blocks from which we can compose many implementations. The > balancing acts between generality and efficiency, between learning from > the existing code bases, and imagining better ones > will be some of the biggest challenge we face. The goal is not a single > homogenous grid, but rather defining a broad set of possible virtual > spaces, and enabling as fluid and transparent movement between them as we > can manage. > > > - David W. Levine > ~ Zha Ewry (ISL) > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 4 > Date: Fri, 06 Feb 2009 14:04:08 -0700 > From: Lawson English > Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF > session (Draft Charter) > To: Lisa Dusseault > Cc: "mmox@ietf.org" > Message-ID: <498CA5C8.3090601@cox.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Lisa Dusseault wrote: >> I'm the sponsoring AD for this BOF, and I'm glad to see work on making >> the charter more generic already. It wasn't clear to me how >> interested other parties besides Linden Labs were, and what they want, >> but that's what the BOF process (not just the meeting, but also the >> mailing list and its charter discussions ) is for. The goal is to >> figure out The Right Thing to do, and nothing is set in stone yet. >> The right thing could even be more than one WG, for example. >> >> It's worth pointing out very early that the deadline for submitting >> new Internet-Drafts is March 2, and there's a tradition of only >> considering material that has been published in Internet-Drafts at >> IETF meetings. Thus, if there's any other material that can be put in >> the form of an Internet-Draft and published by March 2, then that >> document is referenced in the agenda, a lot of IETF people will read >> that material and be better prepared for this BOF. >> >> In particular, people like me who haven't been involved in this area >> will need a bit more introduction somehow. I actually have read some >> of this Open Grid stuff before, and yet I'm still struggling with what >> it means for two nodes to share perceptions of things or to handoff >> control of virtual objects. What about trust between nodes? What >> about differences in how things are modeled and what metadata they have? >> > > Those are hot-button questions, Lisa, due to the "live" economy that > Second LIfe uses. There's been more discussions on those topics than > anything else, I suspect. > > Here's an index to most of the discussions I'm aware of about these > topics: > > https://wiki.secondlife.com/wiki/AW_Groupies#Chat_Logs > > key words: permissions, perms, IP, intellectual property, content > creation, content creators, inventory, assets, copybot... > > See alsp: https://wiki.secondlife.com/wiki/Category:AW_Groupies_User_Pages > > > >> thanks, >> >> Lisa >> >> On Fri, Feb 6, 2009 at 3:41 AM, Morgaine Dinova >> > > wrote: >> >> >> >> On Fri, Feb 6, 2009 at 10:34 AM, Infinity Linden (Meadhbh S. >> Hamrick) > >> wrote: >> >> 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. >> >> >> Good, that is of course what I was hoping (and expecting) to >> hear. Let's make sure that the charter reflects our openness and >> makes our work of value to more parties than just the current >> participants in the SL ecosystem. >> >> 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? >> >> >> Yes, I'll try to help with this. Getting the charter right is >> largely just a matter of naming the end goal and cutting out >> SL-specifics. >> >> 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) >> >> >> While the use of "Linden Lab" in the name is not vendor-agnostic >> and hence might well cause problems of adoption by your >> competitors (and you cannot seriously be suggesting that LL ranks >> alongside Rivest!), that is not the key problem with the name, >> which is the following. >> >> LLSD is in current use inside LL/SL, and so it cannot be both that >> production format and a modified extensible format that we will be >> refining at the same time. (It may not change, but at this stage >> we cannot know that.) To use John's form of words in the LLSD >> context, using this established technology PRECLUDES CHANGE if we >> find that change is required. After all, it is not within our >> scope to modify LL's current internal format. >> >> Personally I would have avoided the issue by replacing all >> occurrences of "Linden Lab" by "Open Grid" in this Structured Data >> spec for MMOX as a sign that the OGP protocol is fully independent >> of LL, and to avoid any friction with other companies. "Open Grid >> Structured Data" also happens to fit in with "Open Grid Protocol" >> like hand in glove. >> >> Morgaine. >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > > > ------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > End of mmox Digest, Vol 1, Issue 7 > ********************************** > From infinity@lindenlab.com Fri Feb 6 14:51:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB483A6C46 for ; Fri, 6 Feb 2009 14:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSRhKCCeZYfU for ; Fri, 6 Feb 2009 14:51:08 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 4F4D83A6C3C for ; Fri, 6 Feb 2009 14:51:08 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id D59CE3DBC43F; Fri, 6 Feb 2009 14:51:10 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Dr Scofield In-Reply-To: <498C2777.4090506@xyzzyxyzzy.net> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 6 Feb 2009 14:51:07 -0800 References: <498C2777.4090506@xyzzyxyzzy.net> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] rezzme URI scheme: addressing locations/grids (SLURLs are bad, bad, bad) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 22:51:09 -0000 right... slurl's are currently limited to the main Second Life grid. a =20= scheme that allows users to reference locations in other grids (even =20 other LL grids) would have more utility. if you haven't done so =20 already, i would recommend looking at some of the existing standards, =20= specifically RFC3986 and RFC3305 and the documents they reference. I =20 think there's some wisdom in both documents that would definitely =20 apply to the conversation. working code and experience deploying and using it is definitely good. there is one caveat i would add, however. the utility of new URI =20 schemes is often questioned, so it's probably good to define the =20 verbiage for the motivation for the scheme. let me give this =20 suggestion for a motivation... at some point we're going to be =20 defining protocol that will include "locations in { a | the } virtual =20= world" as a parameter to some service request. i would anticipate the =20= question, "why do we need a new URI scheme for this? why can't we just =20= provide a HTTP URL that points to a resource that provides the =20 information you need?" the rebuttal(s) to this question i can think of =20= would be... a) it's nice to have a URI that encodes semantics that are =20= human comprehensible.. i.e. - you can look at the rezzme: URI and get =20= useful information. and b) it allows you to remove the method of =20 accessing the information you need from the information itself.. (i.e. =20= - a rezzme: URI doesn't REQUIRE you to do a HTTP query just to get =20 then info about the target location.) and... the scheme referenced includes a form that adds the user's =20 password to the URI. i can't find the exact reference at the moment, =20 but i'm pretty sure this is generally a deprecated form. while =20 including authentication information in URIs is useful in many cases, =20= it's a huge security hole and i remember there was quite a bit of =20 discussion about it a while ago. but.. it's a great suggestion for something to include in the scope of =20= the WG.. being able to uniquely identify locations in {a | the} =20 virtual world will definitely be a requirement. -cheers -m/=E2=88=9E On Feb 6, 2009, at 4:05 AM, Dr Scofield wrote: > i think we need a virtual world independent way of addressing =20 > locations > in virtual worlds. Linden Labs did coin the SLURL way of doing this =20= > for > the linden lab grid --- unfortunately SLURLs don't allow us to address > locations on other grids, let alone other virtual world platforms =20 > (e.g., > OpenSim grids). > > we'd like to propose the rezzme:// URI scheme > = (http://xyzzyxyzzy.net/2009/01/07/addressing-places-in-virtual-worldsor-wh= y-slurls-are-bad/=20 > ) > --- a reference implementation of a rezzme protocol handler is =20 > available > (http://forge.opensimulator.org/gf/project/rezzme/). > > we've been using it to address OpenSim grids, Linden Lab main and beta > (and other) grids. the rezzme protocol handler utilizes GridInfo. > > dirk > > --=20 > dr dirk husemann ---- virtual worlds research ---- ibm zurich =20 > research lab > SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- = http://xyzzyxyzzy.net/ > RL: hud@zurich.ibm.com - +41 44 724 8573 - = http://www.zurich.ibm.com/~hud/ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From rthayer@secorix.com Fri Feb 6 15:02:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57373A67DF for ; Fri, 6 Feb 2009 15:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvyxQg62EZBM for ; Fri, 6 Feb 2009 15:02:23 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 9798E3A6919 for ; Fri, 6 Feb 2009 15:02:23 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so571406rvb.5 for ; Fri, 06 Feb 2009 15:02:26 -0800 (PST) Received: by 10.141.153.17 with SMTP id f17mr1108919rvo.99.1233961346061; Fri, 06 Feb 2009 15:02:26 -0800 (PST) Received: from ?192.168.1.103? (64-79-123-251.static.wiline.com [64.79.123.251]) by mx.google.com with ESMTPS id l31sm6769343rvb.4.2009.02.06.15.02.24 (version=SSLv3 cipher=RC4-MD5); Fri, 06 Feb 2009 15:02:25 -0800 (PST) Message-ID: <498CC17E.5020606@secorix.com> Date: Fri, 06 Feb 2009 15:02:22 -0800 From: Rodney Thayer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mmox@ietf.org References: <498C2777.4090506@xyzzyxyzzy.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [mmox] rezzme URI scheme: addressing locations/grids (SLURLs are bad, bad, bad) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 23:02:24 -0000 (somebody has to say it...) V6 address wouldn't work, right? We're not routing packets between worlds so that doesn't make sense, right? But... we're routing (stuff) between (places) and so lots of prior art, er, work, might provide insight. X.400 email addresses and X.500 distinguished names come to mind. A TLD for SL and the other virtual worlds that are public and/or have registered names? My point is not that SLURL-equivalents could be done in X.400 email, rather that we should make sure this is solving a new problem... this entire area clearly needs some standardization but before it adds protocols it'd be nice to make sure we use the ones that apply (and are architecturally relevant.) Meadhbh Hamrick (Infinity) wrote: > right... slurl's are currently limited to the main Second Life grid. a > scheme that allows users to reference locations in other grids (even > other LL grids) would have more utility. if you haven't done so already, > i would recommend looking at some of the existing standards, > specifically RFC3986 and RFC3305 and the documents they reference. I > think there's some wisdom in both documents that would definitely apply > to the conversation. > > working code and experience deploying and using it is definitely good. > > there is one caveat i would add, however. the utility of new URI schemes > is often questioned, so it's probably good to define the verbiage for > the motivation for the scheme. let me give this suggestion for a > motivation... at some point we're going to be defining protocol that > will include "locations in { a | the } virtual world" as a parameter to > some service request. i would anticipate the question, "why do we need a > new URI scheme for this? why can't we just provide a HTTP URL that > points to a resource that provides the information you need?" the > rebuttal(s) to this question i can think of would be... a) it's nice to > have a URI that encodes semantics that are human comprehensible.. i.e. - > you can look at the rezzme: URI and get useful information. and b) it > allows you to remove the method of accessing the information you need > from the information itself.. (i.e. - a rezzme: URI doesn't REQUIRE you > to do a HTTP query just to get then info about the target location.) > > and... the scheme referenced includes a form that adds the user's > password to the URI. i can't find the exact reference at the moment, but > i'm pretty sure this is generally a deprecated form. while including > authentication information in URIs is useful in many cases, it's a huge > security hole and i remember there was quite a bit of discussion about > it a while ago. > > but.. it's a great suggestion for something to include in the scope of > the WG.. being able to uniquely identify locations in {a | the} virtual > world will definitely be a requirement. > > -cheers > -m/∞ > > On Feb 6, 2009, at 4:05 AM, Dr Scofield wrote: > >> i think we need a virtual world independent way of addressing locations >> in virtual worlds. Linden Labs did coin the SLURL way of doing this for >> the linden lab grid --- unfortunately SLURLs don't allow us to address >> locations on other grids, let alone other virtual world platforms (e.g., >> OpenSim grids). >> >> we'd like to propose the rezzme:// URI scheme >> (http://xyzzyxyzzy.net/2009/01/07/addressing-places-in-virtual-worldsor-why-slurls-are-bad/) >> >> --- a reference implementation of a rezzme protocol handler is available >> (http://forge.opensimulator.org/gf/project/rezzme/). >> >> we've been using it to address OpenSim grids, Linden Lab main and beta >> (and other) grids. the rezzme protocol handler utilizes GridInfo. >> >> dirk >> >> -- >> dr dirk husemann ---- virtual worlds research ---- ibm zurich research >> lab >> SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- >> http://xyzzyxyzzy.net/ >> RL: hud@zurich.ibm.com - +41 44 724 8573 - >> http://www.zurich.ibm.com/~hud/ >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From dwl@us.ibm.com Fri Feb 6 15:04:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A803A6836; Fri, 6 Feb 2009 15:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.304 X-Spam-Level: X-Spam-Status: No, score=-5.304 tagged_above=-999 required=5 tests=[AWL=1.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qkyG+KhOWri; Fri, 6 Feb 2009 15:04:11 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id BA49B3A67DF; Fri, 6 Feb 2009 15:04:10 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n16MvWQI028449; Fri, 6 Feb 2009 17:57:32 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n16N4CNe198402; Fri, 6 Feb 2009 18:04:12 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n16N4Cio030240; Fri, 6 Feb 2009 18:04:12 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n16N4B5Y030234; Fri, 6 Feb 2009 18:04:11 -0500 In-Reply-To: To: Lisa Dusseault MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Fri, 6 Feb 2009 18:04:10 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/06/2009 18:04:11, Serialize complete at 02/06/2009 18:04:11 Content-Type: multipart/alternative; boundary="=_alternative 007EB96985257555_=" Cc: mmox-bounces@ietf.org, "mmox@ietf.org" Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 23:04:13 -0000 This is a multipart message in MIME format. --=_alternative 007EB96985257555_= Content-Type: text/plain; charset="US-ASCII" Great to see you asking questions Lisa. Two separate issues. Trust, can be viewed as straightforward, but hard. We have the usual kitbag of PKIX style solutions, which is good, in the sense that tools like X.509, TLS and HTTPS give us good ways to manage authenticating a remote node in the internet as someone we understand, but bad, in the sense that large scale deployments of PKI based solutions are expensive, and non trivial to manage. There has been a long, ongoing discussion about applying X.509, and such to provide a basis for establishing shared trust, and then layering policy based choices on top of that. (What degree of trust, can I extend to a service which offers me this trust token? things of that sort) I started to right a long answer to your second question, but, it was turning into an essay on immersive space design. The short form of the answer is, yes, this work needs to allow for virtual space services to expose the type of model(s) they support, as well as they styles of interaction they support. Likewise, there are issues akin to content negotiation, when adding objects into a simulated region, and, several approaches to how a simulation should be deployed as a process (Single unitary service, peer to peer mesh of services, clients off-loading various degrees of processing, etc) There are some good leverage points, which factor out the common tasks in all these approaches, namely, adding inputs to the simulation, progressing the simulation, and notifying interested parties of the results. In some cases, this will look very much like the "Region simulator" model which Linden Lab, and a number of other virtual worlds adopt, where simulation is unitary, in others, it may involved a set of peers, as are found in Croquet, which share the state of the world, and then model it locally. The degree to which such approaches can share the content which flows between them, is unclear, but probably greater than zero. ("Object 17, is rotating according to this vector" is something that would be expressed in many of the different approaches, for example) I expect that, this work will end up being a mix of very concrete efforts to document building blocks, with much more abstract work to allow us to express multiple styles of interactions using shared building blocks. If we can, in fact identify the shared building blocks, and can specify them to everyone's satisfaction, I would hope that would create draft specifications which would advance interoperability broadly. - David W. Levine ~ Zha Ewry (ISL) Lisa Dusseault Sent by: mmox-bounces@ietf.org 02/06/2009 02:22 PM To Morgaine Dinova cc "mmox@ietf.org" Subject Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) I'm the sponsoring AD for this BOF, and I'm glad to see work on making the charter more generic already. It wasn't clear to me how interested other parties besides Linden Labs were, and what they want, but that's what the BOF process (not just the meeting, but also the mailing list and its charter discussions ) is for. The goal is to figure out The Right Thing to do, and nothing is set in stone yet. The right thing could even be more than one WG, for example. It's worth pointing out very early that the deadline for submitting new Internet-Drafts is March 2, and there's a tradition of only considering material that has been published in Internet-Drafts at IETF meetings. Thus, if there's any other material that can be put in the form of an Internet-Draft and published by March 2, then that document is referenced in the agenda, a lot of IETF people will read that material and be better prepared for this BOF. In particular, people like me who haven't been involved in this area will need a bit more introduction somehow. I actually have read some of this Open Grid stuff before, and yet I'm still struggling with what it means for two nodes to share perceptions of things or to handoff control of virtual objects. What about trust between nodes? What about differences in how things are modeled and what metadata they have? thanks, Lisa On Fri, Feb 6, 2009 at 3:41 AM, Morgaine Dinova < morgaine.dinova@googlemail.com> wrote: On Fri, Feb 6, 2009 at 10:34 AM, Infinity Linden (Meadhbh S. Hamrick) < infinity@lindenlab.com> wrote: 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. Good, that is of course what I was hoping (and expecting) to hear. Let's make sure that the charter reflects our openness and makes our work of value to more parties than just the current participants in the SL ecosystem. 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? Yes, I'll try to help with this. Getting the charter right is largely just a matter of naming the end goal and cutting out SL-specifics. 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) While the use of "Linden Lab" in the name is not vendor-agnostic and hence might well cause problems of adoption by your competitors (and you cannot seriously be suggesting that LL ranks alongside Rivest!), that is not the key problem with the name, which is the following. LLSD is in current use inside LL/SL, and so it cannot be both that production format and a modified extensible format that we will be refining at the same time. (It may not change, but at this stage we cannot know that.) To use John's form of words in the LLSD context, using this established technology PRECLUDES CHANGE if we find that change is required. After all, it is not within our scope to modify LL's current internal format. Personally I would have avoided the issue by replacing all occurrences of "Linden Lab" by "Open Grid" in this Structured Data spec for MMOX as a sign that the OGP protocol is fully independent of LL, and to avoid any friction with other companies. "Open Grid Structured Data" also happens to fit in with "Open Grid Protocol" like hand in glove. Morgaine. _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --=_alternative 007EB96985257555_= Content-Type: text/html; charset="US-ASCII"
Great to see you asking questions Lisa.  

Two separate issues. Trust, can be viewed as straightforward, but hard. We have the usual kitbag of PKIX style solutions, which is good, in the sense that tools like X.509, TLS and HTTPS give us good ways to manage authenticating a remote node in the internet as someone we understand, but bad, in the sense that large scale deployments of PKI based solutions are expensive, and non trivial to manage.  There has been a long, ongoing discussion about applying X.509, and such to provide a basis for establishing shared trust, and then layering policy based choices on top of that. (What degree of trust, can I extend to a service which offers me this trust token? things of that sort)

I started to right a long answer to your second question, but, it was turning into an essay on immersive space design. The short form of the answer is, yes, this work needs to allow for virtual space services to expose the type of model(s) they support, as well as they styles of interaction they support. Likewise, there are issues akin to content negotiation, when adding objects into a simulated region, and, several approaches to how a simulation should be deployed as a process (Single unitary service, peer to peer mesh of services, clients off-loading various degrees of processing, etc)

There are some good leverage points, which factor out the common tasks in all these approaches, namely, adding inputs to the simulation, progressing the simulation, and notifying interested parties of the results. In some cases, this will look very much like the "Region simulator" model which Linden Lab, and a number of other virtual worlds adopt, where simulation is unitary, in others, it may involved a set of peers, as are found in Croquet, which share the state of the world, and then model it locally.  The degree to which such approaches can share the content which flows between them, is unclear, but probably greater than zero. ("Object 17, is rotating according to this vector" is something that would be expressed in many of the different approaches, for example)

I expect that, this work will end up being a mix of very concrete efforts to document building blocks, with much more abstract  work to allow us to express multiple styles of interactions using shared building blocks. If we can, in fact identify the shared building blocks, and can specify them to everyone's satisfaction, I would hope that would create draft specifications which would advance interoperability broadly.

- David W. Levine
~ Zha Ewry (ISL)




Lisa Dusseault <lisa.dusseault@gmail.com>
Sent by: mmox-bounces@ietf.org

02/06/2009 02:22 PM

To
Morgaine Dinova <morgaine.dinova@googlemail.com>
cc
"mmox@ietf.org" <mmox@ietf.org>
Subject
Re: [mmox] Work Items and Planning Documents for the MMOX BoF        session (Draft Charter)





I'm the sponsoring AD for this BOF, and I'm glad to see work on making the charter more generic already.  It wasn't clear to me how interested other parties besides Linden Labs were, and what they want, but that's what the BOF process (not just the meeting, but also the mailing list and its charter discussions ) is for.  The goal is to figure out The Right Thing to do, and nothing is set in stone yet.  The right thing could even be more than one WG, for example.

It's worth pointing out very early that the deadline for submitting new Internet-Drafts is March 2, and there's a tradition of only considering material that has been published in Internet-Drafts at IETF meetings.  Thus, if there's any other material that can be put in the form of an Internet-Draft and published by March 2, then that document is referenced in the agenda, a lot of IETF people will read that material and be better prepared for this BOF.  

In particular, people like me who haven't been involved in this area will need a bit more introduction somehow.  I actually have read some of this Open Grid stuff before, and yet I'm still struggling with what it means for two nodes to share perceptions of things or to handoff control of virtual objects.  What about trust between nodes?  What about differences in how things are modeled and what metadata they have?

thanks,

Lisa
On Fri, Feb 6, 2009 at 3:41 AM, Morgaine Dinova <morgaine.dinova@googlemail.com> wrote:


On Fri, Feb 6, 2009 at 10:34 AM, Infinity Linden (Meadhbh S. Hamrick) <infinity@lindenlab.com> wrote:
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.

Good, that is of course what I was hoping (and expecting) to hear.  Let's make sure that the charter reflects our openness and makes our work of value to more parties than just the current participants in the SL ecosystem.
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?

Yes, I'll try to help with this.  Getting the charter right is largely just a matter of naming the end goal and cutting out SL-specifics.
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)

While the use of "Linden Lab" in the name is not vendor-agnostic and hence might well cause problems of adoption by your competitors (and you cannot seriously be suggesting that LL ranks alongside Rivest!), that is not the key problem with the name, which is the following.

LLSD is in current use inside LL/SL, and so it cannot be both that production format and a modified extensible format that we will be refining at the same time.  (It may not change, but at this stage we cannot know that.)  To use John's form of words in the LLSD context, using this established technology PRECLUDES CHANGE if we find that change is required.  After all, it is not within our scope to modify LL's current internal format.

Personally I would have avoided the issue by replacing all occurrences of "Linden Lab" by "Open Grid" in this Structured Data spec for MMOX as a sign that the OGP protocol is fully independent of LL, and to avoid any friction with other companies.  "Open Grid Structured Data" also happens to fit in with "Open Grid Protocol" like hand in glove.

Morgaine.

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--=_alternative 007EB96985257555_=-- From john.hurliman@intel.com Fri Feb 6 16:21:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0364F3A6BBF for ; Fri, 6 Feb 2009 16:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH35BcsOcnl5 for ; Fri, 6 Feb 2009 16:21:31 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 9149E3A6B70 for ; Fri, 6 Feb 2009 16:21:31 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 06 Feb 2009 16:15:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.37,394,1231142400"; d="scan'208";a="384791008" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga002.jf.intel.com with ESMTP; 06 Feb 2009 16:30:31 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Fri, 6 Feb 2009 17:21:34 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Fri, 6 Feb 2009 17:21:10 -0700 Thread-Topic: Proposed draft charter and milestone list Thread-Index: AcmIufpojn0g82eiQcGV7NgdbPsuSA== Message-ID: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {D2FDAD8B-D795-4005-8886-DC8BDB9294AE} x-cr-hashedpuzzle: AhcF BfWl COf5 Cz6i C2A7 C6TZ DbiK DmgW EFrq FNnm Fw2w Gk/w Hw0v H2LQ IGPX IUg/; 1; bQBtAG8AeABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {D2FDAD8B-D795-4005-8886-DC8BDB9294AE}; agBvAGgAbgAuAGgAdQByAGwAaQBtAGEAbgBAAGkAbgB0AGUAbAAuAGMAbwBtAA==; Sat, 07 Feb 2009 00:21:11 GMT; UAByAG8AcABvAHMAZQBkACAAZAByAGEAZgB0ACAAYwBoAGEAcgB0AGUAcgAgAGEAbgBkACAAbQBpAGwAZQBzAHQAbwBuAGUAIABsAGkAcwB0AA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 00:21:33 -0000 I have made changes to the draft group charter to make the language more ve= ndor neutral, and have changed the goals and milestones to be more vendor n= eutral 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 i= ncreasing interest to the internet community. Innumerable examples exist of= such applications, most using proprietary protocols. With their roots in g= ames 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 proce= ss 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 appl= ications, b) provide for access and exchange with other systems on the inte= rnet 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 p= rotocols to communicate and interact with the state of Virtual World applic= ations. Foundational protocols will be evaluated for: 1) representing appli= cation layer objects and serializing messages between these objects, 2) a m= essaging abstraction layer to support the unique needs of VW interactions, = 3) authenticating protocol endpoints. An attempt will be made to use existi= ng standards wherever possible. For example, image data is typed and transf= erred using MIME and HTTP; message serializations are encoded in XML and JS= ON. The MMOX working group is not proposing the standardization of any one comp= lete proprietary protocol, but the definition of a extensible core protocol= and layers of agreed functionality as they are developed. Because the foun= dational protocols can be deployed before the entire range of VW functions = is considered, we believe that the efforts of the MMOX working group are ac= hievable 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 I= nformational RFC February 2010 Progression of base VW protocols to a Proposed Standard February 2010 Progression of Virtual World Primitive Object Format to Propo= sed Standard February 2010 Rough consensus on a VW Authentication and VW Teleport protoc= ol June 2010 Progression of VW Authentication to Proposed Standard June 2010 Progression of VW Teleport to Proposed Standard --- John Hurliman From dcolivares@gmail.com Fri Feb 6 16:34:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CBC93A6856 for ; Fri, 6 Feb 2009 16:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id In8t0E-XCgPB for ; Fri, 6 Feb 2009 16:34:56 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 92BA23A6B3F for ; Fri, 6 Feb 2009 16:34:56 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1115359wfd.31 for ; Fri, 06 Feb 2009 16:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/v+mfwxPCiyaJW9gveMcRJtFt+orfGPVdl32AL66QPo=; b=qVTT6l9cITZ0AP/C+lGl0LibdePMYdjzcUdg9E2X7CXiC6imgRTfnWW5jVNimgcg3B EXSi//nTDt0yTlveYnY9L2XSjRpn2BE+06KK4bDzU/TBgjVEcLhoPe54Fx7B6dJDV8X4 Eo3tvurHV6CtmtjuY/ANqNJ7U1hx2zNeWtU4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bS5PrVc1I1OA+8KZqtBXZn64+oR7zr3eL33zkPSWdTQa5C76LBVV8qUSgdlWxICJXe ADDNro8blm2I8hh0gjbMKVVJa4TzrpbUeiwpm4HJQPRct3N/i9kSzAu/iFgX5sLDnu8u /N0dYwnVvl79VNyYQVatLqyRnXT/+lyPoA7+g= MIME-Version: 1.0 Received: by 10.143.158.16 with SMTP id k16mr1332499wfo.47.1233966898332; Fri, 06 Feb 2009 16:34:58 -0800 (PST) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> Date: Fri, 6 Feb 2009 19:34:58 -0500 Message-ID: From: Dan Olivares To: "Hurliman, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 00:34:57 -0000 humm On Fri, Feb 6, 2009 at 7:21 PM, Hurliman, John wr= ote: > 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 corre= ct 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 us= ed in business, education and information exchange. With a user base expect= ed to grow to beyond 50 million by 2011, creators of such systems have begu= n to look at ways to make such systems interoperate. There have been severa= l ad hoc efforts since 2007 to develop interoperability. We believe the pro= cess would now benefit from a formal, established process. > > The objective of the MMOX working group is to provide an application-laye= r wire protocol for Virtual Worlds to a) enable interoperability between ap= plications, b) provide for access and exchange with other systems on the in= ternet such as identity providers, web services, e-mail and other informati= on storage systems, c) allow network layers to recognize VW traffic and mak= e 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 appl= ications. Foundational protocols will be evaluated for: 1) representing app= lication 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 exis= ting standards wherever possible. For example, image data is typed and tran= sferred using MIME and HTTP; message serializations are encoded in XML and = JSON. > > The MMOX working group is not proposing the standardization of any one co= mplete proprietary protocol, but the definition of a extensible core protoc= ol and layers of agreed functionality as they are developed. Because the fo= undational protocols can be deployed before the entire range of VW function= s 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 Pro= posed Standard > February 2010 Rough consensus on a VW Authentication and VW Teleport prot= ocol > June 2010 Progression of VW Authentication to Proposed Standard > June 2010 Progression of VW Teleport to Proposed Standard > > --- > > John Hurliman > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From lenglish5@cox.net Fri Feb 6 18:07:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A5833A6B3F for ; Fri, 6 Feb 2009 18:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.147 X-Spam-Level: * X-Spam-Status: No, score=1.147 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMaUJ+tn92Xa for ; Fri, 6 Feb 2009 18:07:38 -0800 (PST) Received: from fed1rmmtao102.cox.net (fed1rmmtao102.cox.net [68.230.241.44]) by core3.amsl.com (Postfix) with ESMTP id C422E3A67DB for ; Fri, 6 Feb 2009 18:07:38 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao102.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090207020740.YKML2342.fed1rmmtao102.cox.net@fed1rmimpo02.cox.net> for ; Fri, 6 Feb 2009 21:07:40 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id Cq7f1b0014N6T0Q04q7frQ; Fri, 06 Feb 2009 21:07:39 -0500 X-Authority-Analysis: v=1.0 c=1 a=N2DjB-moaNEA:10 a=EMxi-gqHSKcA:10 a=Wajolswj7cQA:10 a=-Ki0Gwywz4NoWjAyocoA:9 a=2N023R-Ub-FQVxcZJvCuwpPdUuAA:4 a=dGJ0OcVc7YAA:10 a=kJVaTwQnZmMA:10 X-CM-Score: 0.00 Message-ID: <498CECEB.5010203@cox.net> Date: Fri, 06 Feb 2009 19:07:39 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 CC: "mmox@ietf.org" References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 02:07:39 -0000 And so it begins.... ;-) L. Dan Olivares wrote: > humm > > On Fri, Feb 6, 2009 at 7:21 PM, Hurliman, John 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. >> >> From morgaine.dinova@googlemail.com Sat Feb 7 00:18:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C408C3A6A5C for ; Sat, 7 Feb 2009 00:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+j3ZJysu8qg for ; Sat, 7 Feb 2009 00:18:29 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id C34433A67B1 for ; Sat, 7 Feb 2009 00:18:28 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so480907qwe.31 for ; Sat, 07 Feb 2009 00:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LpapSMmetKgR7Tn2cXlxO6feGVoKzHRudn0BfJfS/kc=; b=IxZDgZIgkbXrgAQJ7uLf2h3QTIy01oGfi0OpcJkP9NsinnFXs0yO1nJ90LWIjcZS62 br9lU9Ce3CrZgaysljF4PSkxUCs3B+lMgtATv1A0SsfpMADWpl0gGrF89w4WiBsRPOnD d19aj1R9jWWP9Wy+QbIBNM2H30IWrO/4HGX2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CYxdhA8cACAJ3QJS7B8KOoteNIG6bXIcI0VIgV2eLWY0Bu6gQAGb5Wza2ZrE9Zyt+7 5kBGitZKOzVWoP4cacKvYdtPXE73M5YeGkXbwJsE8f/xRTGWt25NvVV1+O6zRQ+DA1S7 gs2he0zza5FKlmzwjrIQUIe4yo4njtQ5sDP8s= MIME-Version: 1.0 Received: by 10.214.149.2 with SMTP id w2mr3887779qad.346.1233994710149; Sat, 07 Feb 2009 00:18:30 -0800 (PST) In-Reply-To: References: Date: Sat, 7 Feb 2009 08:18:30 +0000 Message-ID: From: Morgaine Dinova To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015175caa9e5a6c0504624fc891 Cc: Cenji Neutra Subject: Re: [mmox] rezzme URI scheme: addressing locations/grids (SLURLs are bad, bad, bad) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 08:18:29 -0000 --0015175caa9e5a6c0504624fc891 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 6, 2009 at 8:24 PM, Cenji Neutra wrote: > My personal preference would be that we limit the scope of the X in > MMOX to systems that simulate some analogue of 3D physical space (not > necessarily continuous or simply-connected). That way, if location > addressing is within the scope, something like a global x,y,z can be > used and then vendors can easily map other schemes over that (or not) > as desired. > I think that it would be very bad to exclude 2D worlds, Cenji. There is no good reason to place a lower limit on the dimensionality of virtual worlds, nor an upper limit. Indeed, 2D scrollers are still very popular, and have no less a right to addressing support without being treated as a degenerate case. Likewise, higher-dimensioned spaces may well appear --- we're already mapping a 3D scene onto a 2D screen after all, and a 4D timespace world in which time is also addressable and navigateable is easily envisaged, as are hyperspace worlds. I don't think that we should impose any arbitrary restrictions on addressibility. An address makes sense only in the context of a specific world, and therefore it is misguided to attempt to straightjacket all worlds into a single format. Indeed, SL already employs 4 dimensions of addressibility in its live world, namely {region, a, y, z}, or 5 dimensions when you add {gridname} to account for its special-purpose grids such as the Teen Grid, Preview Grid, OGP Beta Grid, and so on. Therefore I suggest that addresses simply be tuples with an arbitrary number of terms, and that the number of terms and their types should be entirely a matter for the world in question, and nobody else. Morgaine. --0015175caa9e5a6c0504624fc891 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 6, 2009 at 8:24 PM, Cenji Ne= utra <cenji.= neutra@gmail.com> wrote:
My personal preference would be that we limit the scope of the X in
MMOX to systems that simulate some analogue of 3D physical space (not
necessarily continuous or simply-connected).  That way, if location addressing is within the scope, something like a global x,y,z can be
used and then vendors can easily map other schemes over that (or not)
as desired.

I think that it would be very bad to = exclude 2D worlds, Cenji.  There is no good reason to place a lower li= mit on the dimensionality of virtual worlds, nor an upper limit.  Inde= ed, 2D scrollers are still very popular, and have no less a right to addres= sing support without being treated as a degenerate case.

Likewise, higher-dimensioned spaces may well appear --- we're alrea= dy mapping a 3D scene onto a 2D screen after all, and a 4D timespace world = in which time is also addressable and navigateable is easily envisaged, as = are hyperspace worlds.  I don't think that we should impose any ar= bitrary restrictions on addressibility.

An address makes sense only in the context of a specific world, and the= refore it is misguided to attempt to straightjacket all worlds into a singl= e format.  Indeed, SL already employs 4 dimensions of addressibility i= n its live world, namely {region, a, y, z}, or 5 dimensions when you add {g= ridname} to account for its special-purpose grids such as the Teen Grid, Pr= eview Grid, OGP Beta Grid, and so on.  Therefore I suggest that addres= ses simply be tuples with an arbitrary number of terms, and that the number= of terms and their types should be entirely a matter for the world in ques= tion, and nobody else.

Morgaine.
--0015175caa9e5a6c0504624fc891-- From morgaine.dinova@googlemail.com Sat Feb 7 03:17:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 515EB3A69B8 for ; Sat, 7 Feb 2009 03:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLwwk9nir4Ro for ; Sat, 7 Feb 2009 03:17:11 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id C628E3A697D for ; Sat, 7 Feb 2009 03:17:10 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so494429qwe.31 for ; Sat, 07 Feb 2009 03:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UIdSNroDENT4F+w+fnYH7s5bGbl8zi+lpx8ZsgQNL7M=; b=kVwRegudd/42EUzLXQYZtrBmQk1B2UfEVYa1Z0qlmxXjMefNZUIeSQW1SJyDILZMAd adOX7CtqKTRX9qhnVwHN0vZmEbiuM4gvNasmX2f37llwfLa8wv5Ua2ByM+xqvbhtU1os rMwOGQc+a3RIKiuxUre+bpOaKuKxfGrYj16lo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZF+FqcJiR59B2SkZD0MI+Mre3txT4FjMFBJmdI5E9uElpAeAeD5o/vLMhTu2Zka+sL /5JlJGNsCQNYyZR0Nsnu95PO/DGBguHghnoGvF3RGjl/RE/44w10CJBnMCh5JOLgV+/2 F0dl5ZvX/r7FZi/Xwa7Vn+89LbzxlrmDso6JU= MIME-Version: 1.0 Received: by 10.214.44.6 with SMTP id r6mr4055826qar.105.1234005432257; Sat, 07 Feb 2009 03:17:12 -0800 (PST) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> Date: Sat, 7 Feb 2009 11:17:12 +0000 Message-ID: From: Morgaine Dinova To: "Hurliman, John" Content-Type: multipart/alternative; boundary=0015175cb1d470cd180462524726 Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 11:17:12 -0000 --0015175cb1d470cd180462524726 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 7, 2009 at 12:21 AM, Hurliman, John 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: > > Description of Working Group: > > 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: > > 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 > > 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. --0015175cb1d470cd180462524726 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 7, 2009 at 12:21 AM, Hurlima= n, John <jo= hn.hurliman@intel.com> wrote:
I have made changes to the draft group charter to make the language more ve= ndor neutral, and have changed the goals and milestones to be more vendor n= eutral 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 ar= e perfectly fine from my perspective, so I won't be suggesting any subs= tantive modifications.  (Note however the removal of the word "pr= oprietary" in the final paragraph, which may be substantive, depending= on what was intended --- I believe it was there simply by mistake, since t= he remainder of the paragraph did not address the subject).  I have ti= died up several English, grammatical or spelling details for the sake of be= tter presentation though, and I also have a comment to make about the timel= ine at the end:

Description of Working Group:

Virtual Worlds and other Massively Multi-Party Online Applications are of i= ncreasing 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 exp= ected to grow to beyond 50 million by 2011, creators of such systems have b= egun to look at ways to make such systems interoperate. There have been sev= eral 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 appl= ications, b) provide for access and exchange with other systems on the Inte= rnet 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 p= rotocols to communicate and interact with the state of Virtual World applic= ations. Foundational protocols will be evaluated for: 1) representing appli= cation layer objects and serializing messages between these objects, 2) pro= viding a messaging abstraction layer to support the unique needs of VW inte= ractions, and 3) authenticating protocol endpoints. An attempt will be made= to use existing standards wherever possible. For example, image data is ty= ped 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 comp= lete protocol, but the definition of a extensible core protocol with additi= onal layers of agreed functionality as they are developed. Because the foun= dational protocols can be deployed before the entire range of VW functions = is considered, we believe that the efforts of the MMOX working group are ac= hievable 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 Propo= sed Standard
February 2010 Rough consensus on a VW Authentication and VW Teleport protoc= ol
June 2010 Progression of VW Authentication to Proposed Standard
June 2010 Progression of VW Teleport to Proposed Standard

With regard to the above timeline (which I have left= intact for now), I would like to draw your attention to the third item, an= d to a matter that I pointed out in a previous post, which others have affi= rmed as well:  that our work is not tied to the specifics of Linden La= b's very particular implementation.

That implementation exposes the mapping of regions to individual machin= es and/or simulators, and hence conflates our very important notion of abst= ract communication endpoints with the very non-abstract and non-generic det= ails of their exposed machinery.  As a result, I do not believe that t= he publication of a specification for inter-simulator communication is in a= ny way related to our work here:  virtual worlds may not even have sim= ulators, 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 relat= ionship to the vendor-neutral, inter-world protocol suite that we are devel= oping here, and therefore while it may be a milestone for Linden Lab, it is= not one of ours.

Morgaine.
--0015175cb1d470cd180462524726-- From morgaine.dinova@googlemail.com Sat Feb 7 03:56:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EEF83A69B8; Sat, 7 Feb 2009 03:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3LY8q8bjfCV; Sat, 7 Feb 2009 03:56:29 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 1FFA33A697D; Sat, 7 Feb 2009 03:56:28 -0800 (PST) Received: by qyk4 with SMTP id 4so1731109qyk.13 for ; Sat, 07 Feb 2009 03:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=uIafm+ij0Vo3V8L8rRsNbClRmVX1nVxN6TJ7A5XOfGw=; b=sBtH4gnJCHvhi8L982a5E6ns9GJG6t8Y5GVOhwEXU4K4zI6yqAsRcfwlMiToHs+Zk7 m5ORLtA3j6us+zx4vcsy156SI0FXwUoZLQZW6KY1RzKXN61X+KgUgw42igQWHOurT9rT C0BpOym4LRW41ulZw6Q+/HHRpgTaDaPMBQpmw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XztZNmMjONKLJIo5pw91zTlcUUSsh5O93a/tA5qWDUSSgofBAq+Hx/YgxP9ecJwEbH dbqiwQalfYd0ULoLd0TJvdKzrMTIVRlaY7+EjBav5/Oyc7IMHrmCnMFMEEdJtx0nTMtG dvdV7/5dzbVwC6H6tMlcDzBRiG/CTiS5IjXRM= MIME-Version: 1.0 Received: by 10.214.183.15 with SMTP id g15mr127935qaf.163.1234007791181; Sat, 07 Feb 2009 03:56:31 -0800 (PST) In-Reply-To: References: Date: Sat, 7 Feb 2009 11:56:31 +0000 Message-ID: From: Morgaine Dinova To: David W Levine Content-Type: multipart/alternative; boundary=0015175d016a0b20e9046252d481 Cc: mmox-bounces@ietf.org, "mmox@ietf.org" Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 11:56:30 -0000 --0015175d016a0b20e9046252d481 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 6, 2009 at 11:04 PM, David W Levine wrote: > > Great to see you asking questions Lisa. > > Two separate issues. Trust, can be viewed as straightforward, but hard. We > have the usual kitbag of PKIX style solutions, which is good, in the sense > that tools like X.509, TLS and HTTPS give us good ways to manage > authenticating a remote node in the internet as someone we understand, but > bad, in the sense that large scale deployments of PKI based solutions are > expensive, and non trivial to manage. There has been a long, ongoing > discussion about applying X.509, and such to provide a basis for > establishing shared trust, and then layering policy based choices on top of > that. (What degree of trust, can I extend to a service which offers me this > trust token? things of that sort) > > I suggest that we stay well clear of the perceptual minefield that is the enumeration of trust and security benefits as marketing bullet points. Some very perceptive and well respected minds in the security area have highlighted in recent years the great disparity between the actual benefits provided by security mechanisms and the far higher but quite false sense of security that they generate. We're not marketeers (particularly of snake oil), so let's try to stick to objective technical benefits of the specific solutions that we propose, justifying those benefits as analytically as we can, and leave the debatable systemic merit of these mechanisms for others to advocate, probably incorrectly. Security is a very complex and challenging engineering problem, but security theater isn't engineering at all. Morgaine. --0015175d016a0b20e9046252d481 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 6, 2009 at 11:04 PM, David W= Levine <dwl@us.ibm.= com> wrote:

Great to see you asking questions = Lisa.  

Two separate issues. Trust, can be= viewed as straightforward, but hard. We have the usual kitbag of PKIX style soluti= ons, which is good, in the sense that tools like X.509, TLS and HTTPS give us good ways to manage authenticating a remote node in the internet as someone we understand, but bad, in the sense that large scale deployments of PKI based solutions are expensive, and non trivial to manage.  There has been a long, ongoing discussion about applying X.509, and such to provide a basis for establishing shared trust, and then layering policy based choic= es on top of that. (What degree of trust, can I extend to a service which offers me this trust token? things of that sort)

I suggest that we stay well clear of the perceptual = minefield that is the enumeration of trust and security benefits as marketi= ng bullet points.  Some very perceptive and well respected minds in th= e security area have highlighted in recent years the great disparity betwee= n the actual benefits provided by security mechanisms and the far higher bu= t quite false sense of security that they generate.

We're not marketeers (particularly of snake oil), so let's try = to stick to objective technical benefits of the specific solutions that we = propose, justifying those benefits as analytically as we can, and leave the= debatable systemic merit of these mechanisms for others to advocate, proba= bly incorrectly.

Security is a very complex and challenging engineering problem, but sec= urity theater isn't engineering at all.

Morgaine.
--0015175d016a0b20e9046252d481-- From infinity@lindenlab.com Sat Feb 7 09:42:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F093A689D for ; Sat, 7 Feb 2009 09:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W23xspDmTJfp for ; Sat, 7 Feb 2009 09:42:17 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 62EF33A6AFF for ; Sat, 7 Feb 2009 09:42:17 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id C0D303DBC074; Sat, 7 Feb 2009 09:42:19 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Morgaine Dinova In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-6-170785630 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Feb 2009 09:42:19 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 17:42:18 -0000 --Apple-Mail-6-170785630 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Right. our plan is to provide mechanism, but not policy, and certainly =20= not security theater. There is no way the developer of a protocol can =20= ensure that the user of that protocol will follow best practice in =20 terms of security. But I don't think the answer is to ignore security =20= concerns. In terms of security, we've already had significant conversations in =20 the AWG about domains of trust, or what's trying to trust what and =20 when. My sense is that it's worth enumerating these domains in a =20 protocol definition and provide default mechanisms to ensure trust. =20 For the trust domain that yields to PKIX/X.509 style solutions, X.509 =20= is convenient as 1) it's well defined, 2) there's a history of =20 identifying and fixing it's problems, and 3) it separates the policy =20 of key management (the policy of the certifying authority and explicit =20= roots trusted by a node) from the mechanism (PKIX, OCSP, etc.) So to recap... there are several different places where trust must be =20= defined. some of them will require host authentication. PKIX is a good =20= fit for these types of solutions. Deployers who want a "federated =20 trust" experience can deploy a full PKI, with all it's benefits and =20 drawbacks. Those who don't care can simply use self-signed =20 certificates and can explicitly trust "promiscuous" root certificates. That said... we should remember that we'll eventually need actual =20 proposals in the form internet drafts, or at least in the form of =20 "security concerns" sections of other drafts. Maybe we should add to the charter of the working group the =20 requirement that we identify trust domains and investigate options for =20= each domain. So... the domains identified in the past include: 1. host to host domain. this is the domain of "do i even trust the =20 host i'm connecting to." for some types of deployments, say a public =20 deployment like Second Life, the server components will decide to =20 trust each client host. for private, commercial deployments, the =20 operators may only want to trust a few select systems. 2. inter-object domain. so assuming you trust the host you're talking =20= to, if it's an endpoint for asset information, you may want to know =20 that the assets involved or it's meta-data is "trusted" somehow. or... =20= there have been at least a few proposals to encrypt assets. the reason =20= inter-object is different from host-to-host is that it is conceivable =20= that a trusted host may hold assets who's origin is unknown. while it =20= is (probably) outside the definition of any protocol we define here as =20= to what client applications will do with object-based trust =20 information, we should either define the format for trust or privacy =20 asset meta-data or identify how to add opaque information in asset =20 formats. -cheers -m/=E2=88=9E On Feb 7, 2009, at 3:56 AM, Morgaine Dinova wrote: > > > On Fri, Feb 6, 2009 at 11:04 PM, David W Levine =20 > wrote: > > Great to see you asking questions Lisa. > > Two separate issues. Trust, can be viewed as straightforward, but =20 > hard. We have the usual kitbag of PKIX style solutions, which is =20 > good, in the sense that tools like X.509, TLS and HTTPS give us good =20= > ways to manage authenticating a remote node in the internet as =20 > someone we understand, but bad, in the sense that large scale =20 > deployments of PKI based solutions are expensive, and non trivial to =20= > manage. There has been a long, ongoing discussion about applying X.=20= > 509, and such to provide a basis for establishing shared trust, and =20= > then layering policy based choices on top of that. (What degree of =20 > trust, can I extend to a service which offers me this trust token? =20 > things of that sort) > > I suggest that we stay well clear of the perceptual minefield that =20 > is the enumeration of trust and security benefits as marketing =20 > bullet points. Some very perceptive and well respected minds in the =20= > security area have highlighted in recent years the great disparity =20 > between the actual benefits provided by security mechanisms and the =20= > far higher but quite false sense of security that they generate. > > We're not marketeers (particularly of snake oil), so let's try to =20 > stick to objective technical benefits of the specific solutions that =20= > we propose, justifying those benefits as analytically as we can, and =20= > leave the debatable systemic merit of these mechanisms for others to =20= > advocate, probably incorrectly. > > Security is a very complex and challenging engineering problem, but =20= > security theater isn't engineering at all. > > Morgaine. > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-6-170785630 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right. our plan is to provide = mechanism, but not policy, and certainly not security theater. There is = no way the developer of a protocol can ensure that the user of that = protocol will follow best practice in terms of security. But I don't = think the answer is to ignore security concerns.

In = terms of security, we've already had significant conversations in the = AWG about domains of trust, or what's trying to trust what and when. My = sense is that it's worth enumerating these domains in a protocol = definition and provide default mechanisms to ensure trust. For the trust = domain that yields to PKIX/X.509 style solutions, X.509 is convenient as = 1) it's well defined, 2) there's a history of identifying and fixing = it's problems, and 3) it separates the policy of key management (the = policy of the certifying authority and explicit roots trusted by a node) = from the mechanism (PKIX, OCSP, etc.)

So to = recap... there are several different places where trust must be defined. = some of them will require host authentication. PKIX is a good fit for = these types of solutions. Deployers who want a "federated trust" = experience can deploy a full PKI, with all it's benefits and drawbacks. = Those who don't care can simply use self-signed certificates and can = explicitly trust "promiscuous" root = certificates.

That said... we should remember = that we'll eventually need actual proposals in the form internet drafts, = or at least in the form of "security concerns" sections of other = drafts.

Maybe we should add to the charter of = the working group the requirement that we identify trust domains and = investigate options for each domain. So... the domains identified in the = past include:

1. host to host domain. this is = the domain of "do i even trust the host i'm connecting to." for some = types of deployments, say a public deployment like Second Life, the = server components will decide to trust each client host. for private, = commercial deployments, the operators may only want to trust a few = select systems.

2. inter-object domain. so = assuming you trust the host you're talking to, if it's an endpoint for = asset information, you may want to know that the assets involved or it's = meta-data is "trusted" somehow. or... there have been at least a few = proposals to encrypt assets. the reason inter-object is different from = host-to-host is that it is conceivable that a trusted host may hold = assets who's origin is unknown. while it is (probably) outside the = definition of any protocol we define here as to what client applications = will do with object-based trust information, we should either define the = format for trust or privacy asset meta-data or identify how to add = opaque information in asset = formats.

-cheers
-m/=E2=88=9E
<= div>
On Feb 7, 2009, at 3:56 AM, Morgaine Dinova = wrote:



On Fri, Feb 6, 2009 at = 11:04 PM, David W Levine <dwl@us.ibm.com> = wrote:

Great to see you asking = questions Lisa.  

Two separate issues. Trust, can be viewed as straightforward, = but hard. We have the usual kitbag of PKIX style solutions, which is = good, in the sense that tools like X.509, TLS and HTTPS give us good = ways to manage authenticating a remote node in the internet as someone = we understand, but bad, in the sense that large scale deployments of PKI = based solutions are expensive, and non trivial to manage.  There = has been a long, ongoing discussion about applying X.509, and such to = provide a basis for establishing shared trust, and then layering policy = based choices on top of that. (What degree of trust, can I extend to a = service which offers me this trust token? things of that sort) =

I suggest that we stay well clear of the = perceptual minefield that is the enumeration of trust and security = benefits as marketing bullet points.  Some very perceptive and well = respected minds in the security area have highlighted in recent years = the great disparity between the actual benefits provided by security = mechanisms and the far higher but quite false sense of security that = they generate.

We're not marketeers (particularly of snake oil), = so let's try to stick to objective technical benefits of the specific = solutions that we propose, justifying those benefits as analytically as = we can, and leave the debatable systemic merit of these mechanisms for = others to advocate, probably incorrectly.

Security is a very = complex and challenging engineering problem, but security theater isn't = engineering at all.

Morgaine.
= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mmox

= --Apple-Mail-6-170785630-- From infinity@lindenlab.com Sat Feb 7 09:50:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42C253A6CD6 for ; Sat, 7 Feb 2009 09:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoTCSNFHjwKg for ; Sat, 7 Feb 2009 09:50:38 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id E0B223A6CB6 for ; Sat, 7 Feb 2009 09:50:38 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 1FE123DBC074; Sat, 7 Feb 2009 09:50:42 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Morgaine Dinova In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-7-171287811 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Feb 2009 09:50:41 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 17:50:40 -0000 --Apple-Mail-7-171287811 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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 > 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: > > Description of Working Group: > > 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: > > 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 > > 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. > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-7-171287811 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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 = <john.hurliman@intel.com> 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:
=

= Description of Working Group:

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:

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
=
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.
= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mmox

= --Apple-Mail-7-171287811-- From jack@martinelli.org Sat Feb 7 12:32:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6913A682B for ; Sat, 7 Feb 2009 12:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhjIKugQpq9U for ; Sat, 7 Feb 2009 12:32:26 -0800 (PST) Received: from 95228-web1.designerscience.com (unknown [72.32.122.42]) by core3.amsl.com (Postfix) with ESMTP id D9D933A6D1D for ; Sat, 7 Feb 2009 12:31:54 -0800 (PST) Received: (qmail 2897 invoked from network); 7 Feb 2009 14:31:57 -0600 Received: from localhost (127.0.0.1) by localhost with SMTP; 7 Feb 2009 14:31:57 -0600 Received: from host-206-206-59-29.ns1.spro.net (host-206-206-59-29.ns1.spro.net [206.206.59.29]) by webmail.martinelli.org (Horde MIME library) with HTTP; Sat, 7 Feb 2009 14:31:57 -0600 Message-ID: <20090207143157.93idprlj0gsckogw@webmail.martinelli.org> Date: Sat, 7 Feb 2009 14:31:57 -0600 From: jack@martinelli.org To: mmox@ietf.org References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1) Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 20:32:27 -0000 Quoting "Hurliman, John" : > I have made changes to the draft group charter .... > The objective of the MMOX working group is to provide an =20 > application-layer wire protocol for Virtual Worlds to a) enable =20 > interoperability between applications, b) provide for access and =20 > exchange with other systems on the internet such as identity =20 > providers, web services, e-mail and other information storage =20 > systems, c) allow network layers to recognize VW traffic and make =20 > routing decisions based on its characteristics. Just a nit... an application-layer protocol isn't a wire protocol. =20 You probably want to stay away from using "wire protocol" cuz it might =20 sound to to guys like me that you want to replace all the hardware or =20 NIC firmware on the whole www. Application layer might be need refinement as well. I'm thinking more =20 like a 2-layer client layer. I'd divide it like so... scriptable VW layer VWP =3D VW ports - non-host protocol ports (something like those =20 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, =20 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 =20 all the same requiremnts of any OS. It's a resource manager. =20 Possibly this should be divided as well into a massively distributed =20 OS and MMOX? see : http://en.wikipedia.org/wiki/MOSIX and http://en.wikipedia.org/wiki/LinuxPMI From infinity@lindenlab.com Sat Feb 7 13:01:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2F493A6948 for ; Sat, 7 Feb 2009 13:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgJKNTXT3jl4 for ; Sat, 7 Feb 2009 13:01:35 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 9C6353A68A7 for ; Sat, 7 Feb 2009 13:01:35 -0800 (PST) Received: from [192.168.1.241] (c-67-169-8-206.hsd1.ca.comcast.net [67.169.8.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id B38451414004; Sat, 7 Feb 2009 13:01:38 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: jack@martinelli.org In-Reply-To: <20090207143157.93idprlj0gsckogw@webmail.martinelli.org> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Feb 2009 13:01:38 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <20090207143157.93idprlj0gsckogw@webmail.martinelli.org> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 21:01:36 -0000 when i say "application layer," i'm referring to things above the =20 transport in terms of TCP/IP and above the presentation layer in the =20 OSI model. and when i say "wire protocol," i'm referring to PDUs that move across =20= the wire. thus, i think we should be ignoring issues of software =20 architecture and internal messaging infrastructure while making an =20 application layer protocol that is independent of implementation =20 language or even presentation or transport. that is, i would hope we =20 could define a protocol that does not REQUIRE a specific transport, =20 session management infrastructure or message serialization scheme. =20 that being said... LL and the OpenSim community have been focusing on =20= messages sent over HTTP(S) over TCP or a custom message format over =20 UDP, and i think we SHOULD focus on these transports... there's a fair =20= amount of experience with them and working implementations. but =20 there's been persistent discussion of other transports and =20 serialization schemes, so creating a system that was dependent on =20 HTTP(S) over TCP seems a bit like shooting yourself in the foot in =20 terms of extensibility. so... sorry for the confusion... i was using the term "wire protocol" =20= to describe things that get put in PDUs and transmitted over a network =20= as distinct from the data structures and software that interpret the =20 semantics of application layer PDUs. MMOX could be seen as the core of a massively distributed operating =20 system, but that is not it's focus. i'm a touch nervous bringing =20 discussions of scripting languages or operating systems into the MMOX =20= charter. that being said... many of the application layer objects =20 we're talking about will be scriptable, and there's no reason to =20 REQUIRE the use of LSL or MONO (or ECMAScript or ... ) in the spec. =20 but there are probably very good reasons to be able to communicate =20 metadata about objects (including the language of scripts) in MIME =20 types or some similar mechanism. -cheers -m/=E2=88=9E On Feb 7, 2009, at 12:31 PM, jack@martinelli.org wrote: > Quoting "Hurliman, John" : > >> I have made changes to the draft group charter > > > .... >> The objective of the MMOX working group is to provide an =20 >> application-layer wire protocol for Virtual Worlds to a) enable =20 >> interoperability between applications, b) provide for access and =20 >> exchange with other systems on the internet such as identity =20 >> providers, web services, e-mail and other information storage =20 >> systems, c) allow network layers to recognize VW traffic and make =20= >> routing decisions based on its characteristics. > > Just a nit... an application-layer protocol isn't a wire protocol. =20= > You probably want to stay away from using "wire protocol" cuz it =20 > might sound to to guys like me that you want to replace all the =20 > hardware or NIC firmware on the whole www. > > Application layer might be need refinement as well. I'm thinking =20 > more like a 2-layer client layer. I'd divide it like so... > > scriptable VW layer > VWP =3D VW ports - non-host protocol ports (something like those =20 > 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 =20 > 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 =20= > all the same requiremnts of any OS. It's a resource manager. =20 > Possibly this should be divided as well into a massively distributed =20= > OS and MMOX? see : > > http://en.wikipedia.org/wiki/MOSIX > and > http://en.wikipedia.org/wiki/LinuxPMI > > > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From morgaine.dinova@googlemail.com Sat Feb 7 13:36:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6684E3A6B4F for ; Sat, 7 Feb 2009 13:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaV-bPNDZeFH for ; Sat, 7 Feb 2009 13:36:02 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 081253A6765 for ; Sat, 7 Feb 2009 13:36:01 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so553218qwe.31 for ; Sat, 07 Feb 2009 13:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NmXz5jNWhC4BDxE0eCl8mbUVzv7Jt0c+ujOG5zJCcVU=; b=jilGHZTMf1DB2K4eTRGLVFg+mOC/4WC4OqZd85it3lq6p4qFuXlkSllaAye94n0+ne ka1at9ObWA6qpnUHDKwMcMggUB3D8A/bSdLEPre1eWh4lSowA+SW8yLDd25CHhNXFoQs vRxJycAG50K85KsifV1JUa3BF4sWdUSFWDlsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xKccrv8FUFuIt7w9pNwWlws1PK2TOCQiZE2RdZmtPyBdaeU7BuyYIpBwEz1aIUCMyN //e7BOJWn4OiGrz3Ikd/bAaWZeATLPuFKmKkZEUcI3hVE71Fb4plvIrIl3I0Blv5BrVH 9z0HpcA1LhDNlWzxGTF+vYLMgtfedO5UueUm0= MIME-Version: 1.0 Received: by 10.215.100.1 with SMTP id c1mr4641093qam.113.1234042564612; Sat, 07 Feb 2009 13:36:04 -0800 (PST) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> Date: Sat, 7 Feb 2009 21:36:04 +0000 Message-ID: From: Morgaine Dinova To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=0015175cbac8b3942e04625aec8a Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 21:36:03 -0000 --0015175cbac8b3942e04625aec8a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 7, 2009 at 5:50 PM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> 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. --0015175cbac8b3942e04625aec8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 7, 2009 at 5:50 PM, Meadhbh = Hamrick (Infinity) <infinity@lindenlab.com> wrote:
huh? the word "proprietary" in the last paragraph= said that the work will NOT be the blessing of an existing proprietary pro= tocol. the reason it is there is to explicitly call out the fact that the w= ork of the MMOX group is NOT to simply define the existing SecondLife proto= col and put an IETF rubber stamp on it. i am hoping we all share that objec= tive.

Of course we share that objective.  But you'= re missing the NEW logic of that paragraph:  OGP was referred to in th= e previous version and is not in the new one, and therefore any mention of = "proprietary protocol" is completely out of context and meaningle= ss after these edits --- try rereading the paragraph without remembering th= at 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 ref= erred to before, since OGP is certainly not a "complete" one (bar= ely an initial fragment) and therefore we couldn't be trying to standar= dize it even with the old wording.  The whole new semantic just become= s bizarre with that word in there.

Of course, the intent might have been simply to say that we're work= ing 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 purpo= se of that word (and that's why I put the disclaimer "may be subst= antive" in my introduction), then we should affirm that positively, ra= ther than saying that we are NOT creating a proprietary protocol.

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

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

Morgaine.
=
--0015175cbac8b3942e04625aec8a-- From morgaine.dinova@googlemail.com Sat Feb 7 14:09:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEF5D3A6B89 for ; Sat, 7 Feb 2009 14:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VP5lVkK7xpX for ; Sat, 7 Feb 2009 14:09:15 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id BD2B93A684A for ; Sat, 7 Feb 2009 14:09:14 -0800 (PST) Received: by qyk4 with SMTP id 4so1914393qyk.13 for ; Sat, 07 Feb 2009 14:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zQoGS4cO885OmGYNWLqsH9afoXRk54D0wmjbK7ZEX1U=; b=k/ZC6vYDzDfcf27/7SWQr2jgkkfXUOwF+F5ibkVucGri96xl+NbM4eGcBosbujobX4 c3u0oWBeKmo+WcT5jvz2hz+M8/FbIyrw5mhX1cYROcLbyPGrNlG2h+2viQ1KPOrSJbP2 p4KuOdg8UOSuAzMyVjWHTTLADfihT0rJ7UMuQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QvkQOlRO7V1xN+rzuDRhFzrBLuZVBxIXNlWVGhvtgSxobs0FzYT8wrbiYr8BB4tn5E mpIYnxh3DKoE+7VCD7cR742S94Ohlrd58B94TlrCGAqtyqhJnOjToBY1tN5epNLVX9ar q/m9AhK2++xHcWlvzVhjPLInVXFxiM42eIKc4= MIME-Version: 1.0 Received: by 10.214.114.6 with SMTP id m6mr4656760qac.122.1234044557469; Sat, 07 Feb 2009 14:09:17 -0800 (PST) In-Reply-To: <498C7CCE.4040309@lindenlab.com> References: <498C7CCE.4040309@lindenlab.com> Date: Sat, 7 Feb 2009 22:09:17 +0000 Message-ID: From: Morgaine Dinova To: Rob Lanphier Content-Type: multipart/alternative; boundary=0015175cf7127c2a3404625b63e7 Cc: "mmox@ietf.org" Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF session (Draft Charter) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 22:09:15 -0000 --0015175cf7127c2a3404625b63e7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 6, 2009 at 6:09 PM, Rob Lanphier wrote: > You'll see from the draft that LLSD is being proposed as Informational > track. That doesn't preclude the creation of a future specification, > also called LLSD, that is a standards track specification, but that's > going to be something that the proposed working group can sort out. > > Given how widely used LLSD is already in several independent > implementations, it seems like it's at least worthy of an Informational > RFC and a MIME-type registration, no? > Highly worthy, Rob! :-) What's more, since it is the technical issues that matter to us most here, the fact that Linden Lab appears in a protocol name barely registers on the importance radar at all, except possibly to yourselves if you want to see LLSD adopted as a standard even by your competitors. It's not an issue as far as I am concerned, as long as the standard is totally unencumbered for use in the virtual world community or any purpose. What would be an issue though would be LL's production LLSD acting as a brake on modifications of the serialization format that might be required by this workgroup for the purposes of extensibility. Since you have explained that LLSD is free to evolve if needed (and it may not even be needed), I do not forsee a problem at this time. If LLSD is modified by us then you will have to tackle versioning if the old name is retained, but that's not a showstopper. Morgaine. --0015175cf7127c2a3404625b63e7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 6, 2009 at 6:09 PM, Rob Lanp= hier <robla@lin= denlab.com> wrote:
You'll see from the draft that LLSD is being proposed as Informational<= br> track.  That doesn't preclude the creation of a future specificati= on,
also called LLSD, that is a standards track specification, but that's going to be something that the proposed working group can sort out.

Given how widely used LLSD is already in several independent
implementations, it seems like it's at least worthy of an Informational=
RFC and a MIME-type registration, no?
 
Highly worthy, R= ob! :-)

What's more, since it is the technical issues that matte= r to us most here, the fact that Linden Lab appears in a protocol name bare= ly registers on the importance radar at all, except possibly to yourselves = if you want to see LLSD adopted as a standard even by your competitors.&nbs= p; It's not an issue as far as I am concerned, as long as the standard = is totally unencumbered for use in the virtual world community or any purpo= se.

What would be an issue though would be LL's production LLSD acting = as a brake on modifications of the serialization format that might be requi= red by this workgroup for the purposes of extensibility.  Since you ha= ve explained that LLSD is free to evolve if needed (and it may not even be = needed), I do not forsee a problem at this time.

If LLSD is modified by us then you will have to tackle versioning if th= e old name is retained, but that's not a showstopper.

Morgaine.<= br>
--0015175cf7127c2a3404625b63e7-- From morgaine.dinova@googlemail.com Sat Feb 7 14:30:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9F1C3A6A2A for ; Sat, 7 Feb 2009 14:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.024 X-Spam-Level: X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXazI3ICoe1w for ; Sat, 7 Feb 2009 14:30:29 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id B7CC43A6B5E for ; Sat, 7 Feb 2009 14:30:28 -0800 (PST) Received: by qyk4 with SMTP id 4so1920467qyk.13 for ; Sat, 07 Feb 2009 14:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WJ7xtC8ZvnwBTDTlIfYYlvtNrcdvsqG28QfA/QYvVgA=; b=UVB/RBwXOYv3tAdQ4og0g8cZrSdGPBoqfR9kJdOyMOg3N4tuNPBNpIzpBnC0NSw4r8 uG1Gs9y/buUMTsm6rlZjSMSCAkHUpw2JdjNZjhtLVrZJLU1FQpsXsFXULbz63dNObIAx LLulY6P/wNiZ6JSkRR5kmQLAE4Ax71KB4afD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=odQ5UHSEMWlvHZAYNg8ub4WTPtensA10auUpjYvjyWEROy9fM3cmeEEw9anTBVpMrL CIPfiPK6PRX2NEBysj2NNVZKcEUiUKbGDeAVEgwcQn3qDoIcyJf077GAUxxSQ50lU40G 2Cp0hjEI1k6ozW1PiwYfQdO59MYtpqsuAlDqM= MIME-Version: 1.0 Received: by 10.215.15.2 with SMTP id s2mr1180437qai.324.1234045831024; Sat, 07 Feb 2009 14:30:31 -0800 (PST) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <20090207143157.93idprlj0gsckogw@webmail.martinelli.org> Date: Sat, 7 Feb 2009 22:30:30 +0000 Message-ID: From: Morgaine Dinova To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=0015175cb86c6510ce04625bafad Cc: mmox@ietf.org Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2009 22:30:30 -0000 --0015175cb86c6510ce04625bafad Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit 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) < infinity@lindenlab.com> 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/$B!g(B > > > On Feb 7, 2009, at 12:31 PM, jack@martinelli.org wrote: > > Quoting "Hurliman, John" : >> >> 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 >> >> >> >> >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --0015175cb86c6510ce04625bafad Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: base64 WW91JiMzOTtyZSBhY3R1YWxseSBib3RoIHJpZ2h0LCBJbmZpbml0eSBpbiBkZXNjcmliaW5nIHdo YXQgd2UmIzM5O3JlIGRvaW5nLCBhbmQgSmFjayBpbiBpZGVudGlmeWluZyB0aGF0IHRoZSBwaHJh c2UgJnF1b3Q7YXBwbGljYXRpb24tbGF5ZXIgd2lyZSBwcm90b2NvbCZxdW90OyBpcyBub3QgdmVy eSB3ZWxsIGNob3NlbiAtLS0gSSB0b28gcmFpc2VkIGFuIGV5ZWJyb3cgb24gZmlyc3QgcmVhZCwg YnV0IEkgbGV0IGl0IHBhc3Mgb24gdGhlIGJhc2lzIG9mICZxdW90O3dlbGwgd2Uga25vdyB3aGF0 IHdlIG1lYW4mcXVvdDsuIDstKTxicj4KPGJyPkhvdyBhYm91dCBmaXhpbmcgdGhlIHNlbnRlbmNl IGJ5IHJlcGxhY2luZyAmcXVvdDthcHBsaWNhdGlvbi1sYXllciB3aXJlIHByb3RvY29sJnF1b3Q7 IGJ5ICZxdW90O2FwcGxpY2F0aW9uLWxheWVyIGFuZCBvbi10aGUtd2lyZSBwcm90b2NvbHMmcXVv dDssIGFuZCB0aGVuIGZvbGxvd2luZyB1cCBieSBhZGRpbmcgYW4gb24tdGhlLXdpcmUgaWxsdXN0 cmF0aW9uIG9mIGEgdHlwaWNhbCBleGNoYW5nZSBhcyBzdXBwb3J0aW5nIG1hdGVyaWFsPyZuYnNw OyBJdCB3b3VsZCBpbXByb3ZlIHRoZSBkb2N1bWVudGF0aW9uIHRvby48YnI+Cjxicj5Nb3JnYWlu ZS48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBTYXQsIEZlYiA3LCAyMDA5IGF0 IDk6MDEgUE0sIE1lYWRoYmggSGFtcmljayAoSW5maW5pdHkpIDxzcGFuIGRpcj0ibHRyIj4mbHQ7 PGEgaHJlZj0ibWFpbHRvOmluZmluaXR5QGxpbmRlbmxhYi5jb20iPmluZmluaXR5QGxpbmRlbmxh Yi5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBt YXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsiPgp3aGVuIGkgc2F5 ICZxdW90O2FwcGxpY2F0aW9uIGxheWVyLCZxdW90OyBpJiMzOTttIHJlZmVycmluZyB0byB0aGlu Z3MgYWJvdmUgdGhlIHRyYW5zcG9ydCBpbiB0ZXJtcyBvZiBUQ1AvSVAgYW5kIGFib3ZlIHRoZSBw cmVzZW50YXRpb24gbGF5ZXIgaW4gdGhlIE9TSSBtb2RlbC48YnI+Cjxicj4KYW5kIHdoZW4gaSBz YXkgJnF1b3Q7d2lyZSBwcm90b2NvbCwmcXVvdDsgaSYjMzk7bSByZWZlcnJpbmcgdG8gUERVcyB0 aGF0IG1vdmUgYWNyb3NzIHRoZSB3aXJlLiB0aHVzLCBpIHRoaW5rIHdlIHNob3VsZCBiZSBpZ25v cmluZyBpc3N1ZXMgb2Ygc29mdHdhcmUgYXJjaGl0ZWN0dXJlIGFuZCBpbnRlcm5hbCBtZXNzYWdp bmcgaW5mcmFzdHJ1Y3R1cmUgd2hpbGUgbWFraW5nIGFuIGFwcGxpY2F0aW9uIGxheWVyIHByb3Rv Y29sIHRoYXQgaXMgaW5kZXBlbmRlbnQgb2YgaW1wbGVtZW50YXRpb24gbGFuZ3VhZ2Ugb3IgZXZl biBwcmVzZW50YXRpb24gb3IgdHJhbnNwb3J0LiB0aGF0IGlzLCBpIHdvdWxkIGhvcGUgd2UgY291 bGQgZGVmaW5lIGEgcHJvdG9jb2wgdGhhdCBkb2VzIG5vdCBSRVFVSVJFIGEgc3BlY2lmaWMgdHJh bnNwb3J0LCBzZXNzaW9uIG1hbmFnZW1lbnQgaW5mcmFzdHJ1Y3R1cmUgb3IgbWVzc2FnZSBzZXJp YWxpemF0aW9uIHNjaGVtZS4gdGhhdCBiZWluZyBzYWlkLi4uIExMIGFuZCB0aGUgT3BlblNpbSBj b21tdW5pdHkgaGF2ZSBiZWVuIGZvY3VzaW5nIG9uIG1lc3NhZ2VzIHNlbnQgb3ZlciBIVFRQKFMp IG92ZXIgVENQIG9yIGEgY3VzdG9tIG1lc3NhZ2UgZm9ybWF0IG92ZXIgVURQLCBhbmQgaSB0aGlu ayB3ZSBTSE9VTEQgZm9jdXMgb24gdGhlc2UgdHJhbnNwb3J0cy4uLiB0aGVyZSYjMzk7cyBhIGZh aXIgYW1vdW50IG9mIGV4cGVyaWVuY2Ugd2l0aCB0aGVtIGFuZCB3b3JraW5nIGltcGxlbWVudGF0 aW9ucy4gYnV0IHRoZXJlJiMzOTtzIGJlZW4gcGVyc2lzdGVudCBkaXNjdXNzaW9uIG9mIG90aGVy IHRyYW5zcG9ydHMgYW5kIHNlcmlhbGl6YXRpb24gc2NoZW1lcywgc28gY3JlYXRpbmcgYSBzeXN0 ZW0gdGhhdCB3YXMgZGVwZW5kZW50IG9uIEhUVFAoUykgb3ZlciBUQ1Agc2VlbXMgYSBiaXQgbGlr ZSBzaG9vdGluZyB5b3Vyc2VsZiBpbiB0aGUgZm9vdCBpbiB0ZXJtcyBvZiBleHRlbnNpYmlsaXR5 Ljxicj4KCjxicj4Kc28uLi4gc29ycnkgZm9yIHRoZSBjb25mdXNpb24uLi4gaSB3YXMgdXNpbmcg dGhlIHRlcm0gJnF1b3Q7d2lyZSBwcm90b2NvbCZxdW90OyB0byBkZXNjcmliZSB0aGluZ3MgdGhh dCBnZXQgcHV0IGluIFBEVXMgYW5kIHRyYW5zbWl0dGVkIG92ZXIgYSBuZXR3b3JrIGFzIGRpc3Rp bmN0IGZyb20gdGhlIGRhdGEgc3RydWN0dXJlcyBhbmQgc29mdHdhcmUgdGhhdCBpbnRlcnByZXQg dGhlIHNlbWFudGljcyBvZiBhcHBsaWNhdGlvbiBsYXllciBQRFVzLjxicj4KCjxicj4KTU1PWCBj b3VsZCBiZSBzZWVuIGFzIHRoZSBjb3JlIG9mIGEgbWFzc2l2ZWx5IGRpc3RyaWJ1dGVkIG9wZXJh dGluZyBzeXN0ZW0sIGJ1dCB0aGF0IGlzIG5vdCBpdCYjMzk7cyBmb2N1cy4gaSYjMzk7bSBhIHRv dWNoIG5lcnZvdXMgYnJpbmdpbmcgJm5ic3A7ZGlzY3Vzc2lvbnMgb2Ygc2NyaXB0aW5nIGxhbmd1 YWdlcyBvciBvcGVyYXRpbmcgc3lzdGVtcyBpbnRvIHRoZSBNTU9YIGNoYXJ0ZXIuIHRoYXQgYmVp bmcgc2FpZC4uLiBtYW55IG9mIHRoZSBhcHBsaWNhdGlvbiBsYXllciBvYmplY3RzIHdlJiMzOTty ZSB0YWxraW5nIGFib3V0IHdpbGwgYmUgc2NyaXB0YWJsZSwgYW5kIHRoZXJlJiMzOTtzIG5vIHJl YXNvbiB0byBSRVFVSVJFIHRoZSB1c2Ugb2YgTFNMIG9yIE1PTk8gKG9yIEVDTUFTY3JpcHQgb3Ig Li4uICkgaW4gdGhlIHNwZWMuIGJ1dCB0aGVyZSBhcmUgcHJvYmFibHkgdmVyeSBnb29kIHJlYXNv bnMgdG8gYmUgYWJsZSB0byBjb21tdW5pY2F0ZSBtZXRhZGF0YSBhYm91dCBvYmplY3RzIChpbmNs dWRpbmcgdGhlIGxhbmd1YWdlIG9mIHNjcmlwdHMpIGluIE1JTUUgdHlwZXMgb3Igc29tZSBzaW1p bGFyIG1lY2hhbmlzbS48YnI+Cgo8YnI+Ci1jaGVlcnM8YnI+PGZvbnQgY29sb3I9IiM4ODg4ODgi PgotbS8bJEIhZxsoQjwvZm9udD48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iV2ozQzdjIj48 YnI+Cjxicj4KT24gRmViIDcsIDIwMDksIGF0IDEyOjMxIFBNLCA8YSBocmVmPSJtYWlsdG86amFj a0BtYXJ0aW5lbGxpLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmphY2tAbWFydGluZWxsaS5vcmc8L2E+ IHdyb3RlOjxicj4KPGJyPgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJi b3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0 IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4KUXVvdGluZyAmcXVvdDtIdXJsaW1hbiwg Sm9obiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvaG4uaHVybGltYW5AaW50ZWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+am9obi5odXJsaW1hbkBpbnRlbC5jb208L2E+Jmd0Ozo8YnI+Cjxicj4K PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBz b2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRp bmctbGVmdDogMWV4OyI+CkkgaGF2ZSBtYWRlIGNoYW5nZXMgdG8gdGhlIGRyYWZ0IGdyb3VwIGNo YXJ0ZXI8YnI+CjwvYmxvY2txdW90ZT4KPGJyPgo8YnI+Ci4uLi48YnI+CjxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwg MjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsi PgpUaGUgb2JqZWN0aXZlIG9mIHRoZSBNTU9YIHdvcmtpbmcgZ3JvdXAgaXMgdG8gcHJvdmlkZSBh biAmbmJzcDthcHBsaWNhdGlvbi1sYXllciB3aXJlIHByb3RvY29sIGZvciBWaXJ0dWFsIFdvcmxk cyB0byBhKSBlbmFibGUgJm5ic3A7aW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGFwcGxpY2F0aW9u cywgYikgcHJvdmlkZSBmb3IgYWNjZXNzIGFuZCAmbmJzcDtleGNoYW5nZSB3aXRoIG90aGVyIHN5 c3RlbXMgb24gdGhlIGludGVybmV0IHN1Y2ggYXMgaWRlbnRpdHkgJm5ic3A7cHJvdmlkZXJzLCB3 ZWIgc2VydmljZXMsIGUtbWFpbCBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc3RvcmFnZSAmbmJzcDtz eXN0ZW1zLCBjKSBhbGxvdyBuZXR3b3JrIGxheWVycyB0byByZWNvZ25pemUgVlcgdHJhZmZpYyBh bmQgbWFrZSAmbmJzcDtyb3V0aW5nIGRlY2lzaW9ucyBiYXNlZCBvbiBpdHMgY2hhcmFjdGVyaXN0 aWNzLjxicj4KCjwvYmxvY2txdW90ZT4KPGJyPgpKdXN0IGEgbml0Li4uIGFuIGFwcGxpY2F0aW9u LWxheWVyIHByb3RvY29sIGlzbiYjMzk7dCBhIHdpcmUgcHJvdG9jb2wuICZuYnNwO1lvdSBwcm9i YWJseSB3YW50IHRvIHN0YXkgYXdheSBmcm9tIHVzaW5nICZxdW90O3dpcmUgcHJvdG9jb2wmcXVv dDsgY3V6IGl0IG1pZ2h0IHNvdW5kIHRvIHRvIGd1eXMgbGlrZSBtZSB0aGF0IHlvdSB3YW50IHRv IHJlcGxhY2UgYWxsIHRoZSBoYXJkd2FyZSBvciBOSUMgZmlybXdhcmUgb24gdGhlIHdob2xlIHd3 dy48YnI+Cgo8YnI+CkFwcGxpY2F0aW9uIGxheWVyIG1pZ2h0IGJlIG5lZWQgcmVmaW5lbWVudCBh cyB3ZWxsLiAmbmJzcDtJJiMzOTttIHRoaW5raW5nIG1vcmUgbGlrZSBhIDItbGF5ZXIgY2xpZW50 IGxheWVyLiAmbmJzcDtJJiMzOTtkIGRpdmlkZSBpdCBsaWtlIHNvLi4uPGJyPgo8YnI+CnNjcmlw dGFibGUgVlcgbGF5ZXI8YnI+CiAmbmJzcDtWV1AgPSBWVyBwb3J0cyAtIG5vbi1ob3N0IHByb3Rv Y29sIHBvcnRzIChzb21ldGhpbmcgbGlrZSB0aG9zZSB1c2VkIGluIFNMJiMzOTtzIC0gbGxMaXN0 ZW4sIGxsU2F5KTxicj4KICZuYnNwO2hvc3QtcHJvdG9jb2wgcG9ydHMgLSBUQ1AvSVAgKHllcyB3 ZSBoYXZlIHRvIHVzZSB0aGlzKTxicj4KPGJyPgpNTU9YIGxheWVyIHB1Ymxpc2hlZCBBUEkgc28g dGhhdCB2ZW5kb3JzIG1heSBpbXBsZW1lbnQgdGhlaXIgb3duIFZXJiMzOTtzLCBnYW1lcywgbGFu Z3VhZ2VzIGV0Yy48YnI+Cjxicj4KICZuYnNwO2ltcGxlbWVudHMgbm9uLWhvc3QgcHJvdG9jb2wg cG9ydHMgdXNlZCBieSBzY3JpcHRhYmxlIGxheWVyLjxicj4KPGJyPgpJIHNlZSB0aGUgTU1PWCBs YXllciBhcyB0aGUgY29yZSBvZiBhIG1hc3NpdmVseSBkaXN0cmlidXRlZCBPUyB3aXRoIGFsbCB0 aGUgc2FtZSByZXF1aXJlbW50cyBvZiBhbnkgT1MuICZuYnNwO0l0JiMzOTtzIGEgcmVzb3VyY2Ug bWFuYWdlci4gJm5ic3A7UG9zc2libHkgdGhpcyBzaG91bGQgYmUgZGl2aWRlZCBhcyB3ZWxsIGlu dG8gYSBtYXNzaXZlbHkgZGlzdHJpYnV0ZWQgT1MgYW5kIE1NT1g/IHNlZSA6PGJyPgoKPGJyPgo8 YSBocmVmPSJodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL01PU0lYIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9NT1NJWDwvYT48YnI+CmFuZDxicj4KPGEg aHJlZj0iaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9MaW51eFBNSSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvTGludXhQTUk8L2E+PGJyPgo8YnI+Cjxi cj4KPGJyPgo8YnI+Cjxicj4KPGJyPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4KbW1veCBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzpt bW94QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW1veEBpZXRmLm9yZzwvYT48YnI+CjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW1veCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW1veDwvYT48YnI+ CjwvYmxvY2txdW90ZT4KPGJyPgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4KbW1veCBtYWlsaW5nIGxpc3Q8YnI+CjxhIGhyZWY9Im1haWx0bzptbW94 QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW1veEBpZXRmLm9yZzwvYT48YnI+CjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW1veCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW1veDwvYT48YnI+Cjwv ZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cg== --0015175cb86c6510ce04625bafad-- From morgaine.dinova@googlemail.com Sat Feb 7 16:10:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 801B83A6A60; Sat, 7 Feb 2009 16:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.127 X-Spam-Level: X-Spam-Status: No, score=-1.127 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YePyXxWlmQb6; Sat, 7 Feb 2009 16:10:39 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id D673E3A6A4F; Sat, 7 Feb 2009 16:10:38 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so567327qwe.31 for ; Sat, 07 Feb 2009 16:10:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=t0BspLb6+kQCDyCvEcfKUl+qBad2FZeFWJXhuplx2QQ=; b=MAF1KOoMUSqPvoUappnilvm2MUXAgjEMUg1XsFQmLLdkA/+0DwU1KSJtkGj50Wfw7M F1fBjcLtyP2dr+KQ3v+s5fP756e1uzSrSrlRWKZ2og8X+FL0006qVwO9s86UbL3MZ8R3 AUOe6run+elCyRJVXWIkfUTBnuYLYK5h/HsyE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DguEYDrau9X3wV2YiQmAnOZYprVKSW5iy2h5DFxpaSap1I4NIcX/KQF4T97Sckj84q SE7fgB+yhCDHl2y1RPHDVkGnXLH3Wv6eMXo//hQqzNJ2qA7YTws1gTAABB0ZQNbo5hW2 UR/t+JfVc5y9SdZgQ8nH4LLq5TOFNhyJuzaqg= MIME-Version: 1.0 Received: by 10.214.45.16 with SMTP id s16mr4713326qas.215.1234051840960; Sat, 07 Feb 2009 16:10:40 -0800 (PST) In-Reply-To: References: Date: Sun, 8 Feb 2009 00:10:40 +0000 Message-ID: From: Morgaine Dinova To: David W Levine Content-Type: multipart/alternative; boundary=0015175cd6ea9d6a1d04625d1512 Cc: mmox-bounces@ietf.org, "mmox@ietf.org" Subject: Re: [mmox] Greetings, MMOX Charter, Scope, Activities.. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 00:10:40 -0000 --0015175cd6ea9d6a1d04625d1512 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 6, 2009 at 8:32 PM, David W Levine wrote: > > My hope is that we end up with a set of specifications, which define three > broad sets of items. Low level encoding and formats specifications, and > protocols aimed at building blocks for moving content around. Sets of > services, such as Inventory management, asset Storage, Messaging, presence, > and so forth, which can be deployed in a wide variety of combinations to get > useful effects. finally, there is a set of services centering around that > Linden calls a region simulator, which, are in essence, the mechanisms used > to manage a shared scene graph. Please note, that the current deployment of > these services within the Linden Lab Grid, and on OpenSim grids, is one > model for how a scene graph can be shared. The core problem, of accepting > control inputs from many sources, creating a stream of updated states and > sharing them back out to concerned parties, is, I believe, the nub of the > problem. Many variations can be imagined, with more or less detail handled > centrally, peer to peer simulations, and largely client side simulations. > Our challenge is to capture a set of services and models which lets us > describe these various implementation choices at the services and protocol > level, and, as much as possible, separate deployment and implementation > choices from the interoperable building blocks we define. > > I strongly encourage everyone to share news of the BOF, and of the proposed > working group as widely as possible. While there is a clear danger in > boiling the ocean, if we end up with too diverse a set of interests, I think > that danger is far less than the danger of creating a small focused set of > specifications which don't allow the majority of possible virtual worlds > environments to interoperate. > > Finally, a small word on process and participation. The IETF works by > "rough consensus" how rough, and how broad, is somewhat ill defined. It is > not unanimity, nor is there a precise measure of what is meant by the > phrase. My personal belief is that standards live and die by the ability of > the working group to attract sufficient participants to the consensus. > Standards which unify multiple approaches and allow a diversity of > implementations are of much higher value than ones which codify a single > approach, no matter how well they define that approach. The broader a set > of participants we attract, and the broader a set of possibilities we > enable, the more impact we can have. > > I don't expect that a successful IETF working group will define a set of > specifications which maps exactly to any one implementation. I expect we > will, as a community, begin the process of creating a set of shared building > blocks from which we can compose many implementations. The balancing acts > between generality and efficiency, between learning from the existing code > bases, and imagining better ones will be some of the biggest challenge we > face. The goal is not a single homogenous grid, but rather defining a broad > set of possible virtual spaces, and enabling as fluid and transparent > movement between them as we can manage. > > That is such a wonderfully complete and forward-looking statement that I hesitated to respond initially to avoid gilding the lily. But the lack of comments has made me respond, as I don't want David's words to be lost. I support the above view 100%, and I would encourage everyone else to lend vocal support to such an all-embracing vision. It may seem slightly in conflict with near-term business plans I know, but the fact that we're here at all is testament to many very people (I think I should say "everyone here") being strongly interested in the long term. I think that David has given us a perfect vehicle upon which to ride --- please buy your tickets. I wish to state that I'm on board. Morgaine. --0015175cd6ea9d6a1d04625d1512 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 6, 2009 at 8:32 PM, David W = Levine <dwl@us.ibm.c= om> wrote:

My hope is that we end up with a s= et of specifications, which define three broad sets of items. Low level encodi= ng and formats specifications, and protocols aimed at building blocks for moving content around.  Sets of services, such as Inventory management= , asset Storage, Messaging, presence, and so forth, which can be deployed in a wide variety of combinations to get useful effects. finally, there is a set of services centering around that Linden calls a region simulator, which, are in essence, the mechanisms used to manage a shared scene graph. Please note, that the current deployment of these services within the Linde= n Lab Grid, and on OpenSim grids, is one model for how a scene graph can be shared. The core problem, of accepting control inputs from many sources, creating a stream of updated states and sharing them back out to concerned parties, is, I believe, the nub of the problem. Many variations can be imagined, with more or less detail handled centrally, peer to peer simulati= ons, and largely client side simulations. Our challenge is to capture a set of services and models which lets us describe these various implementation choices at the services and protocol level, and, as much as possible, separ= ate deployment and implementation choices from the interoperable building block= s we define.

I strongly encourage everyone to s= hare news of the BOF, and of the proposed working group as widely as possible. While there is a clear danger in boiling the ocean, if we end up with too diverse a set of interests, I think that danger is far less than the danger of creating a small focused set of specifications which don't allow the majority of possible virtual worlds environments to interoperate.

Finally, a small word on process a= nd participation. The IETF works by "rough consensus" how rough, and how broad, is somewhat ill defined. It is not unanimity, nor is there a precise measure of what is meant by the phrase. My personal belief is that standards live and die by the ability of the working group to attract sufficient  participants to the consensus.  Standards which unify multiple approaches and allow a diversity of implementations are of much higher value than ones which codify a single approach, no matter how well they define that approach.  The broader a set of participants we attra= ct, and the broader a set of possibilities we enable, the more impact we can have.

I don't expect that a successf= ul IETF working group will define a set of specifications which maps exactly to any one implementation. I expect  we will, as a community, begin the process of creating a set of shared building blocks from which we can compo= se many implementations. The balancing acts between generality and efficiency, between learning from the existing code bases, and imagining better ones will be some of the biggest challenge we face. The goal is not  a single homogenous grid, but rather definin= g a broad set of possible virtual spaces, and enabling as fluid and transpare= nt movement between them as we can manage.

That is such a wonderfully complete and forwa= rd-looking statement that I hesitated to respond initially to avoid gilding= the lily.  But the lack of comments has made me respond, as I don'= ;t want David's words to be lost.

I support the above view 100%, and I would encourage everyone else to l= end vocal support to such an all-embracing vision.  It may seem slight= ly in conflict with near-term business plans I know, but the fact that we&#= 39;re here at all is testament to many very people (I think I should say &q= uot;everyone here") being strongly interested in the long term.  = I think that David has given us a perfect vehicle upon which to ride --- pl= ease buy your tickets.  I wish to state that I'm on board.

Morgaine.
--0015175cd6ea9d6a1d04625d1512-- From adam@deepthink.com.au Sat Feb 7 16:36:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D35D3A6B5E for ; Sat, 7 Feb 2009 16:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHHXDARrWGv2 for ; Sat, 7 Feb 2009 16:36:09 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 5FD433A6A22 for ; Sat, 7 Feb 2009 16:36:09 -0800 (PST) Received: from ntxedgeus01.exchange.xchg (ntxedgeus01.lxa.perfora.net [172.23.130.34]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1LVxed2Hja-000891; Sat, 07 Feb 2009 19:36:12 -0500 Received: from ntxhubus02.exchange.xchg (172.23.130.33) by ntxedgeus01.exchange.xchg (172.23.130.34) with Microsoft SMTP Server (TLS) id 8.1.240.5; Sat, 7 Feb 2009 19:27:30 -0500 Received: from winxbeus19.exchange.xchg ([172.23.130.79]) by ntxhubus02.exchange.xchg ([172.23.130.33]) with mapi; Sat, 7 Feb 2009 19:35:07 -0500 From: "Frisby, Adam" To: "mmox@ietf.org" Date: Sat, 7 Feb 2009 19:34:49 -0500 Thread-Topic: [mmox] Proposed draft charter and milestone list Thread-Index: AcmJZ0jQ7pAjumFYShquhhxanxbdZwAHFDjA Message-ID: <63FAD4F222230A4EA79DE9E8BE664735055FCA1F@winxbeus19.exchange.xchg> References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <20090207143157.93idprlj0gsckogw@webmail.martinelli.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Provags-ID: V01U2FsdGVkX1+cl9CnrrVnrpq7Cp3zohBCI57z1IZcIZ1aOXK CjPGmf0bnG6SHKKYAAopzCYFnNb6vWhAZQYPnD25jqAu8oKth Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 00:36:11 -0000 QXMgYSBwZXJzb25hbCBvcGluaW9uIGZvciB0aGUgcmVjb3JkLCB0aGUgY3VycmVudCBVRFAgcGFj a2V0aW5nIHN5c3RlbSBlbXBsb3llZCBieSBMaW5kZW4gTGFiIGFuZCBPcGVuU2ltIGRlc2VydmVz IGFic29sdXRlbHkgbm8gcGxhY2UgYW55d2hlcmUgbmVhciBhbiBJRVRGIGZvcm1hbCBzdGFuZGFy ZCBpbiBpdHMgY3VycmVudCBmb3JtLiBUaGUgc2FtZSBhcHBsaWVzIGZvciBhIGxhcmdlIHBlcmNl bnRhZ2Ugb2YgdGhlIGN1c3RvbSBIVFRQIGhhY2tlcnkgZ29pbmcgb24sIGluIHBhcnRpY3VsYXIg dGhpbmdzIHN1Y2ggYXMgdGhlIHJldmVyc2UtcG9sbC8nRXZlbnRRdWV1ZUdldCcgb3IgdGhlIGN1 cnJlbnQgcHJvcG9zYWwgZm9yIEhUVFAgQXNzZXQgRG93bmxvYWRzLg0KDQpJZiB3ZSBhcmUgdGFs a2luZyBzdGFuZGFyZCB0cmFuc3BvcnRzLCB0aGVuIHRoZXJlIGlzIGFic29sdXRlbHkgbm8gcmVh c29uIHRvIGluY29ycG9yYXRlIG90aGVyIHN0YW5kYXJkcyB3aGVyZSB0aGV5IGRvbuKAmXQgZml0 LiBSZWxpYWJsZSB0cmFuc3BvcnQgY2FuIGJlIGRvbmUgb3ZlciBUQ1AvSVAgdXNpbmcgc29tZSBr aW5kIG9mIG1lc3NhZ2UgZnJhbWUgZmFyIG1vcmUgZWFzaWx5IGFuZCBzYW5lbHkgdGhhbiBhdHRl bXB0aW5nIHRvIGRvIHRoZSBzYW1lIHRoaW5nIGJ1dCBhZGRpbmcgSFRUUCBpbiB0aGVyZSB0b28u DQoNClJlZ2FyZHMsDQoNCkFkYW0NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBtbW94LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptbW94LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZg0KPiBNZWFkaGJoIEhhbXJpY2sgKEluZmluaXR5KQ0KPiBTZW50OiBTYXR1 cmRheSwgNyBGZWJydWFyeSAyMDA5IDE6MDIgUE0NCj4gVG86IGphY2tAbWFydGluZWxsaS5vcmcN Cj4gQ2M6IG1tb3hAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttbW94XSBQcm9wb3NlZCBkcmFm dCBjaGFydGVyIGFuZCBtaWxlc3RvbmUgbGlzdA0KPg0KPiB3aGVuIGkgc2F5ICJhcHBsaWNhdGlv biBsYXllciwiIGknbSByZWZlcnJpbmcgdG8gdGhpbmdzIGFib3ZlIHRoZQ0KPiB0cmFuc3BvcnQg aW4gdGVybXMgb2YgVENQL0lQIGFuZCBhYm92ZSB0aGUgcHJlc2VudGF0aW9uIGxheWVyIGluIHRo ZQ0KPiBPU0kgbW9kZWwuDQo+DQo+IGFuZCB3aGVuIGkgc2F5ICJ3aXJlIHByb3RvY29sLCIgaSdt IHJlZmVycmluZyB0byBQRFVzIHRoYXQgbW92ZSBhY3Jvc3MNCj4gdGhlIHdpcmUuIHRodXMsIGkg dGhpbmsgd2Ugc2hvdWxkIGJlIGlnbm9yaW5nIGlzc3VlcyBvZiBzb2Z0d2FyZQ0KPiBhcmNoaXRl Y3R1cmUgYW5kIGludGVybmFsIG1lc3NhZ2luZyBpbmZyYXN0cnVjdHVyZSB3aGlsZSBtYWtpbmcg YW4NCj4gYXBwbGljYXRpb24gbGF5ZXIgcHJvdG9jb2wgdGhhdCBpcyBpbmRlcGVuZGVudCBvZiBp bXBsZW1lbnRhdGlvbg0KPiBsYW5ndWFnZSBvciBldmVuIHByZXNlbnRhdGlvbiBvciB0cmFuc3Bv cnQuIHRoYXQgaXMsIGkgd291bGQgaG9wZSB3ZQ0KPiBjb3VsZCBkZWZpbmUgYSBwcm90b2NvbCB0 aGF0IGRvZXMgbm90IFJFUVVJUkUgYSBzcGVjaWZpYyB0cmFuc3BvcnQsDQo+IHNlc3Npb24gbWFu YWdlbWVudCBpbmZyYXN0cnVjdHVyZSBvciBtZXNzYWdlIHNlcmlhbGl6YXRpb24gc2NoZW1lLg0K PiB0aGF0IGJlaW5nIHNhaWQuLi4gTEwgYW5kIHRoZSBPcGVuU2ltIGNvbW11bml0eSBoYXZlIGJl ZW4gZm9jdXNpbmcgb24NCj4gbWVzc2FnZXMgc2VudCBvdmVyIEhUVFAoUykgb3ZlciBUQ1Agb3Ig YSBjdXN0b20gbWVzc2FnZSBmb3JtYXQgb3Zlcg0KPiBVRFAsIGFuZCBpIHRoaW5rIHdlIFNIT1VM RCBmb2N1cyBvbiB0aGVzZSB0cmFuc3BvcnRzLi4uIHRoZXJlJ3MgYSBmYWlyDQo+IGFtb3VudCBv ZiBleHBlcmllbmNlIHdpdGggdGhlbSBhbmQgd29ya2luZyBpbXBsZW1lbnRhdGlvbnMuIGJ1dA0K PiB0aGVyZSdzIGJlZW4gcGVyc2lzdGVudCBkaXNjdXNzaW9uIG9mIG90aGVyIHRyYW5zcG9ydHMg YW5kDQo+IHNlcmlhbGl6YXRpb24gc2NoZW1lcywgc28gY3JlYXRpbmcgYSBzeXN0ZW0gdGhhdCB3 YXMgZGVwZW5kZW50IG9uDQo+IEhUVFAoUykgb3ZlciBUQ1Agc2VlbXMgYSBiaXQgbGlrZSBzaG9v dGluZyB5b3Vyc2VsZiBpbiB0aGUgZm9vdCBpbg0KPiB0ZXJtcyBvZiBleHRlbnNpYmlsaXR5Lg0K Pg0KPiBzby4uLiBzb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4uLiBpIHdhcyB1c2luZyB0aGUgdGVy bSAid2lyZSBwcm90b2NvbCINCj4gdG8gZGVzY3JpYmUgdGhpbmdzIHRoYXQgZ2V0IHB1dCBpbiBQ RFVzIGFuZCB0cmFuc21pdHRlZCBvdmVyIGEgbmV0d29yaw0KPiBhcyBkaXN0aW5jdCBmcm9tIHRo ZSBkYXRhIHN0cnVjdHVyZXMgYW5kIHNvZnR3YXJlIHRoYXQgaW50ZXJwcmV0IHRoZQ0KPiBzZW1h bnRpY3Mgb2YgYXBwbGljYXRpb24gbGF5ZXIgUERVcy4NCj4NCj4gTU1PWCBjb3VsZCBiZSBzZWVu IGFzIHRoZSBjb3JlIG9mIGEgbWFzc2l2ZWx5IGRpc3RyaWJ1dGVkIG9wZXJhdGluZw0KPiBzeXN0 ZW0sIGJ1dCB0aGF0IGlzIG5vdCBpdCdzIGZvY3VzLiBpJ20gYSB0b3VjaCBuZXJ2b3VzIGJyaW5n aW5nDQo+IGRpc2N1c3Npb25zIG9mIHNjcmlwdGluZyBsYW5ndWFnZXMgb3Igb3BlcmF0aW5nIHN5 c3RlbXMgaW50byB0aGUgTU1PWA0KPiBjaGFydGVyLiB0aGF0IGJlaW5nIHNhaWQuLi4gbWFueSBv ZiB0aGUgYXBwbGljYXRpb24gbGF5ZXIgb2JqZWN0cw0KPiB3ZSdyZSB0YWxraW5nIGFib3V0IHdp bGwgYmUgc2NyaXB0YWJsZSwgYW5kIHRoZXJlJ3Mgbm8gcmVhc29uIHRvDQo+IFJFUVVJUkUgdGhl IHVzZSBvZiBMU0wgb3IgTU9OTyAob3IgRUNNQVNjcmlwdCBvciAuLi4gKSBpbiB0aGUgc3BlYy4N Cj4gYnV0IHRoZXJlIGFyZSBwcm9iYWJseSB2ZXJ5IGdvb2QgcmVhc29ucyB0byBiZSBhYmxlIHRv IGNvbW11bmljYXRlDQo+IG1ldGFkYXRhIGFib3V0IG9iamVjdHMgKGluY2x1ZGluZyB0aGUgbGFu Z3VhZ2Ugb2Ygc2NyaXB0cykgaW4gTUlNRQ0KPiB0eXBlcyBvciBzb21lIHNpbWlsYXIgbWVjaGFu aXNtLg0KPg0KPiAtY2hlZXJzDQo+IC1tL+KIng0KPg0KPiBPbiBGZWIgNywgMjAwOSwgYXQgMTI6 MzEgUE0sIGphY2tAbWFydGluZWxsaS5vcmcgd3JvdGU6DQo+DQo+ID4gUXVvdGluZyAiSHVybGlt YW4sIEpvaG4iIDxqb2huLmh1cmxpbWFuQGludGVsLmNvbT46DQo+ID4NCj4gPj4gSSBoYXZlIG1h ZGUgY2hhbmdlcyB0byB0aGUgZHJhZnQgZ3JvdXAgY2hhcnRlcg0KPiA+DQo+ID4NCj4gPiAuLi4u DQo+ID4+IFRoZSBvYmplY3RpdmUgb2YgdGhlIE1NT1ggd29ya2luZyBncm91cCBpcyB0byBwcm92 aWRlIGFuDQo+ID4+IGFwcGxpY2F0aW9uLWxheWVyIHdpcmUgcHJvdG9jb2wgZm9yIFZpcnR1YWwg V29ybGRzIHRvIGEpIGVuYWJsZQ0KPiA+PiBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gYXBwbGlj YXRpb25zLCBiKSBwcm92aWRlIGZvciBhY2Nlc3MgYW5kDQo+ID4+IGV4Y2hhbmdlIHdpdGggb3Ro ZXIgc3lzdGVtcyBvbiB0aGUgaW50ZXJuZXQgc3VjaCBhcyBpZGVudGl0eQ0KPiA+PiBwcm92aWRl cnMsIHdlYiBzZXJ2aWNlcywgZS1tYWlsIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzdG9yYWdlDQo+ ID4+IHN5c3RlbXMsIGMpIGFsbG93IG5ldHdvcmsgbGF5ZXJzIHRvIHJlY29nbml6ZSBWVyB0cmFm ZmljIGFuZCBtYWtlDQo+ID4+IHJvdXRpbmcgZGVjaXNpb25zIGJhc2VkIG9uIGl0cyBjaGFyYWN0 ZXJpc3RpY3MuDQo+ID4NCj4gPiBKdXN0IGEgbml0Li4uIGFuIGFwcGxpY2F0aW9uLWxheWVyIHBy b3RvY29sIGlzbid0IGEgd2lyZSBwcm90b2NvbC4NCj4gPiBZb3UgcHJvYmFibHkgd2FudCB0byBz dGF5IGF3YXkgZnJvbSB1c2luZyAid2lyZSBwcm90b2NvbCIgY3V6IGl0DQo+ID4gbWlnaHQgc291 bmQgdG8gdG8gZ3V5cyBsaWtlIG1lIHRoYXQgeW91IHdhbnQgdG8gcmVwbGFjZSBhbGwgdGhlDQo+ ID4gaGFyZHdhcmUgb3IgTklDIGZpcm13YXJlIG9uIHRoZSB3aG9sZSB3d3cuDQo+ID4NCj4gPiBB cHBsaWNhdGlvbiBsYXllciBtaWdodCBiZSBuZWVkIHJlZmluZW1lbnQgYXMgd2VsbC4gIEknbSB0 aGlua2luZw0KPiA+IG1vcmUgbGlrZSBhIDItbGF5ZXIgY2xpZW50IGxheWVyLiAgSSdkIGRpdmlk ZSBpdCBsaWtlIHNvLi4uDQo+ID4NCj4gPiBzY3JpcHRhYmxlIFZXIGxheWVyDQo+ID4gICBWV1Ag PSBWVyBwb3J0cyAtIG5vbi1ob3N0IHByb3RvY29sIHBvcnRzIChzb21ldGhpbmcgbGlrZSB0aG9z ZQ0KPiA+IHVzZWQgaW4gU0wncyAtIGxsTGlzdGVuLCBsbFNheSkNCj4gPiAgIGhvc3QtcHJvdG9j b2wgcG9ydHMgLSBUQ1AvSVAgKHllcyB3ZSBoYXZlIHRvIHVzZSB0aGlzKQ0KPiA+DQo+ID4gTU1P WCBsYXllciBwdWJsaXNoZWQgQVBJIHNvIHRoYXQgdmVuZG9ycyBtYXkgaW1wbGVtZW50IHRoZWly IG93bg0KPiA+IFZXJ3MsIGdhbWVzLCBsYW5ndWFnZXMgZXRjLg0KPiA+DQo+ID4gICBpbXBsZW1l bnRzIG5vbi1ob3N0IHByb3RvY29sIHBvcnRzIHVzZWQgYnkgc2NyaXB0YWJsZSBsYXllci4NCj4g Pg0KPiA+IEkgc2VlIHRoZSBNTU9YIGxheWVyIGFzIHRoZSBjb3JlIG9mIGEgbWFzc2l2ZWx5IGRp c3RyaWJ1dGVkIE9TIHdpdGgNCj4gPiBhbGwgdGhlIHNhbWUgcmVxdWlyZW1udHMgb2YgYW55IE9T LiAgSXQncyBhIHJlc291cmNlIG1hbmFnZXIuDQo+ID4gUG9zc2libHkgdGhpcyBzaG91bGQgYmUg ZGl2aWRlZCBhcyB3ZWxsIGludG8gYSBtYXNzaXZlbHkgZGlzdHJpYnV0ZWQNCj4gPiBPUyBhbmQg TU1PWD8gc2VlIDoNCj4gPg0KPiA+IGh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvTU9TSVgN Cj4gPiBhbmQNCj4gPiBodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0xpbnV4UE1JDQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiBtbW94IG1haWxpbmcgbGlzdA0KPiA+IG1tb3hAaWV0 Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tb3gNCj4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbW1v eCBtYWlsaW5nIGxpc3QNCj4gbW1veEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL21tb3gNCg== From morgaine.dinova@googlemail.com Sat Feb 7 19:50:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7413A6ABF for ; Sat, 7 Feb 2009 19:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev5CSazjQffm for ; Sat, 7 Feb 2009 19:50:21 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 44DF33A6B70 for ; Sat, 7 Feb 2009 19:50:21 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so585901qwe.31 for ; Sat, 07 Feb 2009 19:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Uj51h3WXgQFkRkpOEUhcozfrVxzjjfv2PpY1dzA/sC0=; b=qZ6Da+qGrJ9rQjXBS0R/fFNEBAbV5yR82ZAN+6cIbsl4rCd1kcGqgWKwM8QzAbXNsC Bzgbxp4j+J5QAMysb8d9H6z0mxbzXMpFNAbJVONKmBh+BKObvEtdl9rsy9FN9MtJ+CAR k2tDDqxlNSsQwiDrK7FF/jGr06kfIqmkw28ws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Mp2zgrGK1imR/IREuQsCQSpqBFRfuYl1x81TijPk5RaF2Fsd4fJfpTUN2YterkDiYo krh2khiom/nQIOYBm78a6WcD3tlvtZDmfRcuPCnMwXoaS3yfKW8n4VPMpb9aMeT03po6 g8ntExNlvAzL3z2mliKKUa3PO6lX2D8I7+4ts= MIME-Version: 1.0 Received: by 10.214.46.5 with SMTP id t5mr2363879qat.195.1234065023698; Sat, 07 Feb 2009 19:50:23 -0800 (PST) In-Reply-To: <63FAD4F222230A4EA79DE9E8BE664735055FCA1F@winxbeus19.exchange.xchg> References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <20090207143157.93idprlj0gsckogw@webmail.martinelli.org> <63FAD4F222230A4EA79DE9E8BE664735055FCA1F@winxbeus19.exchange.xchg> Date: Sun, 8 Feb 2009 03:50:23 +0000 Message-ID: From: Morgaine Dinova To: "Frisby, Adam" Content-Type: multipart/alternative; boundary=0015175ce10c5e07e50462602738 Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 03:50:22 -0000 --0015175ce10c5e07e50462602738 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Feb 8, 2009 at 12:34 AM, Frisby, Adam 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. --0015175ce10c5e07e50462602738 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Feb 8, 2009 at 12:34 AM, Frisby,= Adam <adam@d= eepthink.com.au> wrote:
As a personal opinion for the record, the current UDP packeting system empl= oyed by Linden Lab and OpenSim deserves absolutely no place anywhere near a= n IETF formal standard in its current form. The same applies for a large pe= rcentage of the custom HTTP hackery going on, in particular things such as = the reverse-poll/'EventQueueGet' or the current proposal for HTTP A= sset Downloads.

If we are talking standard transports, then there is absolutely no reason t= o 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 sa= nely 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 bee= n 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 th= e massed ranks of "Web-everywhere" people.  However, layerin= g this over HTTP is not sensible engineering, as Adam suggests, but merely = tactical for me.  A TCP stream opened in the client->server directi= on is perfectly adequate for transport of an arbitrary multiplexed data str= eam in the reverse direction, and it does not need any HTTP chicanery to se= t it up nor to keep the downstream pipe busy.  The opening of a TCP st= ream 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 pum= ping downstream traffic once the pipe has been created.

Once established by a client->server request, a TCP stream is an ind= ependent server-client pathway.  HTTP requests from the client may est= ablish 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 be= nefit from HTTP, and it should be handled outide of HTTP, even if the serve= r is running as a REST-type service for upstream requests.  To identif= y the long-term downstream data pipe with a kept-alive HTTP 1.1 shared resp= onse pipe is just plain wrong, and merely panders to the web-centric view i= n areas where web technology is of no benefit.

Multiplexed transmission pipes such as those provided by the (IETF-spon= sored) 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 ef= fectively and with more overhead), without any dependence on HTTP and witho= ut 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 w= ould caution that if we enshrine HTTP response traffic as the recommended t= ransport for server->client updates then our work will be rapidly render= ed second-best by those who take the direct approach of sending asynchronou= s 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 u= pdate process into web-compliant form is simply because there is no Interne= t standard for the job.  Maybe our work here should *start* with defin= ing a mechanism for asynchronous transmission of LLSD objects over bidirect= ional multiplexed client-initiated TCP bundles or SCTP streams.

PPS. Sadly, it would be far too much work to run this idea as a non-mai= nstream counter-proposal here.  I would however suggest that Adam'= s post be taken as strong advice to ABSTRACT THE DOWNSTREAM LINK.  The= n one day someone may do the job properly.
--0015175ce10c5e07e50462602738-- From infinity@lindenlab.com Sat Feb 7 20:04:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 127823A6B8E for ; Sat, 7 Feb 2009 20:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-AJOO74wX-7 for ; Sat, 7 Feb 2009 20:04:40 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 1DDD43A6AFB for ; Sat, 7 Feb 2009 20:04:40 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 7C0231414003; Sat, 7 Feb 2009 20:04:43 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Morgaine Dinova In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-8-208128820 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Feb 2009 20:04:42 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 04:04:41 -0000 --Apple-Mail-8-208128820 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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) > 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. > --Apple-Mail-8-208128820 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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) <infinity@lindenlab.com> = 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.


= = --Apple-Mail-8-208128820-- From morgaine.dinova@googlemail.com Sat Feb 7 20:33:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D82BE3A6B90 for ; Sat, 7 Feb 2009 20:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KoHZ2iRwXJB4 for ; Sat, 7 Feb 2009 20:33:44 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id D037C3A6968 for ; Sat, 7 Feb 2009 20:33:43 -0800 (PST) Received: by qyk4 with SMTP id 4so2011876qyk.13 for ; Sat, 07 Feb 2009 20:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aM57OwjAx5ROi9lGvEB8DCekEX4zWGDx7hxx9ldblhs=; b=cijZ+YWfwJYV1zYCuDiOmQ+x5jJxCRHXVWeNGbSHL0S3xOlo0g28tm8/xsj+Y6NssB lqTSwNu3E07JeCthctoJOPwsnLQEV1tvush3+HM83nrBB/21zlBaIuecGeMewWTUxSMj ys808M0rxSE+8CZVxmX2g7r627se+KrCGpoUo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rEWFFs8IZCb3MxH8iBO8WvNr2apHTwenEU1tBwhjt9IFi011Q8izGOi8j7Br4nYVD3 bDz93kDAO8eHlrPstFl3CKqD6m8T7+PRdyeR/nkYZu1tMnmpYisoAH0JuxPCGdscZU+d K9reFw2ZH5H+oG4zFc5OIrJ0Fk+F+EVaG/umg= MIME-Version: 1.0 Received: by 10.215.12.12 with SMTP id p12mr3485281qai.43.1234067626100; Sat, 07 Feb 2009 20:33:46 -0800 (PST) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> Date: Sun, 8 Feb 2009 04:33:46 +0000 Message-ID: From: Morgaine Dinova To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=0015175cd2767b8841046260c245 Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 04:33:45 -0000 --0015175cd2767b8841046260c245 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Feb 8, 2009 at 4:04 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > Morgaine. we did something to affirm the new protocol will be open and > 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. --0015175cd2767b8841046260c245 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Feb 8, 2009 at 4:04 AM, Meadhbh = Hamrick (Infinity) <infinity@lindenlab.com> wrote:
Morgaine. we did something to affirm the new protocol will = be open and 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 n= o proprietary referent.  It made (some) sense only in the context of y= our original version, because OGP might well have been considered proprieta= ry.

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 co= nsider 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 wor= d "proprietary" did not do that, and only sowed confusion owing t= o total lack of context in the new version.

Arguing about one word is not helpful however.  I would instead as= k you:  do you want the charter to make it plain that our work is &quo= t;public and open"?  If so, then let us find the best form of wor= ds to achieve that.

Morgaine.
--0015175cd2767b8841046260c245-- From lisa.dusseault@gmail.com Sun Feb 8 08:59:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE773A6918 for ; Sun, 8 Feb 2009 08:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.831 X-Spam-Level: X-Spam-Status: No, score=-2.831 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2in4cP8WmMK for ; Sun, 8 Feb 2009 08:59:21 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 77D053A67F3 for ; Sun, 8 Feb 2009 08:59:21 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so1417006rvf.49 for ; Sun, 08 Feb 2009 08:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=a/FMzujnE9HnrjpFvMM+f6FdaSMtTf2SeLd2S01GgDU=; b=fR7ZY0VjQRuUtjffjjqT8mCtf40iPB4IBzglhX+qRgoUQSBNNIaDw/RkzDn6KGUpyJ zM8tUZAdH2R/NLjwYFhHUKqV2vXUIkrVm0QAmniVB5f33ymhHFUccV1UWVZz6+cwci4u 2ZRsjI71vLfQDeeaAnRZc+u02StObCM13mfQY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uyh3N/d2+ZGA4O56xZb31WdWxWbyjRs/Q3IoUCS4PP+yUH9yNThXZPXO81FDES5PJl 2EN2MYQk9/83s4cAeKREYiBjSgZYLANq5h0Aipi4Z8+lzdm5hR01DE37yAb2kDYnMgSw pYAFM4rPSG3aOo14JsBmQb+cIJhOAuItzL2HU= MIME-Version: 1.0 Received: by 10.141.137.16 with SMTP id p16mr3083211rvn.180.1234112365187; Sun, 08 Feb 2009 08:59:25 -0800 (PST) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <20090207143157.93idprlj0gsckogw@webmail.martinelli.org> <63FAD4F222230A4EA79DE9E8BE664735055FCA1F@winxbeus19.exchange.xchg> Date: Sun, 8 Feb 2009 08:59:25 -0800 Message-ID: From: Lisa Dusseault To: Morgaine Dinova Content-Type: multipart/alternative; boundary=000e0cd212cc23d31504626b2db9 Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 16:59:23 -0000 --000e0cd212cc23d31504626b2db9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 < morgaine.dinova@googlemail.com> wrote: > > > On Sun, Feb 8, 2009 at 12:34 AM, Frisby, Adam 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. > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --000e0cd212cc23d31504626b2db9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Interesting timing:  another BOF proposal this month was to do some ex= tensions 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 someth= ing called "Web Sockets" for much the same reasons. 

Fighting this widespread demand would be counterproductive.  Inste= ad, 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 th= e focus and expertise to do it properly (there is so much deployed HTTP rea= lity 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 al= ready-standardized examples that are nearer or farther from the heart of HT= TP.  Atom and WebDAV and XCAP are pretty much extensions of HTTP (and = give quite varying examples of degrees and styles of "RESTful").&= nbsp; 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 obsol= ete and we've been trying to find somebody with the time and saintly pa= tience to revise it.)

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


Lisa

On Sat, Feb 7, 2009 at 7:50 = PM, Morgaine Dinova <morgaine.dinova@googlemail.com> wrote:


On Sun, Feb 8, 200= 9 at 12:34 AM, Frisby, Adam <adam@deepthink.com.au> wrot= e:
As a personal opinion for the record, the current UDP packeting system empl= oyed by Linden Lab and OpenSim deserves absolutely no place anywhere near a= n IETF formal standard in its current form. The same applies for a large pe= rcentage of the custom HTTP hackery going on, in particular things such as = the reverse-poll/'EventQueueGet' or the current proposal for HTTP A= sset Downloads.

If we are talking standard transports, then there is absolutely no reason t= o 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 an= d sanely than attempting to do the same thing but adding HTTP in there too.=

I'm gla= d 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 f= or getting a plain server->client TCP pipe concept through the massed ra= nks of "Web-everywhere" people.  However, layering this over= HTTP is not sensible engineering, as Adam suggests, but merely tactical fo= r me.  A TCP stream opened in the client->server direction is perfe= ctly 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 cli= ent->server request is sufficient to overcome the problem of unreachable= client-side listeners owing to NAT, firewalls and other blocks.  It d= oes not mandate a synchronous client->server approach for pumping downst= ream traffic once the pipe has been created.

Once established by a client->server request, a TCP stream is an ind= ependent server-client pathway.  HTTP requests from the client may est= ablish 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 be= nefit from HTTP, and it should be handled outide of HTTP, even if the serve= r is running as a REST-type service for upstream requests.  To identif= y the long-term downstream data pipe with a kept-alive HTTP 1.1 shared resp= onse pipe is just plain wrong, and merely panders to the web-centric view i= n areas where web technology is of no benefit.

Multiplexed transmission pipes such as those provided by the (IETF-spon= sored) 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 ef= fectively and with more overhead), without any dependence on HTTP and witho= ut 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 w= ould caution that if we enshrine HTTP response traffic as the recommended t= ransport for server->client updates then our work will be rapidly render= ed second-best by those who take the direct approach of sending asynchronou= s 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 u= pdate process into web-compliant form is simply because there is no Interne= t standard for the job.  Maybe our work here should *start* with defin= ing a mechanism for asynchronous transmission of LLSD objects over bidirect= ional multiplexed client-initiated TCP bundles or SCTP streams.

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

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--000e0cd212cc23d31504626b2db9-- From morgaine.dinova@googlemail.com Sun Feb 8 10:42:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263103A68DE for ; Sun, 8 Feb 2009 10:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi+0RJrdwHxX for ; Sun, 8 Feb 2009 10:42:48 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 464463A6929 for ; Sun, 8 Feb 2009 10:42:47 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so655473qwe.31 for ; Sun, 08 Feb 2009 10:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KRUgCoUTvI8f+yohdkNgRoX/9K4szURZR85bu5HoSaU=; b=GFqRoBm2LrKqep/LsR/uXylqc61Gzrdc7sK3gRBCVHOB1KC935oKUNoVFf2NEk29qw 2nglbQSUsgrN9S8nO2IKrXc1lQed7f1D9gWZXSK4ugJalj5DRr7z22J4CXIMD4OB4WW2 Uya2Yb+2WHLzmkMh75bu0VM9LVBuX+a78cyBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ky0WN5F6/OW/MPc+uHwgj4AD2W7dF48WNYW7hdHKPxf2gjFGromGcV1WoG4lmMlvvu jbVWQmo9O9Brp2nQXgRk4zcW4OMl5BkguxgB7lkyoCbU/2+fgC/lnv2Mv5x7qXIknoV3 XXmVGQd07gkEonyJuxDOtqlk7OLb7UnrOUxTk= MIME-Version: 1.0 Received: by 10.214.115.1 with SMTP id n1mr1833090qac.374.1234118571652; Sun, 08 Feb 2009 10:42:51 -0800 (PST) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <20090207143157.93idprlj0gsckogw@webmail.martinelli.org> <63FAD4F222230A4EA79DE9E8BE664735055FCA1F@winxbeus19.exchange.xchg> Date: Sun, 8 Feb 2009 18:42:51 +0000 Message-ID: From: Morgaine Dinova To: Lisa Dusseault Content-Type: multipart/alternative; boundary=0015175cdaec12f73204626c9ffc Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 18:42:50 -0000 --0015175cdaec12f73204626c9ffc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 wrote: > 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 < > morgaine.dinova@googlemail.com> wrote: > >> >> >> On Sun, Feb 8, 2009 at 12:34 AM, Frisby, Adam 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. >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > --0015175cdaec12f73204626c9ffc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Lisa, if you discover any workgroups dedicated to multiplexed server->cl= ient structured object streams that AREN'T layered on top of HTTP, I= 9;d be very interested to hear about them.  :-)

(If they use HT= TP for upstream, that's fine too, as long as the downstream part is ind= ependent.)

Morgaine.

On Sun, Feb 8, 2009 at 4:59= PM, Lisa Dusseault <lisa.dusseault@gmail.com> wrote:
Interesting timing:  another BOF proposal this month was to do some ex= tensions 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 someth= ing called "Web Sockets" for much the same reasons. 

Fighting this widespread demand would be counterproductive.  Inste= ad, 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 th= e focus and expertise to do it properly (there is so much deployed HTTP rea= lity 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 al= ready-standardized examples that are nearer or farther from the heart of HT= TP.  Atom and WebDAV and XCAP are pretty much extensions of HTTP (and = give quite varying examples of degrees and styles of "RESTful").&= nbsp; 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 obsol= ete and we've been trying to find somebody with the time and saintly pa= tience to revise it.)

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


Lisa

On Sat, Feb 7, 2009 at 7:50 PM, Morgaine Dinova <morgaine.dinova@googlemail.com> wrote:
=


On Sun, Feb 8, 2009 at 12:34 AM, Fr= isby, Adam <adam@deepthink.com.au> wrote:
As a personal opinion for the record, the current UDP packeting system empl= oyed by Linden Lab and OpenSim deserves absolutely no place anywhere near a= n IETF formal standard in its current form. The same applies for a large pe= rcentage of the custom HTTP hackery going on, in particular things such as = the reverse-poll/'EventQueueGet' or the current proposal for HTTP A= sset Downloads.

If we are talking standard transports, then there is absolutely no reason t= o 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 an= d sanely than attempting to do the same thing but adding HTTP in there too.=

I'm gla= d 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 f= or getting a plain server->client TCP pipe concept through the massed ra= nks of "Web-everywhere" people.  However, layering this over= HTTP is not sensible engineering, as Adam suggests, but merely tactical fo= r me.  A TCP stream opened in the client->server direction is perfe= ctly 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 cli= ent->server request is sufficient to overcome the problem of unreachable= client-side listeners owing to NAT, firewalls and other blocks.  It d= oes not mandate a synchronous client->server approach for pumping downst= ream traffic once the pipe has been created.

Once established by a client->server request, a TCP stream is an ind= ependent server-client pathway.  HTTP requests from the client may est= ablish 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 be= nefit from HTTP, and it should be handled outide of HTTP, even if the serve= r is running as a REST-type service for upstream requests.  To identif= y the long-term downstream data pipe with a kept-alive HTTP 1.1 shared resp= onse pipe is just plain wrong, and merely panders to the web-centric view i= n areas where web technology is of no benefit.

Multiplexed transmission pipes such as those provided by the (IETF-spon= sored) 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 ef= fectively and with more overhead), without any dependence on HTTP and witho= ut 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 w= ould caution that if we enshrine HTTP response traffic as the recommended t= ransport for server->client updates then our work will be rapidly render= ed second-best by those who take the direct approach of sending asynchronou= s 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 u= pdate process into web-compliant form is simply because there is no Interne= t standard for the job.  Maybe our work here should *start* with defin= ing a mechanism for asynchronous transmission of LLSD objects over bidirect= ional multiplexed client-initiated TCP bundles or SCTP streams.

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

_____________________________________= __________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox



--0015175cdaec12f73204626c9ffc-- From lenglish5@cox.net Sun Feb 8 12:20:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD6E3A6B0F for ; Sun, 8 Feb 2009 12:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.96 X-Spam-Level: X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahMk0+dOehWU for ; Sun, 8 Feb 2009 12:20:25 -0800 (PST) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id B39353A69BF for ; Sun, 8 Feb 2009 12:20:25 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090208202029.OPLR12540.fed1rmmtao106.cox.net@fed1rmimpo02.cox.net>; Sun, 8 Feb 2009 15:20:29 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id DYLT1b00E4N6T0Q04YLTG6; Sun, 08 Feb 2009 15:20:28 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=tSEhY0Qq5EuDJ3g6hvUA:9 a=TO83JGg4K9KEwCgokDeF-t966KUA:4 a=BDXKcin-EtgA:10 X-CM-Score: 0.00 Message-ID: <498F3E8B.8020408@cox.net> Date: Sun, 08 Feb 2009 13:20:27 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "mmox@ietf.org" , Lisa Dusseault , "Infinity Linden (Meadhbh S. Hamrick)" , David W Levine Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 20:20:27 -0000 Seems to me that it would be a great thing (especially for those of us who can't make it) if the mmox BOF was held or at least broadcast in-world, live. This would be symbolic AND allow those of us who can't be there to at least know what is going on, even if the IETF rules wouldn't allow us to participate fully. Which brings up another point: what ARE the IETF rules concerning remote participation via VR? I'm guessing they don't exist as yet. Should that be something that is worked out before the meeting? Can people who are unable to make the meetig get some kind of recognized status at the meeting? Even peanut gallery chatter ala Metanomics or Science Friday would be a good start. Lawson From infinity@lindenlab.com Sun Feb 8 13:49:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124CE3A6AAA for ; Sun, 8 Feb 2009 13:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Hgyx8iI77JP for ; Sun, 8 Feb 2009 13:49:04 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 5495C3A69B5 for ; Sun, 8 Feb 2009 13:49:03 -0800 (PST) Received: from localhost (m640e36d0.tmodns.net [208.54.14.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 85AE83DBC09B; Sun, 8 Feb 2009 13:49:02 -0800 (PST) Message-ID: <8trxigmmb2wwkcxti246i9js.1234129734178@email.android.com> From: "Infinity Linden (Meadhbh S. Hamrick)" Date: Sun, 08 Feb 2009 13:48:53 -0800 To: Lawson English , "mmox@ietf.org" , Lisa Dusseault , David W Levine Content-Type: multipart/mixed; boundary="----ROGPB3YQWGQNW03O4TCY697FFLUYTI" MIME-Version: 1.0 Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 21:49:05 -0000 ------ROGPB3YQWGQNW03O4TCY697FFLUYTI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGV5IFNhaS4uLiB0aGlzIGlzIGEgdmVyeSBnb29kIHBvaW50IGFuZCBvbmUgSSdtIGdsYWQgc29t ZW9uZSBlbHNlIGlzIHRoaW5raW5nIGFib3V0IHRvby4gSSBkb24ndCBiZWxpZXZlIHRoZSBJRUZU IHB1Ymxpc2hlcyBndWlkZWxpbmVzIGZvciBicm9hZGNhc3RpbmcgaW50byB2aXJ0dWFsIHdvcmxk cywgYnV0IHRoZXkgaGF2ZSBzaW11bGNhc3Qgc29tZSBtZWV0aW5ncyB2aWEgaW50ZXJuZXQgYnJv YWRjYXN0LCBzbyB0aGVyZSBhcmUgcHJvYmFibHkgc29tZSBndWlkZWxpbmVzIHdlIGNvdWxkICJi b3Jyb3ciLiBXZSdyZSBwcm9iYWJseSBhIGJpdCBvZiB0aW1lIGF3YXkgZnJvbSBmdWxsIHBhcnRp Y2lwYXRpb24gaW4gdmlydHVhbCB3b2xkcy4gSSBjYW4gaW1hZ2luZSB0aGVyZSdzIGEgZGViYXRl IHRoYXQgY291bGQgaGFwcGVuIHJlbGF0ZWQgdG8gYW5vbnltaXR5IGFuZCByZXB1dGF0aW9uLiBC ZXNpZGVzLCB3ZSBtYXkgd2FudCB0byBkZXNpZ24gdGhlIE9HUCBIdW1tIFN1Yi1Qcm90b2NvbC4K ClNvIGxlbW1lIGFzayBhcm91bmQgYW5kIHNlZSB3aGF0IHdlIGNhbiBkby4KCi1DaGVlcnMKLUlu ZmluaXR5CgpMYXdzb24gRW5nbGlzaCA8bGVuZ2xpc2g1QGNveC5uZXQ+IHdyb3RlOgoKPlNlZW1z IHRvIG1lIHRoYXQgaXQgd291bGQgYmUgYSBncmVhdCB0aGluZyAoZXNwZWNpYWxseSBmb3IgdGhv c2Ugb2YgdXMgDQo+d2hvIGNhbid0IG1ha2UgaXQpIGlmIHRoZSBtbW94IEJPRiB3YXMgaGVsZCBv ciBhdCBsZWFzdCBicm9hZGNhc3QgDQo+aW4td29ybGQsIGxpdmUuIFRoaXMgd291bGQgYmUgc3lt Ym9saWMgQU5EIGFsbG93IHRob3NlIG9mIHVzIHdobyBjYW4ndCANCj5iZSB0aGVyZSB0byBhdCBs ZWFzdCBrbm93IHdoYXQgaXMgZ29pbmcgb24sIGV2ZW4gaWYgdGhlIElFVEYgcnVsZXMgDQo+d291 bGRuJ3QgYWxsb3cgdXMgdG8gcGFydGljaXBhdGUgZnVsbHkuDQo+DQo+V2hpY2ggYnJpbmdzIHVw IGFub3RoZXIgcG9pbnQ6IHdoYXQgQVJFIHRoZSBJRVRGIHJ1bGVzIGNvbmNlcm5pbmcgcmVtb3Rl IA0KPnBhcnRpY2lwYXRpb24gdmlhIFZSPyBJJ20gZ3Vlc3NpbmcgdGhleSBkb24ndCBleGlzdCBh cyB5ZXQuIFNob3VsZCB0aGF0IA0KPmJlIHNvbWV0aGluZyB0aGF0IGlzIHdvcmtlZCBvdXQgYmVm b3JlIHRoZSBtZWV0aW5nPyBDYW4gcGVvcGxlIHdobyBhcmUgDQo+dW5hYmxlIHRvIG1ha2UgdGhl IG1lZXRpZyBnZXQgc29tZSBraW5kIG9mIHJlY29nbml6ZWQgc3RhdHVzIGF0IHRoZSANCj5tZWV0 aW5nPyBFdmVuIHBlYW51dCBnYWxsZXJ5IGNoYXR0ZXIgYWxhIE1ldGFub21pY3Mgb3IgU2NpZW5j ZSBGcmlkYXkgDQo+d291bGQgYmUgYSBnb29kIHN0YXJ0Lg0KPg0KPg0KPkxhd3Nvbg0KPg0KPg0K ------ROGPB3YQWGQNW03O4TCY697FFLUYTI-- From rthayer@secorix.com Sun Feb 8 13:55:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F3D3A6ACA for ; Sun, 8 Feb 2009 13:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9fO8lhL4AFx for ; Sun, 8 Feb 2009 13:55:57 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id C24913A6AAA for ; Sun, 8 Feb 2009 13:55:57 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so1472758rvf.49 for ; Sun, 08 Feb 2009 13:56:01 -0800 (PST) Received: by 10.141.29.16 with SMTP id g16mr3267862rvj.92.1234130160769; Sun, 08 Feb 2009 13:56:00 -0800 (PST) Received: from ?192.168.1.103? (adsl-75-55-220-76.dsl.pltn13.sbcglobal.net [75.55.220.76]) by mx.google.com with ESMTPS id c20sm7506978rvf.8.2009.02.08.13.55.59 (version=SSLv3 cipher=RC4-MD5); Sun, 08 Feb 2009 13:55:59 -0800 (PST) Message-ID: <498F54E5.1020706@secorix.com> Date: Sun, 08 Feb 2009 13:55:49 -0800 From: Rodney Thayer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "mmox@ietf.org" References: <498F3E8B.8020408@cox.net> In-Reply-To: <498F3E8B.8020408@cox.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 21:55:59 -0000 There are technologies being used to gain remote access to IETF meetings, I believe. See for example this... http://videolab.uoregon.edu/events/ietf/ They've been noodling with offsite access to IETF meetings for a while. If there's some public information on how an in-world parallel meeting could occur using any of these protocols that'd be an interesting use case. It was my impression that the state of the art is not quite there. Lawson English wrote: > Seems to me that it would be a great thing (especially for those of us > who can't make it) if the mmox BOF was held or at least broadcast > in-world, live. This would be symbolic AND allow those of us who can't > be there to at least know what is going on, even if the IETF rules > wouldn't allow us to participate fully. > > Which brings up another point: what ARE the IETF rules concerning remote > participation via VR? I'm guessing they don't exist as yet. Should that > be something that is worked out before the meeting? Can people who are > unable to make the meetig get some kind of recognized status at the > meeting? Even peanut gallery chatter ala Metanomics or Science Friday > would be a good start. > > > Lawson > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From lenglish5@cox.net Sun Feb 8 14:02:47 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38EA93A68F6 for ; Sun, 8 Feb 2009 14:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.614 X-Spam-Level: X-Spam-Status: No, score=0.614 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z295pPkt80gj for ; Sun, 8 Feb 2009 14:02:46 -0800 (PST) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id 76A103A68AE for ; Sun, 8 Feb 2009 14:02:46 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090208220251.CFXT2948.fed1rmmtao101.cox.net@fed1rmimpo02.cox.net>; Sun, 8 Feb 2009 17:02:51 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id Da2q1b00D4N6T0Q04a2qih; Sun, 08 Feb 2009 17:02:51 -0500 X-Authority-Analysis: v=1.0 c=1 a=_Pk5SSxGuSsA:10 a=esVFqgeMqEEA:10 a=Wajolswj7cQA:10 a=vj2nFF74AAAA:8 a=8Na7m2f08QAIYu3Y7-4A:9 a=WsxYgxcStN9SsPEUesoA:7 a=uVJSwTuDyVHMiWE-kJYuxxAP7F4A:4 a=Dqp-bWOt5EsA:10 X-CM-Score: 0.00 Message-ID: <498F568A.6060401@cox.net> Date: Sun, 08 Feb 2009 15:02:50 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Rodney Thayer References: <498F3E8B.8020408@cox.net> <498F54E5.1020706@secorix.com> In-Reply-To: <498F54E5.1020706@secorix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 22:02:47 -0000 Rodney Thayer wrote: > There are technologies being used to gain remote access to IETF > meetings, I believe. See for example this... > > http://videolab.uoregon.edu/events/ietf/ > > They've been noodling with offsite access to IETF meetings > for a while. > > If there's some public information on how an in-world parallel > meeting could occur using any of these protocols that'd be > an interesting use case. It was my impression that the state > of the art is not quite there. > > Well, there are two weekly venues for this kind of thing in Second LIfe: NPR's Science Friday and the MEtanomics interview show. Ira Flatow keeps an avatar in Second LIfe and monitors background text chatter and weaves it into his interview. Beyers Sellers interviews guests as Second Life avatars, has a simul-cast to the Metanomics webiste, and has special Second Life links between several different islands so that that people can watch the interview live via QuickTime on the website or one of the Second Life islands, and everyone's local chat and website comments are mushed into one massive local chat in realtime. Seems to me that these would be good models for in-world participation, though, the question of "membership" vs peanut gallery status may arise. L. From infinity@lindenlab.com Sun Feb 8 14:23:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822BB3A6ABC for ; Sun, 8 Feb 2009 14:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XrrMuxWn0IE for ; Sun, 8 Feb 2009 14:23:03 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 94AB33A68AE for ; Sun, 8 Feb 2009 14:23:03 -0800 (PST) Received: from localhost (m240e36d0.tmodns.net [208.54.14.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 9CE3B3DBC09C; Sun, 8 Feb 2009 14:23:04 -0800 (PST) Message-ID: From: "Infinity Linden (Meadhbh S. Hamrick)" Date: Sun, 08 Feb 2009 14:22:58 -0800 To: Rodney Thayer ,"mmox@ietf.org" Content-Type: multipart/mixed; boundary="----XA5XJRVECWWJH2854OMPDOS43G6E8V" MIME-Version: 1.0 Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 22:23:04 -0000 ------XA5XJRVECWWJH2854OMPDOS43G6E8V Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Q29vbC4gR2V0dGluZyB2aWRlbyBpbnRvIFNMIHNob3VsZCBiZSBlYXN5LiBXZSBqdXN0IGJvdW5j ZSBhIHN0cmVhbSBvZmYgc29tZW9uZSB3aXRoIHRoZSBiYW5kd2lkdGggdG8gZmVlZCBpdCB0byBh cyBtYW55IHBlZXBzIGFzIGNhbiBmaXQgaW4gYSByZWdpb24uIEknbGwgdGFsayB0byBvdXIgaW50 ZXJuYWwgcGVlcHMgYXQgTEwsIGJ1dCBJJ2xsIGhhdmUgdG8gc3RvcCBzaG9ydCBvZiB2b2x1bnRl ZXJpbmcgb3RoZXJzIGluIG15IG9yZ2FuaXphdGlvbi4KCkFuZCByaWdodC4uLiBoYXZpbmcgc29t ZW9uZSBhdCB0aGUgbWVldGluZyB3aG8gaXMgbG9nZ2VkIGluIGFuZCBjYW4gcmVsYXkgY2hhdHRl ciB3b3VsZCBsZXQgY29tbWVudHMgZ28gdGhlIG90aGVyIHdheS4KCkFzIGZvciB0aGUgcGVhbnV0 IGdhbGxlcnkuLi4gd2UgZG8gb2theSBAIEFXRyBtZWV0aW5nIGluIHRlcm1zIG9mIGhhbmRsaW5n IHRoZSBvY2Nhc2lvbmFsIGdyaWVmZXIuLi4KCi1jaGVlcnMKLWluZmluaXR5IC8gbWVhZGhiaAoK Um9kbmV5IFRoYXllciA8cnRoYXllckBzZWNvcml4LmNvbT4gd3JvdGU6Cgo+VGhlcmUgYXJlIHRl Y2hub2xvZ2llcyBiZWluZyB1c2VkIHRvIGdhaW4gcmVtb3RlIGFjY2VzcyB0byBJRVRGDQo+bWVl dGluZ3MsIEkgYmVsaWV2ZS4gIFNlZSBmb3IgZXhhbXBsZSB0aGlzLi4uDQo+DQo+aHR0cDovL3Zp ZGVvbGFiLnVvcmVnb24uZWR1L2V2ZW50cy9pZXRmLw0KPg0KPlRoZXkndmUgYmVlbiBub29kbGlu ZyB3aXRoIG9mZnNpdGUgYWNjZXNzIHRvIElFVEYgbWVldGluZ3MNCj5mb3IgYSB3aGlsZS4NCj4N Cj5JZiB0aGVyZSdzIHNvbWUgcHVibGljIGluZm9ybWF0aW9uIG9uIGhvdyBhbiBpbi13b3JsZCBw YXJhbGxlbA0KPm1lZXRpbmcgY291bGQgb2NjdXIgdXNpbmcgYW55IG9mIHRoZXNlIHByb3RvY29s cyB0aGF0J2QgYmUNCj5hbiBpbnRlcmVzdGluZyB1c2UgY2FzZS4gIEl0IHdhcyBteSBpbXByZXNz aW9uIHRoYXQgdGhlIHN0YXRlDQo+b2YgdGhlIGFydCBpcyBub3QgcXVpdGUgdGhlcmUuDQo+DQo+ DQo+TGF3c29uIEVuZ2xpc2ggd3JvdGU6DQo+PiBTZWVtcyB0byBtZSB0aGF0IGl0IHdvdWxkIGJl IGEgZ3JlYXQgdGhpbmcgKGVzcGVjaWFsbHkgZm9yIHRob3NlIG9mIHVzDQo+PiB3aG8gY2FuJ3Qg bWFrZSBpdCkgaWYgdGhlIG1tb3ggQk9GIHdhcyBoZWxkIG9yIGF0IGxlYXN0IGJyb2FkY2FzdA0K Pj4gaW4td29ybGQsIGxpdmUuIFRoaXMgd291bGQgYmUgc3ltYm9saWMgQU5EIGFsbG93IHRob3Nl IG9mIHVzIHdobyBjYW4ndA0KPj4gYmUgdGhlcmUgdG8gYXQgbGVhc3Qga25vdyB3aGF0IGlzIGdv aW5nIG9uLCBldmVuIGlmIHRoZSBJRVRGIHJ1bGVzDQo+PiB3b3VsZG4ndCBhbGxvdyB1cyB0byBw YXJ0aWNpcGF0ZSBmdWxseS4NCj4+IA0KPj4gV2hpY2ggYnJpbmdzIHVwIGFub3RoZXIgcG9pbnQ6 IHdoYXQgQVJFIHRoZSBJRVRGIHJ1bGVzIGNvbmNlcm5pbmcgcmVtb3RlDQo+PiBwYXJ0aWNpcGF0 aW9uIHZpYSBWUj8gSSdtIGd1ZXNzaW5nIHRoZXkgZG9uJ3QgZXhpc3QgYXMgeWV0LiBTaG91bGQg dGhhdA0KPj4gYmUgc29tZXRoaW5nIHRoYXQgaXMgd29ya2VkIG91dCBiZWZvcmUgdGhlIG1lZXRp bmc/IENhbiBwZW9wbGUgd2hvIGFyZQ0KPj4gdW5hYmxlIHRvIG1ha2UgdGhlIG1lZXRpZyBnZXQg c29tZSBraW5kIG9mIHJlY29nbml6ZWQgc3RhdHVzIGF0IHRoZQ0KPj4gbWVldGluZz8gRXZlbiBw ZWFudXQgZ2FsbGVyeSBjaGF0dGVyIGFsYSBNZXRhbm9taWNzIG9yIFNjaWVuY2UgRnJpZGF5DQo+ PiB3b3VsZCBiZSBhIGdvb2Qgc3RhcnQuDQo+PiANCj4+IA0KPj4gTGF3c29uDQo+PiANCj4+IA0K Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG1t b3ggbWFpbGluZyBsaXN0DQo+PiBtbW94QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21tb3gNCj4+IA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+bW1veCBtYWlsaW5nIGxpc3QNCj5tbW94QGlldGYu b3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbW94DQo= ------XA5XJRVECWWJH2854OMPDOS43G6E8V-- From tme@multicasttech.com Sun Feb 8 14:35:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 412F43A69B7 for ; Sun, 8 Feb 2009 14:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.464 X-Spam-Level: X-Spam-Status: No, score=-103.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhbxAlyNImrD for ; Sun, 8 Feb 2009 14:35:47 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 8AB3C3A68F6 for ; Sun, 8 Feb 2009 14:35:47 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14566631; Sun, 08 Feb 2009 17:34:56 -0500 Message-Id: From: Marshall Eubanks To: "Infinity Linden (Meadhbh S. Hamrick)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 8 Feb 2009 17:35:51 -0500 References: X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" , Rodney Thayer Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 22:35:49 -0000 On Feb 8, 2009, at 5:22 PM, Infinity Linden (Meadhbh S. Hamrick) wrote: > Cool. Getting video into SL should be easy. We just bounce a stream > off someone with the bandwidth to feed it to as many peeps as can > fit in a region. I'll talk to our internal peeps at LL, but I'll > have to stop short of volunteering others in my organization. > My broadcasts (AmericaFree.TV) have been going into Second Life for some years now. However, IETF broadcasting at the moment is audio only, not video. There would be no issue with having a live video feed, and we used to broadcast live multicast video, but that was stopped in 2005 IIRC. The biggest reason for that was cost - audio doesn't require a person in the room, while video (at least, the way it was done), did. Regards Marshall > And right... having someone at the meeting who is logged in and can > relay chatter would let comments go the other way. > > As for the peanut gallery... we do okay @ AWG meeting in terms of > handling the occasional griefer... > > -cheers > -infinity / meadhbh > > Rodney Thayer wrote: > >> There are technologies being used to gain remote access to IETF >> meetings, I believe. See for example this... >> >> http://videolab.uoregon.edu/events/ietf/ >> >> They've been noodling with offsite access to IETF meetings >> for a while. >> >> If there's some public information on how an in-world parallel >> meeting could occur using any of these protocols that'd be >> an interesting use case. It was my impression that the state >> of the art is not quite there. >> >> >> Lawson English wrote: >>> Seems to me that it would be a great thing (especially for those >>> of us >>> who can't make it) if the mmox BOF was held or at least broadcast >>> in-world, live. This would be symbolic AND allow those of us who >>> can't >>> be there to at least know what is going on, even if the IETF rules >>> wouldn't allow us to participate fully. >>> >>> Which brings up another point: what ARE the IETF rules concerning >>> remote >>> participation via VR? I'm guessing they don't exist as yet. Should >>> that >>> be something that is worked out before the meeting? Can people who >>> are >>> unable to make the meetig get some kind of recognized status at the >>> meeting? Even peanut gallery chatter ala Metanomics or Science >>> Friday >>> would be a good start. >>> >>> >>> Lawson >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From lenglish5@cox.net Sun Feb 8 15:19:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CE943A68B8 for ; Sun, 8 Feb 2009 15:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3pcVDJS1or7 for ; Sun, 8 Feb 2009 15:19:36 -0800 (PST) Received: from fed1rmmtao104.cox.net (fed1rmmtao104.cox.net [68.230.241.42]) by core3.amsl.com (Postfix) with ESMTP id 630FA3A6886 for ; Sun, 8 Feb 2009 15:19:36 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090208231941.PAFF11567.fed1rmmtao104.cox.net@fed1rmimpo03.cox.net>; Sun, 8 Feb 2009 18:19:41 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id DbKg1b00U4N6T0Q04bKgyT; Sun, 08 Feb 2009 18:19:41 -0500 X-Authority-Analysis: v=1.0 c=1 a=_Pk5SSxGuSsA:10 a=esVFqgeMqEEA:10 a=Wajolswj7cQA:10 a=MV82w4yxjEbrEQFnBs4A:9 a=4r7QtDShoKIhLU6bjhAtZVJe6swA:4 a=5WZzfXpOq_gA:10 X-CM-Score: 0.00 Message-ID: <498F688C.6020709@cox.net> Date: Sun, 08 Feb 2009 16:19:40 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Infinity Linden (Meadhbh S. Hamrick)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , Rodney Thayer Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 23:19:37 -0000 Infinity Linden (Meadhbh S. Hamrick) wrote: > Cool. Getting video into SL should be easy. We just bounce a stream off someone with the bandwidth to feed it to as many peeps as can fit in a region. I'll talk to our internal peeps at LL, but I'll have to stop short of volunteering others in my organization. > Why stop at one region? Talk to the Metanomics folk about setting up a multi-island venue. They would have been happy to help with the last AWG meeting and I'm sure they'd be happy to help with this. L. From DrScofield@xyzzyxyzzy.net Mon Feb 9 09:52:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F063A6AB3 for ; Mon, 9 Feb 2009 09:52:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pE4g7v5ToaUW for ; Mon, 9 Feb 2009 09:52:11 -0800 (PST) Received: from mtagate8.uk.ibm.com (mtagate8.uk.ibm.com [195.212.29.141]) by core3.amsl.com (Postfix) with ESMTP id 3A5253A69A9 for ; Mon, 9 Feb 2009 09:52:08 -0800 (PST) Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate8.uk.ibm.com (8.13.8/8.13.8) with ESMTP id n19HnnqJ049686 for ; Mon, 9 Feb 2009 17:49:49 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n19HnnJ43510318 for ; Mon, 9 Feb 2009 17:49:49 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n19Hnnkd008202 for ; Mon, 9 Feb 2009 17:49:49 GMT Received: from inn.zurich.ibm.com (inn.zurich.ibm.com [9.4.4.229]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n19Hnmc3008195 for ; Mon, 9 Feb 2009 17:49:49 GMT Received: from rieti (h001f160b5489.visitors.zurich.ibm.com [9.4.21.141]) by inn.zurich.ibm.com (AIX5.3/8.13.4/8.13.4) with ESMTP id n19HnmGW688176 for ; Mon, 9 Feb 2009 18:49:48 +0100 Received: from [127.0.0.1] (localhost [127.0.0.1]) by rieti (Postfix) with ESMTP id 820024C0067 for ; Mon, 9 Feb 2009 18:49:48 +0100 (CET) Message-ID: <49906CBC.7060306@xyzzyxyzzy.net> Date: Mon, 09 Feb 2009 18:49:48 +0100 From: Dr Scofield Organization: IBM Research User-Agent: Thunderbird 2.0.0.18 (X11/20081105) MIME-Version: 1.0 CC: mmox@ietf.org References: <498C2777.4090506@xyzzyxyzzy.net> <498CC17E.5020606@secorix.com> In-Reply-To: <498CC17E.5020606@secorix.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] rezzme URI scheme: addressing locations/grids (SLURLs are bad, bad, bad) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 17:52:12 -0000 Rodney Thayer wrote: > (somebody has to say it...) > > V6 address wouldn't work, right? why not? > We're not routing packets > between worlds so that doesn't make sense, right? But... we're > routing (stuff) between (places) and so lots of prior art, er, work, > might provide insight. X.400 email addresses and X.500 distinguished > names come to mind. A TLD for SL and the other virtual worlds > that are public and/or have registered names? > i tend to stay away from X.400 and X.500 DNs... in my experience they are not really working that well in everyday settings. [...] dirk/DrS -- dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab SL: dr scofield ---- drscofield@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/ RL: hud@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ From infinity@lindenlab.com Mon Feb 9 13:23:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 709773A672F for ; Mon, 9 Feb 2009 13:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15Bk4loX1o5u for ; Mon, 9 Feb 2009 13:23:21 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id BE3783A6874 for ; Mon, 9 Feb 2009 13:23:21 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id E69EF3DBC097; Mon, 9 Feb 2009 13:23:23 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: lenglish5@cox.net In-Reply-To: <498F688C.6020709@cox.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Feb 2009 13:23:23 -0800 References: <498F688C.6020709@cox.net> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" , Rodney Thayer Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 21:23:22 -0000 well.. first things first. i'm just thinking that the incremental from 0 virtual consumers of real-time A/V to 40 consumers will be a lot harder than the incremental from 40 to 160. On Feb 8, 2009, at 3:19 PM, Lawson English wrote: > Infinity Linden (Meadhbh S. Hamrick) wrote: >> Cool. Getting video into SL should be easy. We just bounce a stream >> off someone with the bandwidth to feed it to as many peeps as can >> fit in a region. I'll talk to our internal peeps at LL, but I'll >> have to stop short of volunteering others in my organization. >> > > Why stop at one region? Talk to the Metanomics folk about setting up > a multi-island venue. They would have been happy to help with the > last AWG meeting and I'm sure they'd be happy to help with this. > > > L. From infinity@lindenlab.com Mon Feb 9 13:33:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29DF43A6BB4 for ; Mon, 9 Feb 2009 13:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SL-jc9vxLcID for ; Mon, 9 Feb 2009 13:33:23 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 19C413A6B2E for ; Mon, 9 Feb 2009 13:33:23 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id CE0763DBC097; Mon, 9 Feb 2009 13:33:25 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Feb 2009 13:33:25 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" , Rodney Thayer Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 21:33:24 -0000 okay.. a couple things.. a. I hope it's not a violation of IETF SoP to allow a video simulcast only for the BoF, maybe as a proof of concept. b. while broadcasting into SL would be nice, the big win would be to somehow allow second life avatars to participate in discussions. So having someone at the BoF logged into SL and relaying questions / comments would be required (like Science Friday does it now.) c. we probably have our hands full with the normal BoF planning, so should we take baby steps and implement audio broadcast to SL for the upcoming March meeting, but delay full SL / IETF interaction for a later date? -cheers -m On Feb 8, 2009, at 2:35 PM, Marshall Eubanks wrote: > > > On Feb 8, 2009, at 5:22 PM, Infinity Linden (Meadhbh S. Hamrick) > wrote: > >> Cool. Getting video into SL should be easy. We just bounce a stream >> off someone with the bandwidth to feed it to as many peeps as can >> fit in a region. I'll talk to our internal peeps at LL, but I'll >> have to stop short of volunteering others in my organization. >> > > My broadcasts (AmericaFree.TV) have been going into Second Life for > some years now. > > However, IETF broadcasting at the moment is audio only, not video. > There would be > no issue with having a live video feed, and we used to broadcast > live multicast video, but that > was stopped in 2005 IIRC. > > The biggest reason for that was cost - audio doesn't require a > person in the room, while video (at least, the > way it was done), did. > > Regards > Marshall > >> And right... having someone at the meeting who is logged in and can >> relay chatter would let comments go the other way. >> >> As for the peanut gallery... we do okay @ AWG meeting in terms of >> handling the occasional griefer... >> >> -cheers >> -infinity / meadhbh >> >> Rodney Thayer wrote: >> >>> There are technologies being used to gain remote access to IETF >>> meetings, I believe. See for example this... >>> >>> http://videolab.uoregon.edu/events/ietf/ >>> >>> They've been noodling with offsite access to IETF meetings >>> for a while. >>> >>> If there's some public information on how an in-world parallel >>> meeting could occur using any of these protocols that'd be >>> an interesting use case. It was my impression that the state >>> of the art is not quite there. >>> >>> >>> Lawson English wrote: >>>> Seems to me that it would be a great thing (especially for those >>>> of us >>>> who can't make it) if the mmox BOF was held or at least broadcast >>>> in-world, live. This would be symbolic AND allow those of us who >>>> can't >>>> be there to at least know what is going on, even if the IETF rules >>>> wouldn't allow us to participate fully. >>>> >>>> Which brings up another point: what ARE the IETF rules concerning >>>> remote >>>> participation via VR? I'm guessing they don't exist as yet. >>>> Should that >>>> be something that is worked out before the meeting? Can people >>>> who are >>>> unable to make the meetig get some kind of recognized status at the >>>> meeting? Even peanut gallery chatter ala Metanomics or Science >>>> Friday >>>> would be a good start. >>>> >>>> >>>> Lawson >>>> >>>> >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > From rthayer@secorix.com Mon Feb 9 13:40:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5C43A6C04 for ; Mon, 9 Feb 2009 13:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkRjrzTslI4b for ; Mon, 9 Feb 2009 13:40:58 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.176]) by core3.amsl.com (Postfix) with ESMTP id 286693A6BB4 for ; Mon, 9 Feb 2009 13:40:58 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so1511065ele.13 for ; Mon, 09 Feb 2009 13:40:59 -0800 (PST) Received: by 10.142.157.9 with SMTP id f9mr3170380wfe.87.1234215658786; Mon, 09 Feb 2009 13:40:58 -0800 (PST) Received: from ?10.252.254.103? (m195-163.dsl.rawbw.com [198.144.195.163]) by mx.google.com with ESMTPS id 27sm12055935wff.28.2009.02.09.13.40.56 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Feb 2009 13:40:57 -0800 (PST) Message-ID: <4990A2E6.20502@secorix.com> Date: Mon, 09 Feb 2009 13:40:54 -0800 From: Rodney Thayer User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "mmox@ietf.org" References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 21:40:59 -0000 I think anything you do to promote multi-site access to IETF meetings is going to be welcomed. I think solid small baby steps sound wonderful. I think those of you who wish for rich media experiences should blog vigorously so lots of IETF'ers ask for more. It's 2009. Make shameless references to how you're not asking your boss for travel budget and use provocative terms like "improved training ROI". Meadhbh Hamrick (Infinity) wrote: > okay.. a couple things.. > > a. I hope it's not a violation of IETF SoP to allow a video simulcast > only for the BoF, maybe as a proof of concept. > > b. while broadcasting into SL would be nice, the big win would be to > somehow allow second life avatars to participate in discussions. So > having someone at the BoF logged into SL and relaying questions / > comments would be required (like Science Friday does it now.) > > c. we probably have our hands full with the normal BoF planning, so > should we take baby steps and implement audio broadcast to SL for the > upcoming March meeting, but delay full SL / IETF interaction for a later > date? > > -cheers > -m > > On Feb 8, 2009, at 2:35 PM, Marshall Eubanks wrote: > >> >> >> On Feb 8, 2009, at 5:22 PM, Infinity Linden (Meadhbh S. Hamrick) wrote: >> >>> Cool. Getting video into SL should be easy. We just bounce a stream >>> off someone with the bandwidth to feed it to as many peeps as can fit >>> in a region. I'll talk to our internal peeps at LL, but I'll have to >>> stop short of volunteering others in my organization. >>> >> >> My broadcasts (AmericaFree.TV) have been going into Second Life for >> some years now. >> >> However, IETF broadcasting at the moment is audio only, not video. >> There would be >> no issue with having a live video feed, and we used to broadcast live >> multicast video, but that >> was stopped in 2005 IIRC. >> >> The biggest reason for that was cost - audio doesn't require a person >> in the room, while video (at least, the >> way it was done), did. >> >> Regards >> Marshall >> >>> And right... having someone at the meeting who is logged in and can >>> relay chatter would let comments go the other way. >>> >>> As for the peanut gallery... we do okay @ AWG meeting in terms of >>> handling the occasional griefer... >>> >>> -cheers >>> -infinity / meadhbh >>> >>> Rodney Thayer wrote: >>> >>>> There are technologies being used to gain remote access to IETF >>>> meetings, I believe. See for example this... >>>> >>>> http://videolab.uoregon.edu/events/ietf/ >>>> >>>> They've been noodling with offsite access to IETF meetings >>>> for a while. >>>> >>>> If there's some public information on how an in-world parallel >>>> meeting could occur using any of these protocols that'd be >>>> an interesting use case. It was my impression that the state >>>> of the art is not quite there. >>>> >>>> >>>> Lawson English wrote: >>>>> Seems to me that it would be a great thing (especially for those of us >>>>> who can't make it) if the mmox BOF was held or at least broadcast >>>>> in-world, live. This would be symbolic AND allow those of us who can't >>>>> be there to at least know what is going on, even if the IETF rules >>>>> wouldn't allow us to participate fully. >>>>> >>>>> Which brings up another point: what ARE the IETF rules concerning >>>>> remote >>>>> participation via VR? I'm guessing they don't exist as yet. Should >>>>> that >>>>> be something that is worked out before the meeting? Can people who are >>>>> unable to make the meetig get some kind of recognized status at the >>>>> meeting? Even peanut gallery chatter ala Metanomics or Science Friday >>>>> would be a good start. >>>>> >>>>> >>>>> Lawson >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmox mailing list >>>>> mmox@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmox >>>>> >>>> >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> > > From tme@multicasttech.com Mon Feb 9 14:13:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29183A6C0A for ; Mon, 9 Feb 2009 14:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.465 X-Spam-Level: X-Spam-Status: No, score=-103.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dGheH9NHdu5 for ; Mon, 9 Feb 2009 14:13:55 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 054A83A6B3C for ; Mon, 9 Feb 2009 14:13:54 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14578583; Mon, 09 Feb 2009 17:12:56 -0500 Message-Id: <1D575C73-D745-48AC-922E-3A24683C2273@multicasttech.com> From: Marshall Eubanks To: "Meadhbh Hamrick (Infinity)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Feb 2009 17:13:54 -0500 References: X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" , Rodney Thayer Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 22:13:58 -0000 On Feb 9, 2009, at 4:33 PM, Meadhbh Hamrick (Infinity) wrote: > okay.. a couple things.. > > a. I hope it's not a violation of IETF SoP to allow a video > simulcast only for the BoF, maybe as a proof of concept. > I don't see why it would be, but I have made inquiries to be sure. > b. while broadcasting into SL would be nice, the big win would be to > somehow allow second life avatars to participate in discussions. So > having someone at the BoF logged into SL and relaying questions / > comments would be required (like Science Friday does it now.) Something like that has been done before, passing questions manually to the chairs from virtual attendees (but without avatars). You should make sure that this gets posted to the attendees list. > > > c. we probably have our hands full with the normal BoF planning, so > should we take baby steps and implement audio broadcast to SL for > the upcoming March meeting, but delay full SL / IETF interaction for > a later date? > Given that there will be a MP3 audio feed anyway, does anything actually have to be done for this ? Regards Marshall > -cheers > -m > > On Feb 8, 2009, at 2:35 PM, Marshall Eubanks wrote: > >> >> >> On Feb 8, 2009, at 5:22 PM, Infinity Linden (Meadhbh S. Hamrick) >> wrote: >> >>> Cool. Getting video into SL should be easy. We just bounce a >>> stream off someone with the bandwidth to feed it to as many peeps >>> as can fit in a region. I'll talk to our internal peeps at LL, but >>> I'll have to stop short of volunteering others in my organization. >>> >> >> My broadcasts (AmericaFree.TV) have been going into Second Life for >> some years now. >> >> However, IETF broadcasting at the moment is audio only, not video. >> There would be >> no issue with having a live video feed, and we used to broadcast >> live multicast video, but that >> was stopped in 2005 IIRC. >> >> The biggest reason for that was cost - audio doesn't require a >> person in the room, while video (at least, the >> way it was done), did. >> >> Regards >> Marshall >> >>> And right... having someone at the meeting who is logged in and >>> can relay chatter would let comments go the other way. >>> >>> As for the peanut gallery... we do okay @ AWG meeting in terms of >>> handling the occasional griefer... >>> >>> -cheers >>> -infinity / meadhbh >>> >>> Rodney Thayer wrote: >>> >>>> There are technologies being used to gain remote access to IETF >>>> meetings, I believe. See for example this... >>>> >>>> http://videolab.uoregon.edu/events/ietf/ >>>> >>>> They've been noodling with offsite access to IETF meetings >>>> for a while. >>>> >>>> If there's some public information on how an in-world parallel >>>> meeting could occur using any of these protocols that'd be >>>> an interesting use case. It was my impression that the state >>>> of the art is not quite there. >>>> >>>> >>>> Lawson English wrote: >>>>> Seems to me that it would be a great thing (especially for those >>>>> of us >>>>> who can't make it) if the mmox BOF was held or at least broadcast >>>>> in-world, live. This would be symbolic AND allow those of us who >>>>> can't >>>>> be there to at least know what is going on, even if the IETF rules >>>>> wouldn't allow us to participate fully. >>>>> >>>>> Which brings up another point: what ARE the IETF rules >>>>> concerning remote >>>>> participation via VR? I'm guessing they don't exist as yet. >>>>> Should that >>>>> be something that is worked out before the meeting? Can people >>>>> who are >>>>> unable to make the meetig get some kind of recognized status at >>>>> the >>>>> meeting? Even peanut gallery chatter ala Metanomics or Science >>>>> Friday >>>>> would be a good start. >>>>> >>>>> >>>>> Lawson >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmox mailing list >>>>> mmox@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmox >>>>> >>>> >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> > From suzyque@gmail.com Mon Feb 9 15:48:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 979D83A6BD9 for ; Mon, 9 Feb 2009 15:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV8tKBD9acH4 for ; Mon, 9 Feb 2009 15:48:15 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id D56103A680C for ; Mon, 9 Feb 2009 15:48:14 -0800 (PST) Received: by qyk4 with SMTP id 4so3114237qyk.13 for ; Mon, 09 Feb 2009 15:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=K7Np0lskjHokXMp+pAJzHDmYeVbhsxLJ0XibYUNCEbE=; b=ttQ15wtmTfEm94r3YpW5HNqXYm3/wozb9aMzVslcuyS/fG6cTu/UiSSw3UEhAX8wc6 erscRV3PwbJBqDXt2XHwHFsD76rfMV6Z7yC29rHKt+SsIKxvNiYrdXvYR+kUcIVCL7GI uuN3pUehcaffdADXAwOFHj1EBYijMpEl8CmJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NF6n0MT/HXPKwdJxFKWj6tsz+DMlxc2li65Rcb/ECfkkCk96wy1eD7Yzebgo+a+lFE Y7JU5Pxj+tendH5w+X8zTSycpKCvdb9FVC7eKSh0Qv4vDrbqR6vvNDpDCeppGOl0ALLQ xtA8HAoUDRIsnT4FTXo4bjFmocbrCMMSuvHEo= MIME-Version: 1.0 Sender: suzyque@gmail.com Received: by 10.214.184.8 with SMTP id h8mr2586858qaf.313.1234223296303; Mon, 09 Feb 2009 15:48:16 -0800 (PST) In-Reply-To: <1D575C73-D745-48AC-922E-3A24683C2273@multicasttech.com> References: <1D575C73-D745-48AC-922E-3A24683C2273@multicasttech.com> Date: Mon, 9 Feb 2009 17:48:16 -0600 X-Google-Sender-Auth: dc8332ec2ab1b894 Message-ID: <2bd5b7f10902091548x60b5ac16q8a10c4807d20456f@mail.gmail.com> From: Suzy Deffeyes To: Marshall Eubanks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Rodney Thayer , "mmox@ietf.org" Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: suzyq@pobox.com List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 23:48:15 -0000 > Given that there will be a MP3 audio feed anyway, does anything actually have to be done for this ? Infinity, We can always low tech it for the BoF, and have an open IRC channel for back chat. That gives us a lot of the capability to get input from people that aren't there in person. Suzy Deffeyes IBM From lenglish5@cox.net Mon Feb 9 15:58:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC5843A6C1A for ; Mon, 9 Feb 2009 15:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.914 X-Spam-Level: X-Spam-Status: No, score=0.914 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmFUCeyuiVAD for ; Mon, 9 Feb 2009 15:58:54 -0800 (PST) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id F0F6028C17D for ; Mon, 9 Feb 2009 15:58:53 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090209235857.MUVK2948.fed1rmmtao101.cox.net@fed1rmimpo02.cox.net>; Mon, 9 Feb 2009 18:58:57 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id Dzyw1b0034N6T0Q04zywhJ; Mon, 09 Feb 2009 18:58:56 -0500 X-Authority-Analysis: v=1.0 c=1 a=_Pk5SSxGuSsA:10 a=esVFqgeMqEEA:10 a=Wajolswj7cQA:10 a=4T6gq-Yga2RPnBKCsnwA:9 a=UmiqFyF15PaBs2DD3YQtSdg5wOoA:4 a=72oxJoRhc8oA:10 X-CM-Score: 0.00 Message-ID: <4990C33F.2060800@cox.net> Date: Mon, 09 Feb 2009 16:58:55 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rodney Thayer , "mmox@ietf.org" Subject: Re: [mmox] In-world simul-cast of BOF? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 23:58:54 -0000 Meadhbh Hamrick (Infinity) wrote: > okay.. a couple things.. > > a. I hope it's not a violation of IETF SoP to allow a video simulcast > only for the BoF, maybe as a proof of concept. > > b. while broadcasting into SL would be nice, the big win would be to > somehow allow second life avatars to participate in discussions. So > having someone at the BoF logged into SL and relaying questions / > comments would be required (like Science Friday does it now.) > > c. we probably have our hands full with the normal BoF planning, so > should we take baby steps and implement audio broadcast to SL for the > upcoming March meeting, but delay full SL / IETF interaction for a > later date? Infinity, before you decide its too hard, talk to Beyers Sellers and his Metanomics team. They offered to host the in-world part of the AWG meeting last year on the Metanomics venue, which meant we get the multi-island hookup for free. Also, you can ask about what is required to handle the I/O of questions and comments to/from the live venue. The problems are pretty much solved already. L From morgaine.dinova@googlemail.com Tue Feb 10 03:20:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F143A6820 for ; Tue, 10 Feb 2009 03:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DOuwy-O+UJ4 for ; Tue, 10 Feb 2009 03:20:32 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 4E2C63A6A7A for ; Tue, 10 Feb 2009 03:20:32 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so2145171rvf.49 for ; Tue, 10 Feb 2009 03:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EtwJ/Jv3RY9Qej8BdLVWDvKektTSGml8HQrTr/UNCRs=; b=HpquRTiILz9P/9kWrbx29SNalbD1ev/I5BFj/dCL2vrPH3b1dFg+otOTmWUz5pAj0k 31lLdQkuaBsq7Wx5ZQNOUifQmzNRqkFIem43rzYygo9NxHCcxcjdWhKMCYWzZnfFFehk XcU9FrJ5bMwEkXtd/ivkCMkwfjWwKb3BNqEGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hZnN+59+P+LL5dOCP/OPWWf2X1VfCxi0pq6j335lemY7e7rPUXfi9QXyRJZ7lvaoWf oKV2HuHKwY2F+W6hj3vtujRqydrEEr1lCfyncuenbwMra9cNDcmtX/ETBnYhDRT2S/nq PJbJk/K7JH9CV2Q66dzqVWESa+GbaS7fMOUUM= MIME-Version: 1.0 Received: by 10.141.96.19 with SMTP id y19mr4593585rvl.89.1234264835305; Tue, 10 Feb 2009 03:20:35 -0800 (PST) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> Date: Tue, 10 Feb 2009 11:20:35 +0000 Message-ID: From: Morgaine Dinova To: "mmox@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd1a8e4112f8f04628ead59 Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 11:20:38 -0000 --000e0cd1a8e4112f8f04628ead59 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: >> Description of Working Group: >> >> 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 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 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: >> >> August 2009 Rough consensus on a set of base VW protocols >> October 2009 Publication of LLSD 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 >> > > >> 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. > --000e0cd1a8e4112f8f04628ead59 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In order to move our work on the MMOX charter along, and in view of the lac= k of further input on the latest version for some days now, I have taken In= finity's comments as being strongly substantive and therefore have adde= d words to express the goal of open, non-proprietary ownership.  The f= irst paragraph of the charter had already mentioned that proprietary protoc= ols were used in the past, and therefore this is an appropriate place to in= sert that our work seeks an open, non-proprietary alternative.

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

This new draf= t below becomes our latest version.  The previous first paragraph has = been expanded slightly as explained above, and the LL implementation-specif= ic RFC about simulators has been removed from MMOX milestones as per my pre= vious submission (containing the reasons for the change) which did not elic= it comment:




Description of Working Group:

Virtual Worlds and other Massively Multi-Party Online Applications are of i= ncreasing 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 exp= ected to grow to beyond 50 million by 2011, creators of such systems have b= egun to look at ways to make such systems interoperate. There have been sev= eral ad hoc efforts since 2007 to develop interoperability. We believe that= this goal will now benefit from a formal, established process defining ope= n, non-proprietary standards as infrastructure for virtual world interopera= bility.

The objective of the MMOX working group is to provide an application-layer = wire protocol for Virtual Worlds to a) enable interoperability between appl= ications, b) provide for access and exchange with other systems on the Inte= rnet 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 p= rotocols to communicate and interact with the state of Virtual World applic= ations. Foundational protocols will be evaluated for: 1) representing appli= cation layer objects and serializing messages between these objects, 2) pro= viding a messaging abstraction layer to support the unique needs of VW inte= ractions, and 3) authenticating protocol endpoints. An attempt will be made= to use existing standards wherever possible. For example, image data is ty= ped 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 comp= lete protocol, but the definition of a extensible core protocol with additi= onal layers of agreed functionality as they are developed. Because the foun= dational protocols can be deployed before the entire range of VW functions = is considered, we believe that the efforts of the MMOX working group are ac= hievable 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
February 2010 Progression of base VW protocols to a Proposed Standard
February 2010 Progression of Virtual World Primitive Object Format to Propo= sed Standard
February 2010 Rough consensus on a VW Authentication and VW Teleport protoc= ol
June 2010 Progression of VW Authentication to Proposed Standard
June 2010 Progression of VW Teleport to Proposed Standard



 

Ideally we sho= uld have some representatives from other virtual worlds taking part through= out this work, including at this early charter creation stage, but in their= absence the burden of keeping our goals and protocols applicable to more t= han 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.<= br>
Morgaine.

--000e0cd1a8e4112f8f04628ead59-- From infinity@lindenlab.com Tue Feb 10 09:15:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D29F43A6B84 for ; Tue, 10 Feb 2009 09:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quVcGqJApEmE for ; Tue, 10 Feb 2009 09:15:19 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 6410E3A6A5A for ; Tue, 10 Feb 2009 09:15:19 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 7FDDD3DBC06C; Tue, 10 Feb 2009 09:15:21 -0800 (PST) Message-Id: <8AC7B20A-027B-468C-A9D4-60C4BB2CFECE@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Morgaine Dinova In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2-428365737 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 09:15:19 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: [mmox] Making Progress as a Working Group [was: Re: Proposed draft charter and milestone list] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 17:15:20 -0000 --Apple-Mail-2-428365737 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable One aspect of IETF working groups is they are expected to have =20 concrete objectives and milestones. "rough consensus on a set of base =20= VW protocols" is not an appropriate milestone for a working group. It =20= may be a milestone for a group of people trying to make a working =20 group, but not for the working group itself. (which probably explains =20= why we're having a BoF instead of a working group meeting.) I believe =20= the intent of the group is to publish standards for virtual worlds =20 interactions, not to establish rough consensus for some future work. =20 That being said, we'll obviously have to establish rough consensus as =20= a pre-requisite for establishing a standard, i'm just arguing "rough =20 consensus" for at least some of the aspects of the wire protocol need =20= to be in place before launching the group. The benefit of pursuing work on specific drafts in a working group is =20= the community at large gets to participate in the development on the =20 spec. Informational independent submissions to the RFC Editor; that =20 is, proposals that are not intended to be draft standards do not need =20= to go through the working group process. So "publication of LLSD Draft =20= as an Informational RFC" can be pursued as a working group item, but =20 honestly, our time is probably better spent on other tasks unless we =20 want to move LLSD forward as part of a draft standard. -cheers -m/=E2=88=9E 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 =20= > the lack of further input on the latest version for some days now, I =20= > have taken Infinity's comments as being strongly substantive and =20 > therefore have added words to express the goal of open, non-=20 > proprietary ownership. The first paragraph of the charter had =20 > already mentioned that proprietary protocols were used in the past, =20= > and therefore this is an appropriate place to insert that our work =20 > seeks an open, non-proprietary alternative. > > Note that I have not revised the phrase "application-layer wire =20 > protocol" as we do not appear to have converged on a good =20 > alternative form of expression yet. Possibly there is no need. > > This new draft below becomes our latest version. The previous first =20= > paragraph has been expanded slightly as explained above, and the LL =20= > implementation-specific RFC about simulators has been removed from =20 > MMOX milestones as per my previous submission (containing the =20 > reasons for the change) which did not elicit comment: > > > > > Description of Working Group: > > Virtual Worlds and other Massively Multi-Party Online Applications =20 > are of increasing interest to the Internet community. Numerous =20 > examples exist of such applications, mostly using proprietary =20 > protocols. With their roots in games and social interaction, Virtual =20= > Worlds are now being increasingly used in business, education and =20 > information exchange. With a user base expected to grow to beyond 50 =20= > million by 2011, creators of such systems have begun to look at ways =20= > to make such systems interoperate. There have been several ad hoc =20 > efforts since 2007 to develop interoperability. We believe that this =20= > goal will now benefit from a formal, established process defining =20 > open, non-proprietary standards as infrastructure for virtual world =20= > interoperability. > > The objective of the MMOX working group is to provide an application-=20= > layer wire protocol for Virtual Worlds to a) enable interoperability =20= > between applications, b) provide for access and exchange with other =20= > systems on the Internet such as identity providers, web services, e-=20= > mail and other information storage systems, c) allow network layers =20= > to recognize VW traffic and make routing decisions based on its =20 > characteristics. > > The core work of the group will be the production of a set of =20 > application protocols to communicate and interact with the state of =20= > Virtual World applications. Foundational protocols will be evaluated =20= > for: 1) representing application layer objects and serializing =20 > messages between these objects, 2) providing a messaging abstraction =20= > layer to support the unique needs of VW interactions, and 3) =20 > authenticating protocol endpoints. An attempt will be made to use =20 > existing standards wherever possible. For example, image data is =20 > typed and transferred using MIME and HTTP; message serializations =20 > are encoded in XML and JSON. > > The MMOX working group is not proposing the standardization of any =20 > one complete protocol, but the definition of a extensible core =20 > protocol with additional layers of agreed functionality as they are =20= > developed. Because the foundational protocols can be deployed before =20= > the entire range of VW functions is considered, we believe that the =20= > efforts of the MMOX working group are achievable within a reasonable =20= > 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 > February 2010 Progression of base VW protocols to a Proposed Standard > February 2010 Progression of Virtual World Primitive Object Format =20 > to Proposed Standard > February 2010 Rough consensus on a VW Authentication and VW Teleport =20= > protocol > June 2010 Progression of VW Authentication to Proposed Standard > June 2010 Progression of VW Teleport to Proposed Standard > > > > > > Ideally we should have some representatives from other virtual =20 > worlds taking part throughout this work, including at this early =20 > charter creation stage, but in their absence the burden of keeping =20 > our goals and protocols applicable to more than just the SL family =20 > of worlds falls on our own shoulders. I think that these =20 > modifications have probably put us on the right track at least. > > Morgaine. > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-2-428365737 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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/=E2=88=9E

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.

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:




Description of Working Group:

= 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 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 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:

August 2009 = Rough consensus on a set of base VW protocols
October 2009 =  Publication of LLSD 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



 

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.
=

= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mmox

= --Apple-Mail-2-428365737-- From john.hurliman@intel.com Tue Feb 10 09:40:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4B913A6C47 for ; Tue, 10 Feb 2009 09:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFZpE4cdKs3M for ; Tue, 10 Feb 2009 09:40:09 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 9E7BE3A69FD for ; Tue, 10 Feb 2009 09:40:09 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 10 Feb 2009 09:33:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,187,1233561600"; d="scan'208";a="488857141" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by orsmga001.jf.intel.com with ESMTP; 10 Feb 2009 09:40:00 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Tue, 10 Feb 2009 10:40:12 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Tue, 10 Feb 2009 10:40:10 -0700 Thread-Topic: [mmox] Making Progress as a Working Group [was: Re: Proposed draft charter and milestone list] Thread-Index: AcmLoy6gxDhKcCaCToCa/TkW/Pso1QAArJRQ Message-ID: <62BFE5680C037E4DA0B0A08946C0933D5003F298@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <8AC7B20A-027B-468C-A9D4-60C4BB2CFECE@lindenlab.com> In-Reply-To: <8AC7B20A-027B-468C-A9D4-60C4BB2CFECE@lindenlab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mmox] Making Progress as a Working Group [was: Re: Proposed draft charter and milestone list] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 17:40:10 -0000 VGhlcmUgc2VlbXMgdG8gYmUgYSBiYWxhbmNpbmcgYWN0IGJldHdlZW4gZW51bWVyYXRpbmcgYWxs IG9mIHRoZSBkcmFmdHMgd2Ugd2lsbCBwcm9wb3NlIHRvIHR1cm4gaW50byBzdGFuZGFyZHMgYW5k IGV2YWx1YXRpbmcgd2hpY2ggZHJhZnRzIGhhdmUgbWVyaXQgaW4gdGhlIGxhcmdlciBjb250ZXh0 IG9mIHRoZSBNTU9YLiBJIGFtIHByZXBhcmluZyBhIGRyYWZ0IHRoYXQgd2lsbCBob3BlZnVsbHkg bWFrZSB0aGUgTWFyY2ggMm5kIGRlYWRsaW5lIChub3Qgc3VyZSBob3cgbG9uZyB0aGUgaW50ZXJu YWwgbGVnYWwgcHJvY2VzcyB3aWxsIHRha2UpLiBTaG91bGQgd2Ugd2FpdCB1bnRpbCBpdCBpcyBy ZWFkeSB0byBleHBsaWNpdGx5IGFkZCBpdCB0byB0aGUgY2hhcnRlciBhbmQgdGltZWxpbmUsIG9y IGNhbiB3ZSB1c2UgbGFuZ3VhZ2UgdGhhdCBpcyBjb25jcmV0ZSBlbm91Z2ggdG8gbW92ZSBmb3J3 YXJkIGJ1dCBzdGlsbCBlbmNvbXBhc3NlcyBvdGhlciBkcmFmdCBwcm9wb3NhbHM/DQoNCkpvaG4N Cg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbW1veC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bW1veC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj5NZWFkaGJo IEhhbXJpY2sgKEluZmluaXR5KQ0KPlNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDEwLCAyMDA5IDk6 MTUgQU0NCj5UbzogTW9yZ2FpbmUgRGlub3ZhDQo+Q2M6IG1tb3hAaWV0Zi5vcmcNCj5TdWJqZWN0 OiBbbW1veF0gTWFraW5nIFByb2dyZXNzIGFzIGEgV29ya2luZyBHcm91cCBbd2FzOiBSZTogUHJv cG9zZWQNCj5kcmFmdCBjaGFydGVyIGFuZCBtaWxlc3RvbmUgbGlzdF0NCj4NCj5PbmUgYXNwZWN0 IG9mIElFVEYgd29ya2luZyBncm91cHMgaXMgdGhleSBhcmUgZXhwZWN0ZWQgdG8gaGF2ZSBjb25j cmV0ZQ0KPm9iamVjdGl2ZXMgYW5kIG1pbGVzdG9uZXMuICJyb3VnaCBjb25zZW5zdXMgb24gYSBz ZXQgb2YgYmFzZSBWVw0KPnByb3RvY29scyIgaXMgbm90IGFuIGFwcHJvcHJpYXRlIG1pbGVzdG9u ZSBmb3IgYSB3b3JraW5nIGdyb3VwLiBJdCBtYXkNCj5iZSBhIG1pbGVzdG9uZSBmb3IgYSBncm91 cCBvZiBwZW9wbGUgdHJ5aW5nIHRvIG1ha2UgYSB3b3JraW5nIGdyb3VwLCBidXQNCj5ub3QgZm9y IHRoZSB3b3JraW5nIGdyb3VwIGl0c2VsZi4gKHdoaWNoIHByb2JhYmx5IGV4cGxhaW5zIHdoeSB3 ZSdyZQ0KPmhhdmluZyBhIEJvRiBpbnN0ZWFkIG9mIGEgd29ya2luZyBncm91cCBtZWV0aW5nLikg SSBiZWxpZXZlIHRoZSBpbnRlbnQNCj5vZiB0aGUgZ3JvdXAgaXMgdG8gcHVibGlzaCBzdGFuZGFy ZHMgZm9yIHZpcnR1YWwgd29ybGRzIGludGVyYWN0aW9ucywNCj5ub3QgdG8gZXN0YWJsaXNoIHJv dWdoIGNvbnNlbnN1cyBmb3Igc29tZSBmdXR1cmUgd29yay4gVGhhdCBiZWluZyBzYWlkLA0KPndl J2xsIG9idmlvdXNseSBoYXZlIHRvIGVzdGFibGlzaCByb3VnaCBjb25zZW5zdXMgYXMgYSBwcmUt cmVxdWlzaXRlIGZvcg0KPmVzdGFibGlzaGluZyBhIHN0YW5kYXJkLCBpJ20ganVzdCBhcmd1aW5n ICJyb3VnaCBjb25zZW5zdXMiIGZvciBhdCBsZWFzdA0KPnNvbWUgb2YgdGhlIGFzcGVjdHMgb2Yg dGhlIHdpcmUgcHJvdG9jb2wgbmVlZCB0byBiZSBpbiBwbGFjZSBiZWZvcmUNCj5sYXVuY2hpbmcg dGhlIGdyb3VwLg0KPg0KPlRoZSBiZW5lZml0IG9mIHB1cnN1aW5nIHdvcmsgb24gc3BlY2lmaWMg ZHJhZnRzIGluIGEgd29ya2luZyBncm91cCBpcw0KPnRoZSBjb21tdW5pdHkgYXQgbGFyZ2UgZ2V0 cyB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgZGV2ZWxvcG1lbnQgb24gdGhlDQo+c3BlYy4gSW5mb3Jt YXRpb25hbCBpbmRlcGVuZGVudCBzdWJtaXNzaW9ucyB0byB0aGUgUkZDIEVkaXRvcjsgdGhhdCBp cywNCj5wcm9wb3NhbHMgdGhhdCBhcmUgbm90IGludGVuZGVkIHRvIGJlIGRyYWZ0IHN0YW5kYXJk cyBkbyBub3QgbmVlZCB0byBnbw0KPnRocm91Z2ggdGhlIHdvcmtpbmcgZ3JvdXAgcHJvY2Vzcy4g U28gInB1YmxpY2F0aW9uIG9mIExMU0QgRHJhZnQgYXMgYW4NCj5JbmZvcm1hdGlvbmFsIFJGQyIg Y2FuIGJlIHB1cnN1ZWQgYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0sIGJ1dCBob25lc3RseSwNCj5v dXIgdGltZSBpcyBwcm9iYWJseSBiZXR0ZXIgc3BlbnQgb24gb3RoZXIgdGFza3MgdW5sZXNzIHdl IHdhbnQgdG8gbW92ZQ0KPkxMU0QgZm9yd2FyZCBhcyBwYXJ0IG9mIGEgZHJhZnQgc3RhbmRhcmQu DQo+DQo+LWNoZWVycw0KPi1tL+KIng0KPg0KPk9uIEZlYiAxMCwgMjAwOSwgYXQgMzoyMCBBTSwg TW9yZ2FpbmUgRGlub3ZhIHdyb3RlOg0KPg0KPg0KPglJbiBvcmRlciB0byBtb3ZlIG91ciB3b3Jr IG9uIHRoZSBNTU9YIGNoYXJ0ZXIgYWxvbmcsIGFuZCBpbiB2aWV3DQo+b2YgdGhlIGxhY2sgb2Yg ZnVydGhlciBpbnB1dCBvbiB0aGUgbGF0ZXN0IHZlcnNpb24gZm9yIHNvbWUgZGF5cyBub3csIEkN Cj5oYXZlIHRha2VuIEluZmluaXR5J3MgY29tbWVudHMgYXMgYmVpbmcgc3Ryb25nbHkgc3Vic3Rh bnRpdmUgYW5kDQo+dGhlcmVmb3JlIGhhdmUgYWRkZWQgd29yZHMgdG8gZXhwcmVzcyB0aGUgZ29h bCBvZiBvcGVuLCBub24tcHJvcHJpZXRhcnkNCj5vd25lcnNoaXAuICBUaGUgZmlyc3QgcGFyYWdy YXBoIG9mIHRoZSBjaGFydGVyIGhhZCBhbHJlYWR5IG1lbnRpb25lZA0KPnRoYXQgcHJvcHJpZXRh cnkgcHJvdG9jb2xzIHdlcmUgdXNlZCBpbiB0aGUgcGFzdCwgYW5kIHRoZXJlZm9yZSB0aGlzIGlz DQo+YW4gYXBwcm9wcmlhdGUgcGxhY2UgdG8gaW5zZXJ0IHRoYXQgb3VyIHdvcmsgc2Vla3MgYW4g b3Blbiwgbm9uLQ0KPnByb3ByaWV0YXJ5IGFsdGVybmF0aXZlLg0KPg0KPglOb3RlIHRoYXQgSSBo YXZlIG5vdCByZXZpc2VkIHRoZSBwaHJhc2UgImFwcGxpY2F0aW9uLWxheWVyIHdpcmUNCj5wcm90 b2NvbCIgYXMgd2UgZG8gbm90IGFwcGVhciB0byBoYXZlIGNvbnZlcmdlZCBvbiBhIGdvb2QgYWx0 ZXJuYXRpdmUNCj5mb3JtIG9mIGV4cHJlc3Npb24geWV0LiAgUG9zc2libHkgdGhlcmUgaXMgbm8g bmVlZC4NCj4NCj4JVGhpcyBuZXcgZHJhZnQgYmVsb3cgYmVjb21lcyBvdXIgbGF0ZXN0IHZlcnNp b24uICBUaGUgcHJldmlvdXMNCj5maXJzdCBwYXJhZ3JhcGggaGFzIGJlZW4gZXhwYW5kZWQgc2xp Z2h0bHkgYXMgZXhwbGFpbmVkIGFib3ZlLCBhbmQgdGhlDQo+TEwgaW1wbGVtZW50YXRpb24tc3Bl Y2lmaWMgUkZDIGFib3V0IHNpbXVsYXRvcnMgaGFzIGJlZW4gcmVtb3ZlZCBmcm9tDQo+TU1PWCBt aWxlc3RvbmVzIGFzIHBlciBteSBwcmV2aW91cyBzdWJtaXNzaW9uIChjb250YWluaW5nIHRoZSBy ZWFzb25zDQo+Zm9yIHRoZSBjaGFuZ2UpIHdoaWNoIGRpZCBub3QgZWxpY2l0IGNvbW1lbnQ6DQo+ DQo+DQo+DQo+DQo+DQo+DQo+CQkJRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCj4NCj4J CQlWaXJ0dWFsIFdvcmxkcyBhbmQgb3RoZXIgTWFzc2l2ZWx5IE11bHRpLVBhcnR5IE9ubGluZQ0K PkFwcGxpY2F0aW9ucyBhcmUgb2YgaW5jcmVhc2luZyBpbnRlcmVzdCB0byB0aGUgSW50ZXJuZXQg Y29tbXVuaXR5Lg0KPk51bWVyb3VzIGV4YW1wbGVzIGV4aXN0IG9mIHN1Y2ggYXBwbGljYXRpb25z LCBtb3N0bHkgdXNpbmcgcHJvcHJpZXRhcnkNCj5wcm90b2NvbHMuIFdpdGggdGhlaXIgcm9vdHMg aW4gZ2FtZXMgYW5kIHNvY2lhbCBpbnRlcmFjdGlvbiwgVmlydHVhbA0KPldvcmxkcyBhcmUgbm93 IGJlaW5nIGluY3JlYXNpbmdseSB1c2VkIGluIGJ1c2luZXNzLCBlZHVjYXRpb24gYW5kDQo+aW5m b3JtYXRpb24gZXhjaGFuZ2UuIFdpdGggYSB1c2VyIGJhc2UgZXhwZWN0ZWQgdG8gZ3JvdyB0byBi ZXlvbmQgNTANCj5taWxsaW9uIGJ5IDIwMTEsIGNyZWF0b3JzIG9mIHN1Y2ggc3lzdGVtcyBoYXZl IGJlZ3VuIHRvIGxvb2sgYXQgd2F5cyB0bw0KPm1ha2Ugc3VjaCBzeXN0ZW1zIGludGVyb3BlcmF0 ZS4gVGhlcmUgaGF2ZSBiZWVuIHNldmVyYWwgYWQgaG9jIGVmZm9ydHMNCj5zaW5jZSAyMDA3IHRv IGRldmVsb3AgaW50ZXJvcGVyYWJpbGl0eS4gV2UgYmVsaWV2ZSB0aGF0IHRoaXMgZ29hbCB3aWxs DQo+bm93IGJlbmVmaXQgZnJvbSBhIGZvcm1hbCwgZXN0YWJsaXNoZWQgcHJvY2VzcyBkZWZpbmlu ZyBvcGVuLCBub24tDQo+cHJvcHJpZXRhcnkgc3RhbmRhcmRzIGFzIGluZnJhc3RydWN0dXJlIGZv ciB2aXJ0dWFsIHdvcmxkDQo+aW50ZXJvcGVyYWJpbGl0eS4NCj4NCj4NCj4JCQlUaGUgb2JqZWN0 aXZlIG9mIHRoZSBNTU9YIHdvcmtpbmcgZ3JvdXAgaXMgdG8gcHJvdmlkZQ0KPmFuIGFwcGxpY2F0 aW9uLWxheWVyIHdpcmUgcHJvdG9jb2wgZm9yIFZpcnR1YWwgV29ybGRzIHRvIGEpIGVuYWJsZQ0K PmludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBhcHBsaWNhdGlvbnMsIGIpIHByb3ZpZGUgZm9yIGFj Y2VzcyBhbmQNCj5leGNoYW5nZSB3aXRoIG90aGVyIHN5c3RlbXMgb24gdGhlIEludGVybmV0IHN1 Y2ggYXMgaWRlbnRpdHkgcHJvdmlkZXJzLA0KPndlYiBzZXJ2aWNlcywgZS1tYWlsIGFuZCBvdGhl ciBpbmZvcm1hdGlvbiBzdG9yYWdlIHN5c3RlbXMsIGMpIGFsbG93DQo+bmV0d29yayBsYXllcnMg dG8gcmVjb2duaXplIFZXIHRyYWZmaWMgYW5kIG1ha2Ugcm91dGluZyBkZWNpc2lvbnMgYmFzZWQN Cj5vbiBpdHMgY2hhcmFjdGVyaXN0aWNzLg0KPg0KPg0KPgkJCVRoZSBjb3JlIHdvcmsgb2YgdGhl IGdyb3VwIHdpbGwgYmUgdGhlIHByb2R1Y3Rpb24gb2YgYQ0KPnNldCBvZiBhcHBsaWNhdGlvbiBw cm90b2NvbHMgdG8gY29tbXVuaWNhdGUgYW5kIGludGVyYWN0IHdpdGggdGhlIHN0YXRlDQo+b2Yg VmlydHVhbCBXb3JsZCBhcHBsaWNhdGlvbnMuIEZvdW5kYXRpb25hbCBwcm90b2NvbHMgd2lsbCBi ZSBldmFsdWF0ZWQNCj5mb3I6IDEpIHJlcHJlc2VudGluZyBhcHBsaWNhdGlvbiBsYXllciBvYmpl Y3RzIGFuZCBzZXJpYWxpemluZyBtZXNzYWdlcw0KPmJldHdlZW4gdGhlc2Ugb2JqZWN0cywgMikg cHJvdmlkaW5nIGEgbWVzc2FnaW5nIGFic3RyYWN0aW9uIGxheWVyIHRvDQo+c3VwcG9ydCB0aGUg dW5pcXVlIG5lZWRzIG9mIFZXIGludGVyYWN0aW9ucywgYW5kIDMpIGF1dGhlbnRpY2F0aW5nDQo+ cHJvdG9jb2wgZW5kcG9pbnRzLiBBbiBhdHRlbXB0IHdpbGwgYmUgbWFkZSB0byB1c2UgZXhpc3Rp bmcgc3RhbmRhcmRzDQo+d2hlcmV2ZXIgcG9zc2libGUuIEZvciBleGFtcGxlLCBpbWFnZSBkYXRh IGlzIHR5cGVkIGFuZCB0cmFuc2ZlcnJlZA0KPnVzaW5nIE1JTUUgYW5kIEhUVFA7IG1lc3NhZ2Ug c2VyaWFsaXphdGlvbnMgYXJlIGVuY29kZWQgaW4gWE1MIGFuZCBKU09OLg0KPg0KPg0KPgkJCVRo ZSBNTU9YIHdvcmtpbmcgZ3JvdXAgaXMgbm90IHByb3Bvc2luZyB0aGUNCj5zdGFuZGFyZGl6YXRp b24gb2YgYW55IG9uZSBjb21wbGV0ZSBwcm90b2NvbCwgYnV0IHRoZSBkZWZpbml0aW9uIG9mIGEN Cj5leHRlbnNpYmxlIGNvcmUgcHJvdG9jb2wgd2l0aCBhZGRpdGlvbmFsIGxheWVycyBvZiBhZ3Jl ZWQgZnVuY3Rpb25hbGl0eQ0KPmFzIHRoZXkgYXJlIGRldmVsb3BlZC4gQmVjYXVzZSB0aGUgZm91 bmRhdGlvbmFsIHByb3RvY29scyBjYW4gYmUNCj5kZXBsb3llZCBiZWZvcmUgdGhlIGVudGlyZSBy YW5nZSBvZiBWVyBmdW5jdGlvbnMgaXMgY29uc2lkZXJlZCwgd2UNCj5iZWxpZXZlIHRoYXQgdGhl IGVmZm9ydHMgb2YgdGhlIE1NT1ggd29ya2luZyBncm91cCBhcmUgYWNoaWV2YWJsZSB3aXRoaW4N Cj5hIHJlYXNvbmFibGUgdGltZSBmcmFtZS4NCj4NCj4NCj4NCj4NCj4NCj4JCQlHb2FscyBhbmQg TWlsZXN0b25lczoNCj4NCj4JCQlBdWd1c3QgMjAwOSBSb3VnaCBjb25zZW5zdXMgb24gYSBzZXQg b2YgYmFzZSBWVw0KPnByb3RvY29scw0KPgkJCU9jdG9iZXIgMjAwOSAgUHVibGljYXRpb24gb2Yg TExTRCBEcmFmdCBhcyBhbg0KPkluZm9ybWF0aW9uYWwgUkZDDQo+CQkJRmVicnVhcnkgMjAxMCBQ cm9ncmVzc2lvbiBvZiBiYXNlIFZXIHByb3RvY29scyB0byBhDQo+UHJvcG9zZWQgU3RhbmRhcmQN Cj4JCQlGZWJydWFyeSAyMDEwIFByb2dyZXNzaW9uIG9mIFZpcnR1YWwgV29ybGQgUHJpbWl0aXZl DQo+T2JqZWN0IEZvcm1hdCB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPgkJCUZlYnJ1YXJ5IDIwMTAg Um91Z2ggY29uc2Vuc3VzIG9uIGEgVlcgQXV0aGVudGljYXRpb24NCj5hbmQgVlcgVGVsZXBvcnQg cHJvdG9jb2wNCj4JCQlKdW5lIDIwMTAgUHJvZ3Jlc3Npb24gb2YgVlcgQXV0aGVudGljYXRpb24g dG8gUHJvcG9zZWQNCj5TdGFuZGFyZA0KPgkJCUp1bmUgMjAxMCBQcm9ncmVzc2lvbiBvZiBWVyBU ZWxlcG9ydCB0byBQcm9wb3NlZA0KPlN0YW5kYXJkDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+CQlJ ZGVhbGx5IHdlIHNob3VsZCBoYXZlIHNvbWUgcmVwcmVzZW50YXRpdmVzIGZyb20gb3RoZXINCj52 aXJ0dWFsIHdvcmxkcyB0YWtpbmcgcGFydCB0aHJvdWdob3V0IHRoaXMgd29yaywgaW5jbHVkaW5n IGF0IHRoaXMgZWFybHkNCj5jaGFydGVyIGNyZWF0aW9uIHN0YWdlLCBidXQgaW4gdGhlaXIgYWJz ZW5jZSB0aGUgYnVyZGVuIG9mIGtlZXBpbmcgb3VyDQo+Z29hbHMgYW5kIHByb3RvY29scyBhcHBs aWNhYmxlIHRvIG1vcmUgdGhhbiBqdXN0IHRoZSBTTCBmYW1pbHkgb2Ygd29ybGRzDQo+ZmFsbHMg b24gb3VyIG93biBzaG91bGRlcnMuICBJIHRoaW5rIHRoYXQgdGhlc2UgbW9kaWZpY2F0aW9ucyBo YXZlDQo+cHJvYmFibHkgcHV0IHVzIG9uIHRoZSByaWdodCB0cmFjayBhdCBsZWFzdC4NCj4NCj4J CU1vcmdhaW5lLg0KPg0KPg0KPg0KPglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPgltbW94IG1haWxpbmcgbGlzdA0KPgltbW94QGlldGYub3JnDQo+CWh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW1veA0KPg0KPg0KDQo+IA0K From jwatte@gmail.com Tue Feb 10 13:03:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA7623A6991 for ; Tue, 10 Feb 2009 13:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67ghrdyQinbK for ; Tue, 10 Feb 2009 13:03:55 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 7BB4D3A693B for ; Tue, 10 Feb 2009 13:03:55 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so32612ana.4 for ; Tue, 10 Feb 2009 13:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=XPza+QPQaLBB0mxBuSh1GL8Cnefp0xD3jn3qXBGWZmg=; b=xf4B4p+IgHDS++9iMNncJFQQvLBg9Bh1+eDT0m940JJm1nUQWly+A95mq7jKKyDMMN fp8o5ZUbbPrBg5SXw7En/1GFEdxUAzpzAU+TT95CB6fG0dWuziXb2pf80TVBno19hOEs FaW+JpWIXqkvDGV8UkI3KzCfRpkmAF5Ghc+I0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fZstJTmNbTIh3a2XH7MZ0ZFhQ471MErQHyfqOVeWfr1UHuBl7LOqaFI0hLQpyJbxPv zPMefs0V+5+5gAkAGgu3vPVJtQbsWvl9mtuIqfEDCX+AEEAHmTR3i9KN0kxMqSegIKey ncQ5eV/sCIEMVz5arGBU6KDMwrT8iZQ4W4Rrk= Received: by 10.100.128.20 with SMTP id a20mr2533578and.148.1234299838731; Tue, 10 Feb 2009 13:03:58 -0800 (PST) Received: from ?192.168.168.106? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d29sm10016112and.34.2009.02.10.13.03.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Feb 2009 13:03:57 -0800 (PST) Message-ID: <4991EBBB.2060603@gmail.com> Date: Tue, 10 Feb 2009 13:03:55 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine Dinova References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 21:03:56 -0000 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: October 2009 Publication of LLSD Draft as an Informational RFC Is using the LLSD proposal already a foregone conclusion? Sincererly, jw 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. > > 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: > > > > > Description of Working Group: > > 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 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 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: > > August 2009 Rough consensus on a set of base VW protocols > October 2009 Publication of LLSD 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 > > > > > > > > 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From infinity@lindenlab.com Tue Feb 10 14:03:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22AD43A6818 for ; Tue, 10 Feb 2009 14:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEOXfc1rBee9 for ; Tue, 10 Feb 2009 14:03:40 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id EF2F33A67AC for ; Tue, 10 Feb 2009 14:03:39 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 843F83DBC06C; Tue, 10 Feb 2009 14:03:42 -0800 (PST) Message-Id: <96318886-2CAB-4060-B11A-FB55C0C8B3F0@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <4991EBBB.2060603@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 14:03:42 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <4991EBBB.2060603@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 22:03:41 -0000 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: > > > 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: > > October 2009 Publication of LLSD Draft as an Informational RFC > > Is using the LLSD proposal already a foregone conclusion? > > Sincererly, > > jw > > > 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. >> >> 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: >> >> >> >> >> Description of Working Group: >> >> 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 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 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: >> >> August 2009 Rough consensus on a set of base VW protocols >> October 2009 Publication of LLSD 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 >> >> >> >> >> >> >> 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. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Tue Feb 10 14:09:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 765F53A6C65 for ; Tue, 10 Feb 2009 14:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAFowoqXrTGw for ; Tue, 10 Feb 2009 14:09:29 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 48F3C3A63CB for ; Tue, 10 Feb 2009 14:09:29 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 0DA153DBC06C; Tue, 10 Feb 2009 14:09:33 -0800 (PST) Message-Id: <706F1984-2127-45D5-992B-6CDB6D875D24@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: "Hurliman, John" In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D5003F298@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 14:09:32 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <8AC7B20A-027B-468C-A9D4-60C4BB2CFECE@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D5003F298@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Making Progress as a Working Group [was: Re: Proposed draft charter and milestone list] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 22:09:30 -0000 John... if you've got something that might be worth discussing, i encourage =20 you to come up with a draft sooner rather than later. remember... =20 draft documents are exactly that... drafts. obviously you want the =20 drafts to be as complete as possible. on the other hand, i'm thinking we're probably going to spend the =20 majority of the time of the f2f meeting discussing objectives and =20 milestones. so if you're worried about getting the concept on the =20 agenda, submitting earlier rather than later is better. also... even =20 if you don't hit the march 2nd deadline there's still a lot of room =20 for discussion on the mailing list. my gut feeling is even after the =20 march f2f meeting, there'll still be a lot of discussion before a WG =20 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 =20 > drafts we will propose to turn into standards and evaluating which =20 > drafts have merit in the larger context of the MMOX. I am preparing =20= > a draft that will hopefully make the March 2nd deadline (not sure =20 > how long the internal legal process will take). Should we wait until =20= > it is ready to explicitly add it to the charter and timeline, or can =20= > we use language that is concrete enough to move forward but still =20 > encompasses other draft proposals? > > John > >> -----Original Message----- >> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On =20 >> Behalf Of >> Meadhbh Hamrick (Infinity) >> Sent: Tuesday, February 10, 2009 9:15 AM >> To: Morgaine Dinova >> Cc: mmox@ietf.org >> 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 =20 >> concrete >> objectives and milestones. "rough consensus on a set of base VW >> protocols" is not an appropriate milestone for a working group. It =20= >> may >> be a milestone for a group of people trying to make a working =20 >> 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 =20 >> intent >> of the group is to publish standards for virtual worlds interactions, >> not to establish rough consensus for some future work. That being =20 >> said, >> we'll obviously have to establish rough consensus as a pre-=20 >> requisite for >> establishing a standard, i'm just arguing "rough consensus" for at =20= >> 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 =20= >> is, >> proposals that are not intended to be draft standards do not need =20 >> to go >> through the working group process. So "publication of LLSD Draft as =20= >> an >> Informational RFC" can be pursued as a working group item, but =20 >> honestly, >> our time is probably better spent on other tasks unless we want to =20= >> move >> LLSD forward as part of a draft standard. >> >> -cheers >> -m/=E2=88=9E >> >> 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 =20 >> now, I >> have taken Infinity's comments as being strongly substantive and >> therefore have added words to express the goal of open, non-=20 >> proprietary >> ownership. The first paragraph of the charter had already mentioned >> that proprietary protocols were used in the past, and therefore =20 >> 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 =20= >> 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: >> >> >> >> >> >> >> Description of Working Group: >> >> 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 =20 >> 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 =20 >> ways to >> make such systems interoperate. There have been several ad hoc =20 >> efforts >> since 2007 to develop interoperability. We believe that this goal =20 >> 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 >> interoperability between applications, b) provide for access and >> exchange with other systems on the Internet such as identity =20 >> providers, >> web services, e-mail and other information storage systems, c) allow >> network layers to recognize VW traffic and make routing decisions =20 >> 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 =20 >> state >> of Virtual World applications. Foundational protocols will be =20 >> evaluated >> for: 1) representing application layer objects and serializing =20 >> 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 =20= >> 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 =20 >> 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 =20 >> 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 >> 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 >> >> >> >> >> >> >> >> Ideally we should have some representatives from other >> virtual worlds taking part throughout this work, including at this =20= >> early >> charter creation stage, but in their absence the burden of keeping =20= >> our >> goals and protocols applicable to more than just the SL family of =20 >> worlds >> falls on our own shoulders. I think that these modifications have >> probably put us on the right track at least. >> >> Morgaine. >> >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From morgaine.dinova@googlemail.com Tue Feb 10 15:36:47 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453193A698C for ; Tue, 10 Feb 2009 15:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEZuNXQbWn17 for ; Tue, 10 Feb 2009 15:36:45 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id C66903A687B for ; Tue, 10 Feb 2009 15:36:45 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so66747rvf.49 for ; Tue, 10 Feb 2009 15:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1QJRuDXvbEZGfwK11O41JDCy6v26Hdyn9TVPv80TBZc=; b=FuTfGKDoscDtIcT83D2wWbYqGw5EW/z5ZLGCua0alduze7IjlO+ZQKmqd6sJwjIfgH YcW6yIfbidDeq8chGHFQ7NYHZFolAvSL0NKI4lg7el0cD1H0H4Yvy/qFDA6Q1uQsvHB7 q7UEMxYuCiBwEJTzwr3Z/pB0U/MUtFF9NnqA8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Mq4Khm5nx30zQ/C1ivAIZN7XHvjtkYHdNH0bvJJittoghSZtcaU5MuD1XmtMx+iT3t K1GNcfLh5jpVVmUt2QS9e75tpffJGKsm/SHoEFBRmxkvXUkVcp6dYW1qUL+qAplg3Lst wynXEi4YVtwrTIxdxcGX31rIfwmETn5pCrVWY= MIME-Version: 1.0 Received: by 10.141.180.5 with SMTP id h5mr4981259rvp.82.1234309008869; Tue, 10 Feb 2009 15:36:48 -0800 (PST) In-Reply-To: <8AC7B20A-027B-468C-A9D4-60C4BB2CFECE@lindenlab.com> References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <8AC7B20A-027B-468C-A9D4-60C4BB2CFECE@lindenlab.com> Date: Tue, 10 Feb 2009 23:36:48 +0000 Message-ID: From: Morgaine Dinova To: "mmox@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd15552044ac3046298f642 Subject: Re: [mmox] Making Progress as a Working Group [was: Re: Proposed draft charter and milestone list] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 23:36:47 -0000 --000e0cd15552044ac3046298f642 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Feb 10, 2009 at 5:15 PM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> 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. > 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. > > 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: > > > > >>> Description of Working Group: >>> >>> 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 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 >>> 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: >>> >>> August 2009 Rough consensus on a set of base VW protocols >>> October 2009 Publication of LLSD 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 >>> >> > > > > >> >>> 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. >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > --000e0cd15552044ac3046298f642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 10, 2009 at 5:15 PM, Meadhbh= Hamrick (Infinity) <infinity@lindenlab.com> wrote:

Informational independent submissions to the RFC Edito= r; that is, proposals that are not intended to be draft standards do not ne= ed to go through the working group process. So "publication of LL= SD Draft as an Informational RFC" can be pursued as a working group it= em, but honestly, our time is probably better spent on other tasks unless w= e 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 fr= om MMOX's list?  This will give LL the freedom to publish this int= ernal 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 ext= ensibility or for other reasons, then a new spec can be defined from that b= ase, 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 appropria= teness within an IETF standards track protocol.  Using LLSD as an init= ial base proposal for data structuring would not imply design endorsement b= y MMOX in the way that making it an MMOX milestone surely would.

Morgaine.




= 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 subst= antive and therefore have added words to express the goal of open, non-prop= rietary ownership.  The first paragraph of the charter had already men= tioned that proprietary protocols were used in the past, and therefore this= is an appropriate place to insert that our work seeks an open, non-proprie= tary alternative.

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

This new dra= ft below becomes our latest version.  The previous first paragraph has= been expanded slightly as explained above, and the LL implementation-speci= fic RFC about simulators has been removed from MMOX milestones as per my pr= evious submission (containing the reasons for the change) which did not eli= cit comment:




Description of Working Group:

Virtual Worlds and other Massi= vely Multi-Party Online Applications are of increasing interest to the Inte= rnet community.  Numerous examples exist of such applications, mostly = using proprietary protocols. With their roots in games and social interacti= on, Virtual Worlds are now being increasingly used in business, education a= nd information exchange. With a user base expected to grow to beyond 50 mil= lion by 2011, creators of such systems have begun to look at ways to make s= uch systems interoperate. There have been several ad hoc efforts since 2007= to develop interoperability. We believe that this goal will now benefit fr= om a formal, established process defining open, non-proprietary standards a= s infrastructure for virtual world interoperability.

The objective of the MMOX working group is to provide an applica= tion-layer wire protocol for Virtual Worlds to a) enable interoperability b= etween 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 traffi= c and make routing decisions based on its characteristics.

The core work of the group will be the production of a set of a= pplication protocols to communicate and interact with the state of Virtual = World applications. Foundational protocols will be evaluated for: 1) repres= enting application layer objects and serializing messages between these obj= ects, 2) providing a messaging abstraction layer to support the unique need= s of VW interactions, and 3) authenticating protocol endpoints. An attempt = will be made to use existing standards wherever possible. For example, imag= e 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 on= e complete protocol, but the definition of a extensible core protocol with = additional layers of agreed functionality as they are developed. Because th= e foundational protocols can be deployed before the entire range of VW func= tions 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 Dr= aft as an Informational RFC
February 2010 Progression of base VW protoc= ols to a Proposed Standard
February 2010 Progression of Virtual World Primitive Object Format to Prop= osed Standard
February 2010 Rough consensus on a VW Authentication and = VW Teleport protocol
June 2010 Progression of VW Authentication to Prop= osed Standard
June 2010 Progression of VW Teleport to Proposed Standard



 

Ideally we should have some re= presentatives from other virtual worlds taking part throughout this work, i= ncluding at this early charter creation stage, but in their absence the bur= den 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 modif= ications have probably put us on the right track at least.

Morgaine.

= _______________________________________________
mmox mailing list
mmox@ietf.org
https://= www.ietf.org/mailman/listinfo/mmox


--000e0cd15552044ac3046298f642-- From infinity@lindenlab.com Tue Feb 10 16:11:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BE13A6835 for ; Tue, 10 Feb 2009 16:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1wgCMIfKz5H for ; Tue, 10 Feb 2009 16:11:54 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id E35133A682A for ; Tue, 10 Feb 2009 16:11:54 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 455363DBC47A; Tue, 10 Feb 2009 16:11:58 -0800 (PST) Message-Id: <0B643D8E-4DD7-486C-8CD0-BD2BF5F54ED8@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Morgaine Dinova In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-3-453364014 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 16:11:57 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <8AC7B20A-027B-468C-A9D4-60C4BB2CFECE@lindenlab.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Making Progress as a Working Group [was: Re: Proposed draft charter and milestone list] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 00:11:56 -0000 --Apple-Mail-3-453364014 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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) > 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. > > > > > 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. >> >> 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: >> >> >> >> >> Description of Working Group: >> >> 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 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 >> 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: >> >> August 2009 Rough consensus on a set of base VW protocols >> October 2009 Publication of LLSD 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 >> >> >> >> >> >> 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. >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > --Apple-Mail-3-453364014 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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) <infinity@lindenlab.com> = 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.




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.

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:




Description of Working Group:

= 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 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 = 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:

August 2009 Rough consensus on a set of = base VW protocols
October 2009  Publication of LLSD 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



 

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.

= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
=



= --Apple-Mail-3-453364014-- From morgaine.dinova@googlemail.com Tue Feb 10 17:48:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 954963A6DA0 for ; Tue, 10 Feb 2009 17:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSgehFo0gK6n for ; Tue, 10 Feb 2009 17:48:22 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id B51683A6D39 for ; Tue, 10 Feb 2009 17:48:22 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so102417rvf.49 for ; Tue, 10 Feb 2009 17:48:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2TqvOtZUZRzNckSlCOVAfcVv28fvCDXuVjHlnqV0HhU=; b=NIfuRkSgyujl4+Fb/eVYCc8V2Z5OGYVDdNRvAUR+3JRDStGtK50mFEqA+e+4TD8Lji 8+RaODTKYfv3geSkHHbLIfRjKGolL1LOuTVBqyQL+MtrpIo3qNH32eSkBN8cYF2NLv9N NFnE+fvuKRjxXTx6ksHeZCLhSolL4AFqRQ/do= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=HyIz6zpcTs6LKKGAcXxONIJMBZYf/gu+xVfhTu90RVJaio1XiNl/h4cVxYRBIgVkvc fM2YFfdOR3Tv0E7aTw3TrkrZ2qx/XQxYPRUfsxAbiXVQSXZzkcU73osVe+JSoVwO6jrE ULCtnl7HOeMmcPPoynSIFtSCV8YFv0YS4f28M= MIME-Version: 1.0 Received: by 10.141.105.18 with SMTP id h18mr4624997rvm.109.1234316906483; Tue, 10 Feb 2009 17:48:26 -0800 (PST) In-Reply-To: <0B643D8E-4DD7-486C-8CD0-BD2BF5F54ED8@lindenlab.com> References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <8AC7B20A-027B-468C-A9D4-60C4BB2CFECE@lindenlab.com> <0B643D8E-4DD7-486C-8CD0-BD2BF5F54ED8@lindenlab.com> Date: Wed, 11 Feb 2009 01:48:26 +0000 Message-ID: From: Morgaine Dinova To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=000e0cd1389ac0515304629acc4c Cc: "mmox@ietf.org" Subject: Re: [mmox] Making Progress as a Working Group [was: Re: Proposed draft charter and milestone list] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 01:48:24 -0000 --000e0cd1389ac0515304629acc4c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 11, 2009 at 12:11 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: and replace it with what? > 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. > > On Feb 10, 2009, at 3:36 PM, Morgaine Dinova wrote: > > > > On Tue, Feb 10, 2009 at 5:15 PM, Meadhbh Hamrick (Infinity) < > infinity@lindenlab.com> 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. > > > > >> 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. >> >> 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: >> >> >> >> >>>> Description of Working Group: >>>> >>>> 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 >>>> 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 >>>> 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: >>>> >>>> August 2009 Rough consensus on a set of base VW protocols >>>> October 2009 Publication of LLSD 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 >>>> >>> >> >> >> >> >>> >>>> 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. >>> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> >> > > --000e0cd1389ac0515304629acc4c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 11, 2009 at 12:11 AM, Meadhb= h Hamrick (Infinity) <infinity@lindenlab.com> wrote:

and replace it with what?

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 t= ake as external input to MMOX.  Creating that RFC would of course be a= Linden milestone, the direct publication of a current Linden production st= andard.

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 standard= s 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 ti= me on it (ie. it's no longer a milestone for MMOX deliberation), and in= stead 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 reco= mmend) 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 w= hat 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 --- advant= ages on all fronts and no disadvantages.

Morgaine.


 

On F= eb 10, 2009, at 3:36 PM, Morgaine Dinova wrote:



On Tue, Fe= b 10, 2009 at 5:15 PM, Meadhbh Hamrick (Infinity) <infinity@lindenlab= .com> wrote:

In= formational independent submissions to the RFC Editor; that is, proposals t= hat are not intended to be draft standards do not need to go through the wo= rking group process. So "publication of LLSD Draft as an Informat= ional RFC" can be pursued as a working group item, but honestly, our t= ime is probably better spent on other tasks unless we want to move LLSD for= ward as part of a draft standard.

I tend to agree with that.

I= n that case, is everyone happy if we remove the LLSD milestone from MMOX= 9;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 ex= tensibility 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 t= o 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 appropri= ateness within an IETF standards track protocol.  Using LLSD as an ini= tial base proposal for data structuring would not imply design endorsement = by MMOX in the way that making it an MMOX milestone surely would.

Morgaine.




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

In order to move our work on the MMOX charte= r 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 subs= tantive and therefore have added words to express the goal of open, non-pro= prietary ownership.  The first paragraph of the charter had already me= ntioned that proprietary protocols were used in the past, and therefore thi= s is an appropriate place to insert that our work seeks an open, non-propri= etary alternative.

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

This new dra= ft below becomes our latest version.  The previous first paragraph has= been expanded slightly as explained above, and the LL implementation-speci= fic RFC about simulators has been removed from MMOX milestones as per my pr= evious submission (containing the reasons for the change) which did not eli= cit comment:




Description of Working Group:

Virtual Worlds and other Massi= vely Multi-Party Online Applications are of increasing interest to the Inte= rnet community.  Numerous examples exist of such applications, mostly = using proprietary protocols. With their roots in games and social interacti= on, Virtual Worlds are now being increasingly used in business, education a= nd information exchange. With a user base expected to grow to beyond 50 mil= lion by 2011, creators of such systems have begun to look at ways to make s= uch systems interoperate. There have been several ad hoc efforts since 2007= to develop interoperability. We believe that this goal will now benefit fr= om a formal, established process defining open, non-proprietary standards a= s infrastructure for virtual world interoperability.

The objective of the MMOX working group is to provide an applica= tion-layer wire protocol for Virtual Worlds to a) enable interoperability b= etween 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 traffi= c and make routing decisions based on its characteristics.

The core work of the group will be the production of a set of a= pplication protocols to communicate and interact with the state of Virtual = World applications. Foundational protocols will be evaluated for: 1) repres= enting application layer objects and serializing messages between these obj= ects, 2) providing a messaging abstraction layer to support the unique need= s of VW interactions, and 3) authenticating protocol endpoints. An attempt = will be made to use existing standards wherever possible. For example, imag= e 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 on= e complete protocol, but the definition of a extensible core protocol with = additional layers of agreed functionality as they are developed. Because th= e foundational protocols can be deployed before the entire range of VW func= tions 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 Dr= aft as an Informational RFC
February 2010 Progression of base VW protoc= ols to a Proposed Standard
February 2010 Progression of Virtual World Primitive Object Format to Prop= osed Standard
February 2010 Rough consensus on a VW Authentication and = VW Teleport protocol
June 2010 Progression of VW Authentication to Prop= osed Standard
June 2010 Progression of VW Teleport to Proposed Standard



 

Ideally we should have some re= presentatives from other virtual worlds taking part throughout this work, i= ncluding at this early charter creation stage, but in their absence the bur= den 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 modif= ications have probably put us on the right track at least.

Morgaine.

= _______________________________________________
mmox mailing list
mmox@ietf.org
https://= www.ietf.org/mailman/listinfo/mmox




--000e0cd1389ac0515304629acc4c-- From jwatte@gmail.com Tue Feb 10 17:51:53 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201313A6A60 for ; Tue, 10 Feb 2009 17:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJ4OX8sp6ZH8 for ; Tue, 10 Feb 2009 17:51:52 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 5136D3A67FB for ; Tue, 10 Feb 2009 17:51:52 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so164959yxm.49 for ; Tue, 10 Feb 2009 17:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=STrEnKicxYvyugOMhEoaeZxJS2kAvVjE3D1o1rfiyOc=; b=JUtPxf2TisfPkgdhw6no7YmljzSn0gEE1BOa6nxuDAKINPe0WdVnBW9vkM8T3cEp6g a5AyVUf6Ch3RJeeMbp+fSKtlohNCVeJafeLOPDG3yYKS2yReFdcv6wGMg7DW+RYC82Ht Tnr4dWx5CLhCq6giG19vJlcumQwDeNYrDDZZU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=aXJrmp9h1xPqKLFFcZAtwT+sSlW4SPeEAEzlDg3OfskkM78BlM1I4a6aVqWM5gH4hI 75eSBbXvFAeps9cLdL8pv2o0AaVHJUSZunYxKW+hGEVXv6+zlxCPBUYeCcsJ7he8tgUB wNTxYZwM5Mq/AnrFnunfE0apmRieiuQcpylwA= Received: by 10.100.119.17 with SMTP id r17mr3921978anc.130.1234317115696; Tue, 10 Feb 2009 17:51:55 -0800 (PST) Received: from ?192.168.168.106? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b7sm15231380ana.59.2009.02.10.17.51.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Feb 2009 17:51:55 -0800 (PST) Message-ID: <49922F38.7000106@gmail.com> Date: Tue, 10 Feb 2009 17:51:52 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <4991EBBB.2060603@gmail.com> <96318886-2CAB-4060-B11A-FB55C0C8B3F0@lindenlab.com> In-Reply-To: <96318886-2CAB-4060-B11A-FB55C0C8B3F0@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 01:51:53 -0000 Meadhbh Hamrick (Infinity) wrote: > 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 infinity@lindenlab.com Tue Feb 10 18:15:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA24D3A6C75 for ; Tue, 10 Feb 2009 18:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BfKpe2MNsOl for ; Tue, 10 Feb 2009 18:15:17 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 39EA73A6B5C for ; Tue, 10 Feb 2009 18:15:17 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id C2E2E3DBC48A; Tue, 10 Feb 2009 18:15:20 -0800 (PST) Message-Id: <726E476C-8E79-492D-B334-1BD0C65E379B@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49922F38.7000106@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 10 Feb 2009 18:15:20 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <4991EBBB.2060603@gmail.com> <96318886-2CAB-4060-B11A-FB55C0C8B3F0@lindenlab.com> <49922F38.7000106@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 02:15:17 -0000 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: > Meadhbh Hamrick (Infinity) wrote: >> 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 lenglish5@cox.net Tue Feb 10 23:01:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3053A6C7E for ; Tue, 10 Feb 2009 23:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84QaeqQuBQLl for ; Tue, 10 Feb 2009 23:01:10 -0800 (PST) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id AEE543A6B93 for ; Tue, 10 Feb 2009 23:01:10 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090211070112.TOXS2948.fed1rmmtao101.cox.net@fed1rmimpo01.cox.net>; Wed, 11 Feb 2009 02:01:12 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id EX1C1b0014N6T0Q03X1CxT; Wed, 11 Feb 2009 02:01:12 -0500 X-Authority-Analysis: v=1.0 c=1 a=N2DjB-moaNEA:10 a=EMxi-gqHSKcA:10 a=Wajolswj7cQA:10 a=vXsOCsqszfej1O5fXYkA:9 a=bapbfo1ekcUkYwBtXBdw69YtX0oA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <499277B8.9040600@cox.net> Date: Wed, 11 Feb 2009 00:01:12 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <4991EBBB.2060603@gmail.com> <96318886-2CAB-4060-B11A-FB55C0C8B3F0@lindenlab.com> <49922F38.7000106@gmail.com> In-Reply-To: <49922F38.7000106@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 07:01:11 -0000 Jon Watte wrote: > Meadhbh Hamrick (Infinity) wrote: >> 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, > 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 tme@multicasttech.com Tue Feb 10 23:23:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5F43A67AC for ; Tue, 10 Feb 2009 23:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.472 X-Spam-Level: X-Spam-Status: No, score=-103.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8E83BEBfMvn for ; Tue, 10 Feb 2009 23:23:18 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id D55183A6834 for ; Tue, 10 Feb 2009 23:23:17 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14597505; Wed, 11 Feb 2009 02:22:15 -0500 Message-Id: <0177DC90-5115-44C1-83E4-A9192F48C736@multicasttech.com> From: Marshall Eubanks To: Meadhbh Hamrick (Infinity) In-Reply-To: <8AC7B20A-027B-468C-A9D4-60C4BB2CFECE@lindenlab.com> Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 02:23:18 -0500 References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <8AC7B20A-027B-468C-A9D4-60C4BB2CFECE@lindenlab.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Making Progress as a Working Group [was: Re: Proposed draft charter and milestone list] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 07:23:19 -0000 On Feb 10, 2009, at 12:15 PM, Meadhbh Hamrick (Infinity) wrote: > One aspect of IETF working groups is they are expected to have =20 > concrete objectives and milestones. "rough consensus on a set of =20 > base VW protocols" is not an appropriate milestone for a working =20 > group. It may be a milestone for a group of people trying to make a =20= > working group, but not for the working group itself. (which probably =20= > explains why we're having a BoF instead of a working group meeting.) =20= > I believe the intent of the group is to publish standards for =20 > virtual worlds interactions, not to establish rough consensus for =20 > some future work. That being said, we'll obviously have to establish =20= > rough consensus as a pre-requisite for establishing a standard, i'm =20= > just arguing "rough consensus" for at least some of the aspects of =20 > the wire protocol need to be in place before launching the group. > > The benefit of pursuing work on specific drafts in a working group =20 > is the community at large gets to participate in the development on =20= > the spec. Informational independent submissions to the RFC Editor; =20 > that is, proposals that are not intended to be draft standards do =20 > not need to go through the working group process. So "publication of =20= > LLSD Draft as an Informational RFC" can be pursued as a working =20 > group item, but honestly, our time is probably better spent on other =20= > 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 =20 HAVE to go through a WG, and a WG would normally publish any drafts =20 (including informational, experimental, etc.) that it thinks need to be published to fulfill its charter and do its work. In fact, you don't =20 HAVE to have a WG at all, you have WG because it improves the process =20= and the result. In the charter I see The core work of the group will be the production of the Open Grid =20 Protocol suite (OGP), a set of application protocols to communicate =20 and interact with the state of Virtual World applications. =20 Foundational protocols in OGP include the publication of: 1) LLSD, an =20= abstract type system for representing application layer objects along =20= 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 =20 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 > > -cheers > -m/=E2=88=9E > > 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 =20= >> the lack of further input on the latest version for some days now, =20= >> I have taken Infinity's comments as being strongly substantive and =20= >> therefore have added words to express the goal of open, non-=20 >> proprietary ownership. The first paragraph of the charter had =20 >> already mentioned that proprietary protocols were used in the past, =20= >> and therefore this is an appropriate place to insert that our work =20= >> seeks an open, non-proprietary alternative. >> >> Note that I have not revised the phrase "application-layer wire =20 >> protocol" as we do not appear to have converged on a good =20 >> alternative form of expression yet. Possibly there is no need. >> >> This new draft below becomes our latest version. The previous =20 >> first paragraph has been expanded slightly as explained above, and =20= >> the LL implementation-specific RFC about simulators has been =20 >> removed from MMOX milestones as per my previous submission =20 >> (containing the reasons for the change) which did not elicit comment: >> >> >> >> >> Description of Working Group: >> >> Virtual Worlds and other Massively Multi-Party Online Applications =20= >> are of increasing interest to the Internet community. Numerous =20 >> examples exist of such applications, mostly using proprietary =20 >> protocols. With their roots in games and social interaction, =20 >> Virtual Worlds are now being increasingly used in business, =20 >> education and information exchange. With a user base expected to =20 >> grow to beyond 50 million by 2011, creators of such systems have =20 >> begun to look at ways to make such systems interoperate. There have =20= >> been several ad hoc efforts since 2007 to develop interoperability. =20= >> We believe that this goal will now benefit from a formal, =20 >> established process defining open, non-proprietary standards as =20 >> infrastructure for virtual world interoperability. >> >> The objective of the MMOX working group is to provide an =20 >> application-layer wire protocol for Virtual Worlds to a) enable =20 >> interoperability between applications, b) provide for access and =20 >> exchange with other systems on the Internet such as identity =20 >> providers, web services, e-mail and other information storage =20 >> systems, c) allow network layers to recognize VW traffic and make =20 >> routing decisions based on its characteristics. >> >> The core work of the group will be the production of a set of =20 >> application protocols to communicate and interact with the state of =20= >> Virtual World applications. Foundational protocols will be =20 >> evaluated for: 1) representing application layer objects and =20 >> serializing messages between these objects, 2) providing a =20 >> messaging abstraction layer to support the unique needs of VW =20 >> interactions, and 3) authenticating protocol endpoints. An attempt =20= >> will be made to use existing standards wherever possible. For =20 >> example, image data is typed and transferred using MIME and HTTP; =20 >> message serializations are encoded in XML and JSON. >> >> The MMOX working group is not proposing the standardization of any =20= >> one complete protocol, but the definition of a extensible core =20 >> protocol with additional layers of agreed functionality as they are =20= >> developed. Because the foundational protocols can be deployed =20 >> before the entire range of VW functions is considered, we believe =20 >> that the efforts of the MMOX working group are achievable within a =20= >> 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 >> February 2010 Progression of base VW protocols to a Proposed Standard >> February 2010 Progression of Virtual World Primitive Object Format =20= >> to Proposed Standard >> February 2010 Rough consensus on a VW Authentication and VW =20 >> Teleport protocol >> June 2010 Progression of VW Authentication to Proposed Standard >> June 2010 Progression of VW Teleport to Proposed Standard >> >> >> >> >> >> Ideally we should have some representatives from other virtual =20 >> worlds taking part throughout this work, including at this early =20 >> charter creation stage, but in their absence the burden of keeping =20= >> our goals and protocols applicable to more than just the SL family =20= >> of worlds falls on our own shoulders. I think that these =20 >> modifications have probably put us on the right track at least. >> >> Morgaine. >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From morgaine.dinova@googlemail.com Wed Feb 11 00:30:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1EB3A69D0 for ; Wed, 11 Feb 2009 00:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjghmNSyxddP for ; Wed, 11 Feb 2009 00:30:07 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 958033A68B0 for ; Wed, 11 Feb 2009 00:30:07 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so19913qwe.31 for ; Wed, 11 Feb 2009 00:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5oltx+GZRtNt2x12DyHk8mLRxi9CsDKHLKnMZo3f7d8=; b=pNz7HZD810nwq6xbQcvQJmabqxsyTm2i7zdFOr15pjPcUUsfLHZSgEk7zULecDW0e+ HbfyQ16rVbXJwq+i3SAPHdsIXzY6oZeT0AYTu176mphZhWOUTC0ef4hg3h3lcfx1GqpX W9b3TcwY68dqPNjdldyi1aA6sBl4mRo/ck3SY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DcFOqxdMEVOoffjuMu8BsSGtJsYnmF4dLxZr3TdLN40SSW3ACICuSV4zOiQnFweF6h OR1Z8E/fvLVEsRnboR5nud08MVOG3jfm5ZENN88gYEKKIU6kFQFlDH0XsmHMKOSQh1xm DJqeKIJuHo2PShUoRPvN3aO7NoXkQT8Fji7DE= MIME-Version: 1.0 Received: by 10.229.82.68 with SMTP id a4mr5142595qcl.18.1234341010048; Wed, 11 Feb 2009 00:30:10 -0800 (PST) In-Reply-To: <726E476C-8E79-492D-B334-1BD0C65E379B@lindenlab.com> References: <62BFE5680C037E4DA0B0A08946C0933D5003E78F@rrsmsx506.amr.corp.intel.com> <4991EBBB.2060603@gmail.com> <96318886-2CAB-4060-B11A-FB55C0C8B3F0@lindenlab.com> <49922F38.7000106@gmail.com> <726E476C-8E79-492D-B334-1BD0C65E379B@lindenlab.com> Date: Wed, 11 Feb 2009 08:30:09 +0000 Message-ID: From: Morgaine Dinova To: "mmox@ietf.org" Content-Type: multipart/alternative; boundary=00163646d3d66f87a20462a06936 Subject: Re: [mmox] Proposed draft charter and milestone list X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 08:30:09 -0000 --00163646d3d66f87a20462a06936 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 currently 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) < infinity@lindenlab.com> wrote: > 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: > > Meadhbh Hamrick (Infinity) wrote: >> >>> 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 >> >> > --00163646d3d66f87a20462a06936 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The unique merit that I see for LLSD as a foundational specification over t= he two mentioned and others is that LLSD provides an Abstract Data Type (AD= T) system WITHOUT mandating a single form of serialization, and therefore i= s 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 "Thre= e serialization schemes are <b>currently</b> defined: XML, JSON= and Binary", which highlights the possibility of defining other seria= lizations at a later date.  (But the draft is inconsistent in this, wh= ich we will need to improve.)  This is a very all-embracing approach t= hat avoids rejecting interop with a particular VW community just because th= ey use a different serialization.

The two examples given by Jon do the exact opposite since they define u= nique mandatory serializations.  I don't think that such rigidity = is helpful when the goal is to bring separate worlds together.  Man= 9;s natural tendency to Balkanize has resulted in a scattering of islands s= peaking a Babel of languages, and LLSD's approach works within this div= ersity by allowing ADT interchange without evangelizing a particular commun= ications 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 w= as deemed not to be and hence was cancelled), we can certainly expect that = they will use Protocol Buffers for their own serialization because Google&#= 39;s entire internal transport ecosystem is based on it, and hence that cho= ice 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= 9;s most efficient language too.  And some world implementors may dive= straight into using Protocol Buffers anyway just for performance reasons.&= nbsp; Choosing an ADT specification with a 1:N relationship to serializatio= ns allows all of this.  It leaves the future open.

This has very important engineering benefits too.  In decoupling t= he ADT from transport details, communications can adapt better to each diff= erent environment.  For example, using restricted capability platforms= such as cellphones to run VW clients has huge interest within the VW commu= nity, but the CPU and bandwidth constraints of such a platform strongly dis= courage 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 seriali= zation has very good merits, in my view.

Morgaine.



On Wed, Feb 11, 200= 9 at 2:15 AM, Meadhbh Hamrick (Infinity) <infinity@lindenlab.com> wrote:<= br>
ASN.1 / BER encod= ing is overkill, currently unused in this community comparatively complicat= ed 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:

Meadhbh Hamrick (Infinity) wrote:
so... short answer... LLSD _is_ a non-vendor-specific solution.

I guess my question is a little higher level than that. Is there a particul= ar 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 t= his particular case? What's wrong with the existing standards in this p= articular area? (And there are literally dozens). Is there a survey somewhe= re that lists the pros and cons?

Sincerely,

jw



--00163646d3d66f87a20462a06936-- From cathypfeffer@gmail.com Wed Feb 11 02:32:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889EE3A6A4F for ; Wed, 11 Feb 2009 02:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4HWU-iYisRv for ; Wed, 11 Feb 2009 02:32:21 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 5DAB43A6C20 for ; Wed, 11 Feb 2009 02:32:21 -0800 (PST) Received: by ewy14 with SMTP id 14so100187ewy.13 for ; Wed, 11 Feb 2009 02:32:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=iBwEp4a9hcuRvgZdVwUnriet5XDUSjeQc44D/XMaSss=; b=MaR6XKMfoJA56IqgWE/UwBwhfiTD6HTR8xuXn97WpuZ12WteL7y+URTiwWf8Ac0aX9 L3pGvDeRitAI3RPQFvdBDqeArDDeF5j/VEUQTkalbe8mO8/4/43bF+WG/eaE3JmQ74Zu XUVOji3uO+K+GD/DhyV0V+CpLx3UOpMNvG71M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hhndcSAy1I4nFdl3M4QEFtmRs/Lt1DHLLzOrdh9u1ZZrkX+TRIMJ3KakBzBurjTcmu gAGjf1C7GTVCy8gzWAgE/fkqcf8AHJL7KdXRPnNap3ukSvYmmSfGuahXJEYopribd8yH 6E1r4oc74hSVqCST4GZZ2hg6wrDHBQwilX9k8= MIME-Version: 1.0 Received: by 10.211.196.13 with SMTP id y13mr1477878ebp.79.1234348343641; Wed, 11 Feb 2009 02:32:23 -0800 (PST) Date: Wed, 11 Feb 2009 11:32:23 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c0cec8d45e70462a21ec2 Subject: [mmox] Proposal for small enhancement in the LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 10:32:22 -0000 --0015174c0cec8d45e70462a21ec2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all, I propose to add to the xxSD draft: "Agreement on the type of serialization used is not in the scope of this document" to show that we've thought about the problem of the negociation of type of serialization. Or if there is a preferred serialization, like XML, mention it. Or if the type of used serialization is hardwired into a given grid, say it. Or if all grids are supposed to support all types of serialization, say it. But my feeling is that currently this point is left in the dark. Sorry in advance if this point is mentioned in the draft and I have missed it. I tend to read things a bit quickly because of lack of time. -- Catherine Pfeffer --0015174c0cec8d45e70462a21ec2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all,


I propose to add to the xxSD draft:

 "A= greement on the type of serialization used is not in the scope of this docu= ment"

to show that we've thought about the pr= oblem of the negociation of type of serialization.

Or if there is a preferred serialization, like XML, mention it.
Or i= f the type of used serialization is hardwired into a given grid, say it.Or if all grids are supposed to support all types of serialization, say it= .

But my feeling is that currently this point is left in the dark.
Sorry in advance if this point is mentioned in the draft and I have missed= it. I tend to read things a bit quickly because of lack of time.

--
Catherine Pfeffer
--0015174c0cec8d45e70462a21ec2-- From cathypfeffer@gmail.com Wed Feb 11 02:50:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0863F3A67A4 for ; Wed, 11 Feb 2009 02:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTgFASRJBZtg for ; Wed, 11 Feb 2009 02:50:43 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id A39083A67EE for ; Wed, 11 Feb 2009 02:50:42 -0800 (PST) Received: by ewy14 with SMTP id 14so106407ewy.13 for ; Wed, 11 Feb 2009 02:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=NLBZgFL/rFvG8GkEnqsgJmuSUFPdy3cWCNG2z59uF90=; b=ZMDQ3D71HmABNrza9Qf9uBMYn/iIDC6Q8Izy2QAeWvF/iar7CLDalAGoa5yKn0eLFC xb8042WCfNX/jLOPtjrO0l0TVOrBN84SjkqMSjPFCrxfRTd66e6UqPHeKJajFHeWpyQm dFCt2RpXUz/hMiow5VrJMSkBxXUg0U0UNT694= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=j4OyyQmnS2biYGoblkrcci5KdCUXBX1e7WqK4VaV8oabSVKN2bXsjXXUHK6w4tKm9G VgzHuE4EfiYNAp+imy+xYS4cfINKap9gw9iEDVa4v5UURY90RhkUfuRqs1Xc52RDHJCp DL1K3ReyjzgV3Zx+HYaIr/Wvg0b+SRRBFxPFw= MIME-Version: 1.0 Received: by 10.210.76.4 with SMTP id y4mr819588eba.23.1234349444714; Wed, 11 Feb 2009 02:50:44 -0800 (PST) Date: Wed, 11 Feb 2009 11:50:44 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174bdf282e4ffe0462a26050 Subject: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 10:50:44 -0000 --0015174bdf282e4ffe0462a26050 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, The current xxSD draft is in no way related to virtual worlds and massively multiparty environments. That's rather strange for something coming out fro= m a (future) working group named "MMOX". As it is currently expressed, xxSD is very general and addresses the same problems of marshalling and demarshalling structured data like CORBA, COM+, UNO, D-Bus, Sun RPC, Web services, ... do. Even the examples in the draft are very generic and do not show a connotation to virtual worlds. xxSD does the job of marshalling and demarshalling structured data in a way that is much simpler, more flexible and more adapted to virtual worlds than these other protocols, but this might not be obvious to an external person reading the draft. I am fearing a "why are you reinventing the wheel?" concern. I propose to tighten the link to virtual words by specifying how typical virtual worlds data fit in the general principles expressed in the draft. We could add a section saying that : - a 3D vector is to be represented by an array of three reals, in the x, y= , z order - a 2D vector is to be represented by an array of three reals, in the x, y order (for hypothetical 2D virtual worlds, why not) - a rotation is expressed by a quaternion in the order X, Y, Z, S (or S, X= , Y, Z if we want to be maths-compatible and not linden labs-compatible) - say if this quaternion needs being normalized (X=C2=B2 + Y=C2=B2 + Z=C2= =B2 + S=C2=B2 =3D 1) or not. - etc... This would also spare another document/draft that would need to express these constraints ;-). My two cents. --=20 Catherine Pfeffer --0015174bdf282e4ffe0462a26050 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all,


The current xxSD draft is in no way related to virtual worlds and massi= vely multiparty environments. That's rather strange for something comin= g out from a (future) working group named "MMOX".

As it is= currently expressed, xxSD is very general and addresses the same problems = of marshalling and demarshalling structured data like CORBA, COM+, UNO, D-B= us, Sun RPC, Web services, ... do. Even the examples in the draft are very = generic and do not show a connotation to virtual worlds.

xxSD does the job of marshalling and demarshalling structured data in a= way that is much simpler, more flexible and more adapted to virtual worlds= than these other protocols, but this might not be obvious to an external p= erson reading the draft. I am fearing a "why are you reinventing the w= heel?" concern.

I propose to tighten the link to virtual words by specifying how typica= l virtual worlds data fit in the general principles expressed in the draft.=

We could add a section saying that :
 - a 3D vector is to b= e represented by an array of three reals, in the x, y, z order
 - a 2D vector is to be represented by an array of three reals, in the= x, y order (for hypothetical 2D virtual worlds, why not)
 - a rota= tion is expressed by a quaternion in the order X, Y, Z, S (or S, X, Y, Z if= we want to be maths-compatible and not linden labs-compatible)
 - say if this quaternion needs being normalized (X=C2=B2 + Y=C2=B2 + = Z=C2=B2 + S=C2=B2 =3D 1) or not.
 - etc...

This would also s= pare another document/draft that would need to express these constraints ;-= ).


My two cents.

--
Catherine Pfeffer
--0015174bdf282e4ffe0462a26050-- From cathypfeffer@gmail.com Wed Feb 11 02:54:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717573A63D3 for ; Wed, 11 Feb 2009 02:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcuQg5hT6CYs for ; Wed, 11 Feb 2009 02:54:45 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by core3.amsl.com (Postfix) with ESMTP id 023103A63D2 for ; Wed, 11 Feb 2009 02:54:43 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id j40so6960ugd.15 for ; Wed, 11 Feb 2009 02:54:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=aj0Wtzs4BM4zpz5HtJ7tyg1K/W/KvsJVLQsWp32ES0U=; b=t448/yF4iGqh4H/V9rxmy/l1UjAGfeCEVwAI9jYisf/fzhtBA5c3l54i9LR0T85SaU mrqbdGeiBgTtQHTLcbt1VpYvH2BOwF18nRx60OS/81MVEW1dyvShLjif3w6vwLb3AVCN T8IyV+Z5/X9a/gPSxmdr0xah2GNwyHkosujvw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=RPuFTyezl5JhxA162hL0sQu9jr8WkBoNpzTuKVqSuBFK0iEUItJZTRw3WF2u8q80Ht V/xYLtzVlEXekjDL6OZ8mq10vRw2dEFJztJ92+EoFXWQCQ7eixIqFDASQ1SwhoYibJPm ATEqE6LJ7pciFfuRxUuhe8lrnree5/DOdqbg0= MIME-Version: 1.0 Received: by 10.210.45.17 with SMTP id s17mr1009204ebs.74.1234349687150; Wed, 11 Feb 2009 02:54:47 -0800 (PST) Date: Wed, 11 Feb 2009 11:54:47 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174bdf10a198be0462a26e26 Subject: [mmox] Third and last proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 10:54:46 -0000 --0015174bdf10a198be0462a26e26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all, Someone asked "Why should LLIDL be described in a separate document ?" I'm relaying this question here. Best, P.S. in my messages, xxSD means "LLSD with a more vendor-neutral name, like VWSD". -- Catherine Pfeffer --0015174bdf10a198be0462a26e26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all,


Someone asked "Why should LLIDL be described in a s= eparate document ?"

I'm relaying this question here.

Best,

P.S. in my messages, xxSD means "LLSD with a more ve= ndor-neutral name, like VWSD".

--
Catherine Pfeffer
--0015174bdf10a198be0462a26e26-- From cathypfeffer@gmail.com Wed Feb 11 04:05:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 817143A6B55 for ; Wed, 11 Feb 2009 04:05:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2krSnY716Rc for ; Wed, 11 Feb 2009 04:05:01 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 88F273A67B4 for ; Wed, 11 Feb 2009 04:05:01 -0800 (PST) Received: by ewy14 with SMTP id 14so132005ewy.13 for ; Wed, 11 Feb 2009 04:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=K4NcRIgbEzcO9Q+mESL0QY+s2Yf2NmJMz3iRxxiQAMk=; b=QZuxEBOg8yx8v75Efm2pY6B+oveKOE7QrZWk8/nxBtbhR/DdpIAiGoevsBZ5zTHEJK r3o4cns8tq6xL88fyBEuFPr/uL/dTo+TcZBZcohSlSWizIFWsf22s0FOeDW7dN5dPStB DMixpR/9LjOQ3bX2vgPm/h6ddExaJdyY+I0Zo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ojdjUGVyu9piPDHLT1v0gsM9+dFQviRX9QRVXrMbLSHgjCWRb8xhMFjwq5o9Ou/va/ 7Houe/vurAbLabPGFDLxNlKPXSN9XXuTDcLsQ2RUOtZTcH6Vb2Hu1i181n66Dk3bvKVt OhU5lLghwQuIMUBq+6OLF/4MJjQ62iNZWr8y8= MIME-Version: 1.0 Received: by 10.210.104.20 with SMTP id b20mr5071912ebc.117.1234353904550; Wed, 11 Feb 2009 04:05:04 -0800 (PST) Date: Wed, 11 Feb 2009 13:05:04 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174be17202027b0462a36a12 Subject: [mmox] Yet another proposal for LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 12:05:02 -0000 --0015174be17202027b0462a36a12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi again, Someone asked my to forward this suggestion for enhancement; "32 bits data are not future-proof enough, they should be replaced with 64 bits" If my memories are correct, Infinity already gave some thoughts abour it during some informal conversation, but not on this list. I apologize in advance if that has already been proposed. -- Cathy --0015174be17202027b0462a36a12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi again,

Someone asked my to forward this suggestion for enhancemen= t;

"32 bits data are not future-proof enough, they should be re= placed with 64 bits"

If my memories are correct, Infinity alrea= dy gave some thoughts abour it during some informal conversation, but not o= n this list. I apologize in advance if that has already been proposed.

--
Cathy
--0015174be17202027b0462a36a12-- From imaze.rhiano@gmail.com Wed Feb 11 06:40:28 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 420623A68D7 for ; Wed, 11 Feb 2009 06:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTY-XEyzFQ7F for ; Wed, 11 Feb 2009 06:40:27 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 029393A6A24 for ; Wed, 11 Feb 2009 06:40:26 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so66234fgb.41 for ; Wed, 11 Feb 2009 06:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=h64029CEblZqdoWWO0qywO2HW2C6vLjk0D08TH/uoew=; b=f1u4Xh0i+rUK3GJPbUlwEAHzz1oJqueqz4imzMMogZqQELOedyhYI9HqfSwiK7osrn VlK4XS+7FlNQQAcStH3GEcoVA6714s+TE4aNow3swDIGgze+edZkJV3Y9UvRZj0OvVVm 8GcKzgAAXsBeybzy87jfWGWO8EqjtcI+yYSO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PFTqnoCERIKLBBdWQE3uckfflV9SRB9+omznUzH/UDgOVY8rrZo0vCTSt5ZK8CEs5o imVGer7Al6f3M6+f4K59cWrgBHLpXiwmpuGE6tesw+dgiVGbwapvjahMHLw7TkNlKt+6 JjWnNUJx2yfSJdseEQVp1MXHZox7m8ggSutEg= Received: by 10.86.51.2 with SMTP id y2mr711664fgy.2.1234363229404; Wed, 11 Feb 2009 06:40:29 -0800 (PST) Received: from ?192.168.0.100? (85-23-9-21-Karjasilta-TR1.suomi.net [85.23.9.21]) by mx.google.com with ESMTPS id l12sm787064fgb.1.2009.02.11.06.40.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Feb 2009 06:40:28 -0800 (PST) Message-ID: <4992E35B.5060200@gmail.com> Date: Wed, 11 Feb 2009 16:40:27 +0200 From: Imaze Rhiano User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mmox@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Third and last proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 14:40:28 -0000 Hi! Actually LLIDL is same document, but in different chapters and currently they seem to be separated entities - or LLIDL is sub-entity of LLSD. LLSD/xxSD/xxxx is currently just defining 11 types and conversions between types. Then in another chapter is described how LLSD data is serialized by LLIDL. Wouldn't it be more logical to combine these separated entities under single "simple abstract datatype and interface defination" language? I understand that one reason is that LLIDL is currently strongly coupled with RESTful architecture, but wouldn't it possible to expand it bit and allow it to be more architecture independent? For example by adding "component" concept: component assets_server { -> asset_request <- asset_response -> asset <- asset_id } or maybe even: component assets_server { asset_response request_asset( asset_request ); asset_id new_asset( asset ); } same as: %% assets_server -> asset_request <- asset_response %% assets_server -> asset <- asset_id I support Catherine's idea to have more virtual world oriented language. There should have - no must have common defination for 2D/3D vectors, rotations, meshes, animations and textures.Thought, these could also be separated extension for LLSD/xxxx. Whatever language we are going to use - and whatever we are going to call it - it is going to minor detail in big plan. Should we start slowly moving away from LLSD/xxxx and talk about scope of the MMOX - identify objects, components and interactions between VWs? My 0.015447594 Euros :) Catherine Pfeffer kirjoitti: > Hi all, > > > Someone asked "Why should LLIDL be described in a separate document ?" > > I'm relaying this question here. > > > Best, > > P.S. in my messages, xxSD means "LLSD with a more vendor-neutral name, > like VWSD". > > -- > Catherine Pfeffer > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From morgaine.dinova@googlemail.com Wed Feb 11 06:44:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9423A6A24 for ; Wed, 11 Feb 2009 06:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl+a41XN37FF for ; Wed, 11 Feb 2009 06:44:16 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id BB9B03A6935 for ; Wed, 11 Feb 2009 06:44:15 -0800 (PST) Received: by qyk4 with SMTP id 4so207609qyk.13 for ; Wed, 11 Feb 2009 06:44:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=f2g17wX4kRX5mYLKNG7FQSTOgmul3wUsB0mMzSw9YW0=; b=h99oqvhUjNNnDHodvYCB7JjsNxjZYO+MO0Lq3a1YthuOy4If5OTvhDzJvORsfKnDqa baxMe6ipkv5mp7zUZ11ayy7EcMpBBtBiysMZcLCp1jh12XtASbybDoXlF8yMQF5YRNfy hnj/TdgrUJPVPb5VOr8qIaPZoMHDfhGO+H2wI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=acfy7dMjFLfO0LhCw2GeXGH/kUDG6P+8SLQSPJPJ3cE3/nWsFcmsikfcQKflIBvfXc 0r3oazMnqIRMYH8hk2heIu9lYmN5NgQzB4u9TAG/Estvs+aUigIHp/ADQuHwgUM5KAx2 ack2hLgiJVsATRrHOqclrrvsLbiEI91OK6qp4= MIME-Version: 1.0 Received: by 10.224.45.76 with SMTP id d12mr489317qaf.158.1234363459463; Wed, 11 Feb 2009 06:44:19 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Feb 2009 14:44:19 +0000 Message-ID: From: Morgaine Dinova To: Catherine Pfeffer Content-Type: multipart/alternative; boundary=0015175cde2c8669e30462a5a357 Cc: mmox@ietf.org Subject: Re: [mmox] Proposal for small enhancement in the LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 14:44:17 -0000 --0015175cde2c8669e30462a5a357 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Catherine, some of the "omissions" you mention actually reflect a desirable property of specifications: Separation of Concerns. Every time that a document becomes more strongly associated with one problem domain, the less useful it becomes in others. If you employ generic formats then you can employ generic tools instead of having to create your own tools specific to your domain --- a great benefit. LLSD is an Abstract Data Type specification, but an ADT is not a protocol so you would not expect an ADT spec to discuss negotiation of serialization formats --- that belongs in the negotiation section of a wire protocol document. And while Virtual Worlds will make use of specific ADT structures and map their VW data onto them, the VW is merely a SPECIFIC USER of structures defined by the ADT, not an exclusive definer of the ADT as that would be leaking VW concepts into the ADT spec. (ADTs are "Abstract" by design and intent for reasons already mentioned.) In addition, Separation of Concerns is very strongly related to the idea of Decoupling which is so central to taming software engineering difficulties. If two documents describe different aspects of a system then you are quite likely to be able to change one without changing the other, which is much less likely if they are intertwined. This benefit of separation doesn't end with the documents either, but carries over to the corresponding implementations as well. Decoupling is A Good Thing. On the issue of "preferred serialization", this doesn't really hold together when you look at what it implies. If a system offers two alternative serializations then they need to be equivalent in all important respects or they're not actually alternatives at all. If they are true alternatives then this means that the system has implemented both fully, so why then would the spec express a preference? Which one is better is entirely dependent on the quality of individual implementations. For example, both XML and JSON implementations are available with a very broad spectrum of performances, and therefore declaring a preference for JSON as "usually" faster than XML could in practice be quite wrong. If you're going to offer multiple serializations then "ranking" them should not be prejudged. Morgaine. On Wed, Feb 11, 2009 at 10:32 AM, Catherine Pfeffer wrote: > Hi all, > > > I propose to add to the xxSD draft: > > "Agreement on the type of serialization used is not in the scope of this > document" > > to show that we've thought about the problem of the negociation of type of > serialization. > > Or if there is a preferred serialization, like XML, mention it. > Or if the type of used serialization is hardwired into a given grid, say > it. > Or if all grids are supposed to support all types of serialization, say it. > > But my feeling is that currently this point is left in the dark. > > Sorry in advance if this point is mentioned in the draft and I have missed > it. I tend to read things a bit quickly because of lack of time. > > -- > Catherine Pfeffer > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --0015175cde2c8669e30462a5a357 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Catherine, some of the "omissions" you mention actually reflect a= desirable property of specifications:  Separation of Concerns.  = Every time that a document becomes more strongly associated with one proble= m domain, the less useful it becomes in others.  If you employ generic= formats then you can employ generic tools instead of having to create your= own tools specific to your domain --- a great benefit.

LLSD is an Abstract Data Type specification, but an ADT is not a protoc= ol so you would not expect an ADT spec to discuss negotiation of serializat= ion formats --- that belongs in the negotiation section of a wire protocol = document.  And while Virtual Worlds will make use of specific ADT stru= ctures and map their VW data onto them, the VW is merely a SPECIFIC USER of= structures defined by the ADT, not an exclusive definer of the ADT as that= would be leaking VW concepts into the ADT spec.  (ADTs are "Abst= ract" by design and intent for reasons already mentioned.)

In addition, Separation of Concerns is very strongly related to the ide= a of Decoupling which is so central to taming software engineering difficul= ties.  If two documents describe different aspects of a system then yo= u are quite likely to be able to change one without changing the other, whi= ch is much less likely if they are intertwined.  This benefit of separ= ation doesn't end with the documents either, but carries over to the co= rresponding implementations as well.  Decoupling is A Good Thing.

On the issue of "preferred serialization", this doesn't r= eally hold together when you look at what it implies.  If a system off= ers two alternative serializations then they need to be equivalent in all i= mportant respects or they're not actually alternatives at all.  If= they are true alternatives then this means that the system has implemented= both fully, so why then would the spec express a preference?

Which one is better is entirely dependent on the quality of individual = implementations.  For example, both XML and JSON implementations are a= vailable with a very broad spectrum of performances, and therefore declarin= g a preference for JSON as "usually" faster than XML could in pra= ctice be quite wrong.  If you're going to offer multiple serializa= tions then "ranking" them should not be prejudged.

Morgaine.




On Wed, Feb 11,= 2009 at 10:32 AM, Catherine Pfeffer <cathypfeffer@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi all,


I propose to add to the xxSD draft:

 "A= greement on the type of serialization used is not in the scope of this docu= ment"

to show that we've thought about the pr= oblem of the negociation of type of serialization.

Or if there is a preferred serialization, like XML, mention it.
Or i= f the type of used serialization is hardwired into a given grid, say it.Or if all grids are supposed to support all types of serialization, say it= .

But my feeling is that currently this point is left in the dark.
Sorry in advance if this point is mentioned in the draft and I have missed= it. I tend to read things a bit quickly because of lack of time.

--
Catherine Pfeffer

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--0015175cde2c8669e30462a5a357-- From cathypfeffer@gmail.com Wed Feb 11 08:21:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D713F3A6816 for ; Wed, 11 Feb 2009 08:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E12JpxNVum2u for ; Wed, 11 Feb 2009 08:21:04 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 501523A6902 for ; Wed, 11 Feb 2009 08:21:04 -0800 (PST) Received: by ewy14 with SMTP id 14so227376ewy.13 for ; Wed, 11 Feb 2009 08:21:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=1shDSFlzw7GJPErKTpp0CTImsY78NmarR1do71dNh/A=; b=WqiQoSzVHiybZU0xlZufH5asOuF64ZnEx+sHw88k7J2UCK7fdFQeP3+lzZZ9rKwwHM C0rtS74HKFzKK9Nd+fVvpKGJQFVvwAEnDHEEUWaXJO8Ztu8AWKHFAeko1ETKcvD2+BDH xUDHAoA0seJhmJHrruqslXUeoiY4LoKohksWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cv0LGb05w9JO0j4/RljwWep0lI5Oxdx5SIv3XK9BFqxmyp2u56Tv6PgLrurnIFNbId xpZirzAREmGETXx7CcJDuDMD/sluvBTFIQfKr9RUpoIU+pToplZF1zyd3OUchnujh53e MI3eqfPTjmCa0/9QiDnKBcpqeDm8TAsPhodSg= MIME-Version: 1.0 Received: by 10.210.92.11 with SMTP id p11mr1632555ebb.2.1234369267676; Wed, 11 Feb 2009 08:21:07 -0800 (PST) Date: Wed, 11 Feb 2009 17:21:07 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c436cb8b7560462a6fd70 Subject: [mmox] Making a few things explicit X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 16:21:05 -0000 --0015174c436cb8b7560462a6fd70 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Catherine, some of the "omissions" you mention actually reflect a desirable > property of specifications: Separation of Concerns. Fine, but then it should be made clear in the spec: "Agreement on the type of serialization used between two communicating parties is not in the scope of this document" "How typical virtual virtual worlds data map into LLSD is beyond the scope of this document" "Exact transport mechanism (TCP, UDP, ...) used to transport the serialized data is not defined here" I think that could only clarify things. The remark about LLIDL not being in the same document was not relevant, that's what section 4 and appendix C are all about. Reading fast = understanding wrong, sorry. Also, writing in the spec a justification on why not using one of the existing IDL languages and marshalling/demarshalling protocols would not harm, IMHO. Reasons already invoked here include simplicity, versatility and adaptation to situations implied by massive multiparty environments. Just my two eurocents. -- Cathy --0015174c436cb8b7560462a6fd70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Catherine, some of the "omissions" you mention actually refl= ect a desirable
> property of specifications:  Separation of Con= cerns.

Fine, but then it should be made clear in the spec:

&= nbsp; "Agreement on the type of serialization used between two communi= cating parties is not in the scope of this document"

  "How typical virtual virtual worlds data map = into LLSD is beyond the scope of this document"

  "Ex= act transport mechanism (TCP, UDP, ...) used to transport the serialized da= ta is not defined here"

I think that could only clarify things.


The remark about LLI= DL not being in the same document was not relevant, that's what section= 4 and appendix C are all about. Reading fast =3D understanding wrong, sorr= y.


Also, writing in the spec a justification on why not using one of t= he existing IDL languages and marshalling/demarshalling protocols would not= harm, IMHO. Reasons already invoked here include simplicity, versatility a= nd adaptation to situations implied by massive multiparty environments.


Just my two eurocents.

--
Cathy
--0015174c436cb8b7560462a6fd70-- From cenji.neutra@gmail.com Wed Feb 11 08:24:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE1B3A6816 for ; Wed, 11 Feb 2009 08:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwdOmkBouJ2J for ; Wed, 11 Feb 2009 08:24:11 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id CA3813A6896 for ; Wed, 11 Feb 2009 08:24:10 -0800 (PST) Received: by qyk4 with SMTP id 4so319119qyk.13 for ; Wed, 11 Feb 2009 08:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=xBd/YWPqBZmbLNJ/XvX32bP5+WRGKRrA0ZRcBch3BPM=; b=RZvDSy62EP+Cxr/MBnPr6D2Vgxljc1PmW9K51sgtCppowNJ98Eg05WIF6nbCcOF4Xp LRc6SAbEMpiY0xgJWpO9kVIPKaYUlqDr8pSyCTgbe4hNkPSHhqtifykgvnhh1oEagyc3 8xKen8TDOiNrSOAG/lHZgw7MUn95lOXVIpVvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=g/nNII9TcNCLcaNVUvy9YqiWucCYaNw3BkiS74G0oDrPwo0SwpZmYxhYBzsKGEPY1B imW93mzYwJWIKMeuA/5TRPoAXi43lGic+0JNnnD64F178cxxxXAruO+evhuwjL/i3XCa YXD3ny66KWaYD2qnkBNw6PdMxuVssMGjifvEk= MIME-Version: 1.0 Received: by 10.224.54.141 with SMTP id q13mr670133qag.217.1234369453700; Wed, 11 Feb 2009 08:24:13 -0800 (PST) Date: Wed, 11 Feb 2009 11:24:13 -0500 Message-ID: From: Cenji Neutra To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Proposal for small enhancement in the LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 16:24:12 -0000 Morgaine, I'm not sure I agree with your statement that "LLSD is an Abstract Data Type specification", but perhaps I'm mistaken (not being 100% familiar with all the details of LLSD). It appears to me that LLSD is actually just an abstract syntax to represent data structured in a specific way (the concrete syntax being its rendering in XML, etc). The structure itself is almost identical to that represented by many other formats (e.g. JSON, IFF etc). To my mind, an ADT defines a both data, a set of constraints over that data and a set of operations to transform the data that maintain the constraints (for example, a list, queue, binary tree etc). Perhaps xxSD doesn't belong in any MMOX standard at all, except as being referenced as a preferred (or maintained) format for message exchange in some VW-specific protocols the standard defines. In that case it may need to be standardized elsewhere (though I'm not sure it adds sufficient additional benefits over its concrete serializations in XML or JSON to warrant that). Another possibility is that the MMOX standard doesn't mention xxSD at all, but simply defines a set of alternative serializations for messages (e.g. XML, JSON) that are constrained in such a way that they just happen to be valid serializations of LLSD. -Cenji (aka David). The abstract data structure represented by LLSD is identical to that represented by many other similar formats (e.g. JSON). I would characterize LLSD > Date: Wed, 11 Feb 2009 14:44:19 +0000 > From: Morgaine Dinova > Subject: Re: [mmox] Proposal for small enhancement in the LLSD draft > To: Catherine Pfeffer > Cc: mmox@ietf.org > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Catherine, some of the "omissions" you mention actually reflect a desirable > property of specifications: Separation of Concerns. Every time that a > document becomes more strongly associated with one problem domain, the less > useful it becomes in others. If you employ generic formats then you can > employ generic tools instead of having to create your own tools specific to > your domain --- a great benefit. > > LLSD is an Abstract Data Type specification, but an ADT is not a protocol so > you would not expect an ADT spec to discuss negotiation of serialization > formats --- that belongs in the negotiation section of a wire protocol > document. And while Virtual Worlds will make use of specific ADT structures > and map their VW data onto them, the VW is merely a SPECIFIC USER of > structures defined by the ADT, not an exclusive definer of the ADT as that > would be leaking VW concepts into the ADT spec. (ADTs are "Abstract" by > design and intent for reasons already mentioned.) > > In addition, Separation of Concerns is very strongly related to the idea of > Decoupling which is so central to taming software engineering difficulties. > If two documents describe different aspects of a system then you are quite > likely to be able to change one without changing the other, which is much > less likely if they are intertwined. This benefit of separation doesn't end > with the documents either, but carries over to the corresponding > implementations as well. Decoupling is A Good Thing. > > On the issue of "preferred serialization", this doesn't really hold together > when you look at what it implies. If a system offers two alternative > serializations then they need to be equivalent in all important respects or > they're not actually alternatives at all. If they are true alternatives > then this means that the system has implemented both fully, so why then > would the spec express a preference? > > Which one is better is entirely dependent on the quality of individual > implementations. For example, both XML and JSON implementations are > available with a very broad spectrum of performances, and therefore > declaring a preference for JSON as "usually" faster than XML could in > practice be quite wrong. If you're going to offer multiple serializations > then "ranking" them should not be prejudged. > > Morgaine. > From jack@martinelli.org Wed Feb 11 09:08:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D433A6943 for ; Wed, 11 Feb 2009 09:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.619 X-Spam-Level: * X-Spam-Status: No, score=1.619 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32cvSVZdnbp4 for ; Wed, 11 Feb 2009 09:08:19 -0800 (PST) Received: from 95228-web1.designerscience.com (unknown [72.32.122.42]) by core3.amsl.com (Postfix) with ESMTP id 9DF793A693C for ; Wed, 11 Feb 2009 09:08:19 -0800 (PST) Received: (qmail 16954 invoked from network); 11 Feb 2009 11:08:23 -0600 Received: from localhost (127.0.0.1) by localhost with SMTP; 11 Feb 2009 11:08:23 -0600 Received: from host-206-206-59-29.ns1.spro.net (host-206-206-59-29.ns1.spro.net [206.206.59.29]) by webmail.martinelli.org (Horde MIME library) with HTTP; Wed, 11 Feb 2009 11:08:23 -0600 Message-ID: <20090211110823.lc37csnclc88w4cg@webmail.martinelli.org> Date: Wed, 11 Feb 2009 11:08:23 -0600 From: jack@martinelli.org To: mmox@ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1) Subject: Re: [mmox] Serial X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:08:20 -0000 Abstract the serializable type so that other vendors may implement their own. Note that serialization may not even be required when moving an object from one local CPU to local another. 64 vs. 32 bit integers... this isn't an issue for XML but will be for binary streams. Again abstract integers can help here (also with big-endian probs too) From infinity@lindenlab.com Wed Feb 11 09:27:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0874E3A6B4D for ; Wed, 11 Feb 2009 09:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0d8jq8ZRdwV for ; Wed, 11 Feb 2009 09:27:11 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 3E4723A6B05 for ; Wed, 11 Feb 2009 09:27:11 -0800 (PST) Received: from longinus.local (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id DB0953DBC0A5; Wed, 11 Feb 2009 09:27:15 -0800 (PST) Message-ID: <49930A3F.2070806@lindenlab.com> Date: Wed, 11 Feb 2009 09:26:23 -0800 From: Meadhbh Hamrick Organization: Linden Research, Inc. User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------000308000803020407010109" Cc: mmox@ietf.org Subject: Re: [mmox] Yet another proposal for LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:27:12 -0000 This is a multi-part message in MIME format. --------------000308000803020407010109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit right. the answer is basically there are several systems / languages that currently don't support 64 bit efficiently. Python, for instance, does not support a 64 bit int. if you need an int with a width larger than 32 bits, you get an arbitrary lengthed bignum. by defining an int as 64 bits, you REQUIRE the use of bignums in Python (and I think PHP and ECMAScript) but not C/C++, C# or Java where you simply use longs. and PLEASE remember... WE DO NOT WANT TO ENSHRINE THE EXISTING SECOND LIFE PROTOCOL AS A STANDARD. our purpose is not to take the existing UDP message system, that does encode 64 bit values as a binary and create a protocol out of it. rather, we are hoping we can all learn from such mistakes and "do the right thing" in the future. so the question is... where do we need 64 bit ints, if we're not taking the existing SL protocol and standardizing it? and the sad reply is "we don't know cause we haven't worked out the protocol for all aspects of a virtual world yet." so we have a situation where a long int may or may not be useful in the future, but we know it will be detrimental to people using Python (and we think PHP and ECMAScript) and certainly people interested in working on mobile clients. this is the thought process the authors went through to decide the width of ints in the abstract type system. Catherine Pfeffer wrote: > Hi again, > > Someone asked my to forward this suggestion for enhancement; > > "32 bits data are not future-proof enough, they should be replaced > with 64 bits" > > If my memories are correct, Infinity already gave some thoughts abour > it during some informal conversation, but not on this list. I > apologize in advance if that has already been proposed. > > -- > Cathy > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --------------000308000803020407010109 Content-Type: text/x-vcard; charset=utf-8; name="infinity.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="infinity.vcf" YmVnaW46dmNhcmQNCmZuOk1lYWRoYmggSGFtcmljaw0KbjpIYW1yaWNrO01lYWRoYmgNCm9y ZzpMaW5kZW4gUmVzZWFyY2gsIEluYy47T3BlbiBQbGF0Zm9ybSBHcm91cA0KYWRyOjs7Ozs7 O1VTDQplbWFpbDtpbnRlcm5ldDppbmZpbml0eUBsaW5kZW5sYWIuY29tDQp0aXRsZTpTb2Z0 d2FyZSBBcmNoaXRlY3QNCngtbW96aWxsYS1odG1sOkZBTFNFDQp2ZXJzaW9uOjIuMQ0KZW5k OnZjYXJkDQoNCg== --------------000308000803020407010109-- From infinity@lindenlab.com Wed Feb 11 09:27:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 181C83A6B4D for ; Wed, 11 Feb 2009 09:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPg2UHbwygN2 for ; Wed, 11 Feb 2009 09:27:53 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 31DF03A657C for ; Wed, 11 Feb 2009 09:27:53 -0800 (PST) Received: from longinus.local (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id AEB923DBC0A5 for ; Wed, 11 Feb 2009 09:27:57 -0800 (PST) Message-ID: <49930A69.7090702@lindenlab.com> Date: Wed, 11 Feb 2009 09:27:05 -0800 From: Meadhbh Hamrick Organization: Linden Research, Inc. User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: mmox@ietf.org Content-Type: multipart/mixed; boundary="------------040506000206060203050204" Subject: [mmox] [Fwd: Re: Proposal for small enhancement in the LLSD draft] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:27:57 -0000 This is a multi-part message in MIME format. --------------040506000206060203050204 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit hmm... forgot to reply to the list as well. mea culpa. --------------040506000206060203050204 Content-Type: message/rfc822; name="Re: [mmox] Proposal for small enhancement in the LLSD draft.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: [mmox] Proposal for small enhancement in the LLSD draft."; filename*1="eml" Message-ID: <499306FF.6020600@lindenlab.com> Date: Wed, 11 Feb 2009 09:12:31 -0800 From: Meadhbh Hamrick Organization: Linden Research, Inc. User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Catherine Pfeffer Subject: Re: [mmox] Proposal for small enhancement in the LLSD draft References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------090002010708040101060409" This is a multi-part message in MIME format. --------------090002010708040101060409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hey Catherine... the spec as written was intended to be referenced by the VW/MMO specific specs, which is why there's no reference to a grid, virtual worlds or MMOs. and since we don't go into details in the LLSD spec about how virtual worlds will use the spec, we don't talk about what the default serialization would be. this is an example of the "provide mechanism but not policy." the spec will probably NEVER tell you which serialization schemes to use, but you're right, we should probably mention this somewhere so it doesn't look like we forgot about it. but yes... it's totally something that needs to be mentioned somewhere before there's a hope for interoperability. i believe our expectation was that each grid provider would be "liberal in what it accepted, but conservative in what it produced." realistically, each serialization has a specific case in which it is more appropriate. binary serialization is probably more appropriate for messages whose hosts care more about how long it takes to parse something than how readable the message is over the wire (perhaps for mobile clients or for inter-simulator messaging.) JSON serialization is probably more appropriate for someone who wants to do a lot of web client type work (like managing your inventory from a web page.) XML serialization is the "everything else" serialization, providing better readability over the wire and the ability to use commercial XML tools, but with the drawback that you're going to have a "angle bracket tax." so to be a little more detailed about interoperability... there are several standards out there where the spec defines the "what" and individuals using the spec define the "how it's used." X.509 and RTP come to mind as examples. There's a lot in PKIX and X.509 that Verisign will NEVER use. There's a different set of things that Entrust will NEVER use. But the features that each uses isn't defined in the PKIX spec, but in the certification policy and certification practice statement (sometimes) or in the interfaces each of those organizations provide for their customers. RTP (RFC3550) defines an abstract protocol for real-time data, but it's RFC3551 that defines how that protocol is used to provide VoIP like services. in other words... we're expecting people to define their own interoperability profiles where they list which serializations they'll produce and which they'll consume. but we didn't mention that anywhere and yes that is an oversight. i'm also noting that we haven't listed a mechanism for content negotiation. we define MIME types in the RFC, and we're talking about how we like to layer application protocol on top of HTTP, so maybe it's not unreasonable to add a section like "simple content negotiation for using LLSD in an HTTP environment." that would say something like... "if the client doesn't care what serialization it gets back, it SHOULD include the 'Accept: */*' header in the request. the server MAY return a status code 300 to indicate it won't make a decision on serialization for the user. if the client does have a preference, it should be listed in the Accept header. The server is REQUIRED to include a Content-Type header to identify the serialization used. If the server cannot produce the serialization requested by the client, the server MUST return a 406 error code." but honestly... we might want to put this in a different document, something like "the use of LLSD over HTTP" where we could discuss other issues like character sets used, content encodings (we think people like gzipped content, and we would like to produce it in a "standard" way.) and also.. we all should probably take a closer look at section 12 of RFC2616 before writing anything intended to be standardized. Catherine Pfeffer wrote: > Hi all, > > > I propose to add to the xxSD draft: > > "Agreement on the type of serialization used is not in the scope of > this document" > > to show that we've thought about the problem of the negociation of > type of serialization. > > Or if there is a preferred serialization, like XML, mention it. > Or if the type of used serialization is hardwired into a given grid, > say it. > Or if all grids are supposed to support all types of serialization, > say it. > > But my feeling is that currently this point is left in the dark. > > Sorry in advance if this point is mentioned in the draft and I have > missed it. I tend to read things a bit quickly because of lack of time. > > -- > Catherine Pfeffer > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --------------090002010708040101060409 Content-Type: text/x-vcard; charset=utf-8; name="infinity.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="infinity.vcf" YmVnaW46dmNhcmQNCmZuOk1lYWRoYmggSGFtcmljaw0KbjpIYW1yaWNrO01lYWRoYmgNCm9y ZzpMaW5kZW4gUmVzZWFyY2gsIEluYy47T3BlbiBQbGF0Zm9ybSBHcm91cA0KYWRyOjs7Ozs7 O1VTDQplbWFpbDtpbnRlcm5ldDppbmZpbml0eUBsaW5kZW5sYWIuY29tDQp0aXRsZTpTb2Z0 d2FyZSBBcmNoaXRlY3QNCngtbW96aWxsYS1odG1sOkZBTFNFDQp2ZXJzaW9uOjIuMQ0KZW5k OnZjYXJkDQoNCg== --------------090002010708040101060409-- --------------040506000206060203050204 Content-Type: text/x-vcard; charset=utf-8; name="infinity.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="infinity.vcf" YmVnaW46dmNhcmQNCmZuOk1lYWRoYmggSGFtcmljaw0KbjpIYW1yaWNrO01lYWRoYmgNCm9y ZzpMaW5kZW4gUmVzZWFyY2gsIEluYy47T3BlbiBQbGF0Zm9ybSBHcm91cA0KYWRyOjs7Ozs7 O1VTDQplbWFpbDtpbnRlcm5ldDppbmZpbml0eUBsaW5kZW5sYWIuY29tDQp0aXRsZTpTb2Z0 d2FyZSBBcmNoaXRlY3QNCngtbW96aWxsYS1odG1sOkZBTFNFDQp2ZXJzaW9uOjIuMQ0KZW5k OnZjYXJkDQoNCg== --------------040506000206060203050204-- From infinity@lindenlab.com Wed Feb 11 09:39:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D3B43A690A for ; Wed, 11 Feb 2009 09:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl2uDXShP6zM for ; Wed, 11 Feb 2009 09:39:03 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 83BD63A6782 for ; Wed, 11 Feb 2009 09:39:03 -0800 (PST) Received: from longinus.local (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 19DF23DBC0A5; Wed, 11 Feb 2009 09:39:08 -0800 (PST) Message-ID: <49930D07.10408@lindenlab.com> Date: Wed, 11 Feb 2009 09:38:15 -0800 From: Meadhbh Hamrick Organization: Linden Research, Inc. User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Imaze Rhiano References: <4992E35B.5060200@gmail.com> In-Reply-To: <4992E35B.5060200@gmail.com> Content-Type: multipart/mixed; boundary="------------040809070009060201030608" Cc: mmox@ietf.org Subject: Re: [mmox] Third and last proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:39:04 -0000 This is a multi-part message in MIME format. --------------040809070009060201030608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit LLSD is envisioned as an abstract type system that happens to be used by some people developing virtual worlds protocols. (the authors generally think of LLIDL as being part of the LLSD type system... so sometimes you'll hear us refer to both the LLSD abstract type system and LLIDL using the term LLSD.) the idea for separating it out into it's own document is we wanted to define LLSD independent of any virtual world protocol. OGP was always conceived of as being an "application layer protocol." that is... it is the protocol that two applications (like a space server and a simulator) speak to each other (not that we would want to enforce the concept of a space server as being distinct from a simulator, but it's just an example.) in the distant future there may be a time when someone would want to exchange OGP application layer protocol over different transports (like XMPP or even IIOP or BEEP or SMTP or carrier pigeon.) separating LLSD into it's own document makes this a lot easier. and yes.. you're free to create your own specification (VWSD) that includes concepts from LLSD or even references LLSD but adds the component language. -cheers -meadhbh Imaze Rhiano wrote: > Hi! > > Actually LLIDL is same document, but in different chapters and > currently they seem to be separated entities - or LLIDL is sub-entity > of LLSD. LLSD/xxSD/xxxx is currently just defining 11 types and > conversions between types. Then in another chapter is described how > LLSD data is serialized by LLIDL. Wouldn't it be more logical to > combine these separated entities under single "simple abstract > datatype and interface defination" language? I understand that one > reason is that LLIDL is currently strongly coupled with RESTful > architecture, but wouldn't it possible to expand it bit and allow it > to be more architecture independent? For example by adding "component" > concept: > > component assets_server > { > -> asset_request <- asset_response > -> asset <- asset_id > } > > or maybe even: > > component assets_server > { > asset_response request_asset( asset_request ); > asset_id new_asset( asset ); > } > > same as: > > %% assets_server -> asset_request <- asset_response > %% assets_server -> asset <- asset_id > > I support Catherine's idea to have more virtual world oriented > language. There should have - no must have common defination for 2D/3D > vectors, rotations, meshes, animations and textures.Thought, these > could also be separated extension for LLSD/xxxx. > > Whatever language we are going to use - and whatever we are going to > call it - it is going to minor detail in big plan. Should we start > slowly moving away from LLSD/xxxx and talk about scope of the MMOX - > identify objects, components and interactions between VWs? > > My 0.015447594 Euros :) > > Catherine Pfeffer kirjoitti: >> Hi all, >> >> >> Someone asked "Why should LLIDL be described in a separate document ?" >> >> I'm relaying this question here. >> >> >> Best, >> >> P.S. in my messages, xxSD means "LLSD with a more vendor-neutral >> name, like VWSD". >> >> -- >> Catherine Pfeffer >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --------------040809070009060201030608 Content-Type: text/x-vcard; charset=utf-8; name="infinity.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="infinity.vcf" begin:vcard fn:Meadhbh Hamrick n:Hamrick;Meadhbh org:Linden Research, Inc.;Open Platform Group adr:;;;;;;US email;internet:infinity@lindenlab.com title:Software Architect x-mozilla-html:FALSE version:2.1 end:vcard --------------040809070009060201030608-- From infinity@lindenlab.com Wed Feb 11 09:46:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FE93A6CE1 for ; Wed, 11 Feb 2009 09:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AbdjDzr9hTP for ; Wed, 11 Feb 2009 09:46:55 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id C16F83A6B95 for ; Wed, 11 Feb 2009 09:46:55 -0800 (PST) Received: from longinus.local (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 6B05A3DBC0A6; Wed, 11 Feb 2009 09:47:00 -0800 (PST) Message-ID: <49930EDF.4040701@lindenlab.com> Date: Wed, 11 Feb 2009 09:46:07 -0800 From: Meadhbh Hamrick Organization: Linden Research, Inc. User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------000501080309010306070800" Cc: mmox@ietf.org Subject: Re: [mmox] Making a few things explicit X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:46:56 -0000 This is a multi-part message in MIME format. --------------000501080309010306070800 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit good points all. the ietf defines two types of docs: technical standards and applicability statements. the existing LLSD draft is more the former, what we're talking about is more the latter. my sense is that the statements below shouldn't go into the spec itself, but into a related applicability statement. but yeah... it should be done. lemme spend a bit of time working on one. fwiw... there have been many informal discussions in the past about why we (Linden Lab) didn't use ASN.1 or XDR or JSON. most of these discussions have been in public places, but haven't been collated into a coherent explanation. i can't imagine trying to get LLSD published as an RFC without at least 10 more people asking the question... "why not ASN.1?" so yeah... that's something else that should be documented somewhere. but... we wanted to keep the motivation for the spec out of the spec, believing it would make a more readable document. -cheers -meadhbh Catherine Pfeffer wrote: > > Catherine, some of the "omissions" you mention actually reflect a > desirable > > property of specifications: Separation of Concerns. > > Fine, but then it should be made clear in the spec: > > "Agreement on the type of serialization used between two > communicating parties is not in the scope of this document" > > "How typical virtual virtual worlds data map into LLSD is beyond the > scope of this document" > > "Exact transport mechanism (TCP, UDP, ...) used to transport the > serialized data is not defined here" > > I think that could only clarify things. > > > The remark about LLIDL not being in the same document was not > relevant, that's what section 4 and appendix C are all about. Reading > fast = understanding wrong, sorry. > > > Also, writing in the spec a justification on why not using one of the > existing IDL languages and marshalling/demarshalling protocols would > not harm, IMHO. Reasons already invoked here include simplicity, > versatility and adaptation to situations implied by massive multiparty > environments. > > > Just my two eurocents. > > -- > Cathy > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --------------000501080309010306070800 Content-Type: text/x-vcard; charset=utf-8; name="infinity.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="infinity.vcf" YmVnaW46dmNhcmQNCmZuOk1lYWRoYmggSGFtcmljaw0KbjpIYW1yaWNrO01lYWRoYmgNCm9y ZzpMaW5kZW4gUmVzZWFyY2gsIEluYy47T3BlbiBQbGF0Zm9ybSBHcm91cA0KYWRyOjs7Ozs7 O1VTDQplbWFpbDtpbnRlcm5ldDppbmZpbml0eUBsaW5kZW5sYWIuY29tDQp0aXRsZTpTb2Z0 d2FyZSBBcmNoaXRlY3QNCngtbW96aWxsYS1odG1sOkZBTFNFDQp2ZXJzaW9uOjIuMQ0KZW5k OnZjYXJkDQoNCg== --------------000501080309010306070800-- From john.hurliman@intel.com Wed Feb 11 10:03:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268BC28C1C7 for ; Wed, 11 Feb 2009 10:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+jQ93gKVwFt for ; Wed, 11 Feb 2009 10:03:54 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 63B2A28C1A0 for ; Wed, 11 Feb 2009 10:03:54 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 11 Feb 2009 10:03:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,193,1233561600"; d="scan'208";a="109641525" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by azsmga001.ch.intel.com with ESMTP; 11 Feb 2009 10:03:58 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 11 Feb 2009 11:03:58 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Wed, 11 Feb 2009 11:03:57 -0700 Thread-Topic: [mmox] Serial Thread-Index: AcmMa1xOKAlNoPGUQ5aiUbBConmtRAAA4hGw Message-ID: <62BFE5680C037E4DA0B0A08946C0933D500EB61F@rrsmsx506.amr.corp.intel.com> References: <20090211110823.lc37csnclc88w4cg@webmail.martinelli.org> In-Reply-To: <20090211110823.lc37csnclc88w4cg@webmail.martinelli.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] Serial X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 18:03:55 -0000 It actually is a problem in XML. In the current spec, the omission of a 64-= bit integer type means 64-bit integers are stored as binary blobs. These en= d up as Base64 encoded data in the XML. Internally, you have slower access = to the larger integers due to typecasting (and possibly endian conversions,= depending on when you do the host to network order conversion). Over the w= ire, you have to go through Base64 encoding/decoding on top of the conversi= ons. John >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >jack@martinelli.org >Sent: Wednesday, February 11, 2009 9:08 AM >To: mmox@ietf.org >Subject: Re: [mmox] Serial > >Abstract the serializable type so that other vendors may implement their >own. > >Note that serialization may not even be required when moving an object >from one local CPU to local another. > >64 vs. 32 bit integers... this isn't an issue for XML but will be for >binary streams. Again abstract integers can help here (also with >big-endian probs too) > > > >_______________________________________________ >mmox mailing list >mmox@ietf.org >https://www.ietf.org/mailman/listinfo/mmox >=20 From markl@lindenlab.com Wed Feb 11 08:47:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2EA33A693C for ; Wed, 11 Feb 2009 08:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29tsv-3E8imB for ; Wed, 11 Feb 2009 08:47:02 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id E3C193A6B11 for ; Wed, 11 Feb 2009 08:47:02 -0800 (PST) Received: from 945battery-guestA-98.lindenlab.com (945battery-guestA-98.lindenlab.com [10.1.10.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 964121414001 for ; Wed, 11 Feb 2009 08:47:04 -0800 (PST) Message-Id: <1A437F8E-2A23-4F4C-B9D6-03D827BAB66F@lindenlab.com> From: Mark Lentczner To: mmox@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 08:47:02 -0800 References: X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 11 Feb 2009 10:04:17 -0800 Subject: Re: [mmox] LLSD -- Serialization Priority X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:25:08 -0000 I agree there is some ambiguity about what is the intent of having multiple serializations. I see several possible approaches: 1) We insist that all systems that accept LLSD implement all serializations. This leaves the choice up to the generator of the data. 2) We leave the choice up to the consumer of the data, and declare that all requests for LLSD must include some content type negotiation mechanism (such as in HTTP), and therefore all generators of LLSD must support all serializations. 3) One serialization is chosen to be "mandatory", the rest are optional. 4) No preference or requirement of support is stated. Working backwards: I don't support #4, because it doesn't ensure interoperability. It means different systems would have to advertise, out of band, what forms they accepted and generated. This strikes me of being like the early days of TIFF format, where complaint software would often be unable to read each others' files. Option #3 has the easiest interoperability story. But, unless there are major advantages to the non-required serializations, there will be little support for them. After all, once you've done the one required format, why do the others? We only have internal experience data to compare two of the formats, and not enough inter-system experience to know what would be best here. If experience shows that there is little practical difference between supporting the different serializations, then one might question why define alternatives. If we thought there would be many many more consumers of LLSD vs. producers, then #2 would make sense. However, it does place a burden of content negotiation on any protocol or process that transmits serialized LLSD. On the face of it, I think the premise here is false: I believe that all sub-systems in an OGP network will produce and consume LLSD with equal frequency. Another argument in favor of #2 is that parsing tends to be the more expensive operation in LLSD transport, and different implementations will favor different parsing solutions, often because they match the semantics and/or type systems of the implementation language. If there was a substantial expense in serializing LLSD, then #1 would allow implementations to choose what suits them best. However, this is also not borne out by experience: Generating these different serializations takes about the same amount of work. In fact they can all easily be generated by the same code using a common base class and having subclasses supply strings for structure and a few overridden routines for string escaping and such. My sense is that we will settle on either #3 or #2. Until then, I think we are all operating under approach #5: 5) Support for all serializations is mandatory. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From markl@lindenlab.com Wed Feb 11 09:01:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51BC028C204 for ; Wed, 11 Feb 2009 09:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viNUcPk-PCKX for ; Wed, 11 Feb 2009 09:01:40 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 9FD8428C21B for ; Wed, 11 Feb 2009 09:01:33 -0800 (PST) Received: from 945battery-guestA-98.lindenlab.com (945battery-guestA-98.lindenlab.com [10.1.10.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 5B08E3DBC0A3 for ; Wed, 11 Feb 2009 09:01:38 -0800 (PST) Message-Id: From: Mark Lentczner To: mmox@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 09:01:36 -0800 References: X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 11 Feb 2009 10:04:17 -0800 Subject: Re: [mmox] LLSD -- Virtual World specific? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:25:13 -0000 Catherine raised many good points about this that I'm sure we'll see again and again, so I hope we'll form consensus about this soon. On the one hand, it is indeed correct, LLSD and LLIDL, as they sit are not particularly virtual world specific. They could be used in many other contexts. Along with the upcoming OGP Base draft (I'm workin' on it...), it defines a general system for loosely coupled systems to interact over the Internet. On the other hand, LLSD (and the upcoming OGP Base) were motivated by the particular problem that Virtual World interoperability presented: Such a system requires specification of a large number of messages with rich semantics (it takes a large feature set to make a virtual world work), while at the same time requiring heavy resilience in the face of version compatibility. We reviewed the host of available options as a substrate for OGP, and found them lacking for the needs of virtual worlds: Those that supported large, rich APIs generally were very rigid about versioning or expected tightly coupled systems. Those that were designed for loosely coupled systems generally could only support very simple or generic semantics. This led us to create LLSD and LLIDL, which are admittedly more generic than virtual worlds, because other systems didn't fit the requirements well. That all said, we found numerous examples of APIs springing up on the web that could use this level of formalism for both data transport and specification. Most have home-spun data systems and use English and web pages for humans as the only specification language. Examples are Flickr API and Amazon's S3 and EC2. I wonder if we've hit something more broadly useful. I do think that we should, somewhere, define a larger set of composite data structures that will be used time and again in the context of virtual worlds. The examples you gave are dead on: 3D and 2D vectors and quaternions. There are also things like defining units for common scalars such as length, mass, acceleration, etc. I don't know if these belong in the LLSD draft or in another. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From markl@lindenlab.com Wed Feb 11 09:08:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C523A69F0 for ; Wed, 11 Feb 2009 09:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfdpVICkjTj8 for ; Wed, 11 Feb 2009 09:08:32 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 7F6563A67E6 for ; Wed, 11 Feb 2009 09:08:32 -0800 (PST) Received: from 945battery-guestA-98.lindenlab.com (945battery-guestA-98.lindenlab.com [10.1.10.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 46C1E3DBC0A4 for ; Wed, 11 Feb 2009 09:08:37 -0800 (PST) Message-Id: From: Mark Lentczner To: mmox@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 09:08:35 -0800 References: X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 11 Feb 2009 10:04:17 -0800 Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:25:18 -0000 The original design of LLSD had 64 bit integers. I argued for and switch the definition to 32 bit several years ago. My rationale was thus: It is the goal that LLSD data, when in memory and being operated on by a program, use native data types as much as possible. In particular, when LLSD data is in a scripting language such as Perl, Python or PHP, then the types should be the corresponding native data types. For Integers, choosing 32 bits means that integers are just plain, native integers in the vast majority of languages in use today. While many of these languages have facilities for dealing with larger integral numbers, they are often not uniform to work with, convenient or efficient by orders of magnitude than the native, 32 bit integers. There is also the fact that there has been little call for 64 bit integers in the interfaces and APIs that we have built for virtual worlds. The only place I know of in our entire protocol is an obvious design mistake: Two 32 bit integers are concatenated to form a 64 bit identifier. It would have been better to just treat the array of the two integers as the identifier. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From markl@lindenlab.com Wed Feb 11 09:22:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EECE03A657C for ; Wed, 11 Feb 2009 09:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMCWMpTb8OUE for ; Wed, 11 Feb 2009 09:22:11 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id D3A193A693C for ; Wed, 11 Feb 2009 09:22:11 -0800 (PST) Received: from 945battery-guestA-98.lindenlab.com (945battery-guestA-98.lindenlab.com [10.1.10.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id CF6CA3DBC0A5 for ; Wed, 11 Feb 2009 09:22:15 -0800 (PST) Message-Id: <70232964-FF5E-4C7A-A29A-22DD566FEACF@lindenlab.com> From: Mark Lentczner To: mmox@ietf.org In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1-515179918 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 09:22:13 -0800 References: X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 11 Feb 2009 10:04:17 -0800 Subject: Re: [mmox] LLSD -- What is LLIDL doing in there? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 17:25:24 -0000 --Apple-Mail-1-515179918 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit There are admittedly three distinct things in the draft, but I believe they are so closely related that they should remain together: 1) An abstract type system, called LLSD, which defines the data semantics and conversions so that when an API defines something like "has a string and an integer as arguments, and returns a bool and an array of reals", this has clear meaning even in the face of a variety of transports and implementation language choices. 2) Serializations so that communicating systems can pass LLSD typed data. 3) A specification language, called LLIDL, so that APIs can be specified clearly and concisely, both for humans and software. So the API definition above can be stated more precisely as: %% some_api -> { name: string, depth: int } <- { preprocessed: bool, soundings: [ real, ... ] } Please note that LLIDL does not specify the serialization formats, just the abstract interface in terms of the LLSD type system. I believe it takes all three of these things to ensure that interoperating virtual worlds can have a clear contract for what is being specified by the interfaces. In other standards, often the abstract type system and the serialization are collapsed into the definition of the wire protocol, and there is no specification language at all. Because we anticipate there being on the order of 200 APIs needed to create a full virtual world experience, having this more formal grounding seems appropriate. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com --Apple-Mail-1-515179918 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable There are admittedly three = distinct things in the draft, but I believe they are so closely related = that they should remain together:

1) An abstract type = system, called LLSD, which defines the data semantics and conversions so = that when an API defines something like "has a string and an integer as = arguments, and returns a bool and an array of reals", this has clear = meaning even in the face of a variety of transports = and implementation language choices.

2) Serializations so that communicating systems can pass LLSD typed = data.

3) A specification language, called = LLIDL, so that APIs can be specified clearly and concisely, both = for humans and software. So the API definition above can be stated = more precisely as:
%% = some_api
-> { name: string, = depth: int }
<- { = preprocessed: bool, soundings: [ real, ... ] = }

Please note that LLIDL does not = specify the serialization formats, just the abstract interface in terms = of the LLSD type system.

I believe it takes all = three of these things to ensure that interoperating virtual worlds can = have a clear contract for what is being specified by the interfaces. In = other standards, often the abstract type system and the serialization = are collapsed into the definition of the wire protocol, and = there is no specification language at all. Because we anticipate there = being on the order of 200 APIs needed to create a full virtual world = experience, having this more formal grounding seems = appropriate.

- Mark

Mark = Lentczner
Sr. Systems Architect
Technology = Integration
Linden Lab


Zero Linden




= --Apple-Mail-1-515179918-- From jwatte@gmail.com Wed Feb 11 10:40:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC4A28C0DF for ; Wed, 11 Feb 2009 10:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLQJQC7kbN5V for ; Wed, 11 Feb 2009 10:40:48 -0800 (PST) Received: from mail-fx0-f20.google.com (mail-fx0-f20.google.com [209.85.220.20]) by core3.amsl.com (Postfix) with ESMTP id 0E5F23A6D55 for ; Wed, 11 Feb 2009 10:40:44 -0800 (PST) Received: by fxm13 with SMTP id 13so1003002fxm.13 for ; Wed, 11 Feb 2009 10:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=j6SCa1CNc30u5BNIJZU46tZ9E4zQhbT2v2qd+4Ueol8=; b=AmsJrkrHnhOPwXieCqEk03mdubki8VncujUbHfanrHWrGyPhi3W9tEO9PQA445dQ+o TaE0AU/pJmtdpP7OIzjqCPJDeZQS4XSpWtFyE3k0WRBiG1PFtffRvAFSYCIMXrfW8AIF E3mGSS9LIHNi7ok/XESJFXLaJWCnUiIunrWcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=LO5ccB/LWtCyadsviZkasq3Q0OEz72O+41tLce1w/JA5/oVkCkTE1twruQnCrWAuAp +Ea6XgTvJWnf8524VNvNkuTsEr8jMF3IstjG4T1qKpEX2tQiZtoID5zaQReZ3dXPwepZ Tamn5h7gJ15KzBgIfUUHb27/YGr65d2JpN2tA= Received: by 10.223.106.69 with SMTP id w5mr262619fao.17.1234377648116; Wed, 11 Feb 2009 10:40:48 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id k28sm18510424ugd.43.2009.02.11.10.40.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Feb 2009 10:40:47 -0800 (PST) Message-ID: <49931BAA.10109@gmail.com> Date: Wed, 11 Feb 2009 10:40:42 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 18:40:49 -0000 Catherine Pfeffer wrote: > I propose to tighten the link to virtual words by specifying how > typical virtual worlds data fit in the general principles expressed in > the draft. What kinds of virtual world data do you imagine running through this system? Service requests? Service request responses? Mesh data? Animation data? Terrain data? Entity behavior? Multimedia streams? Real-time interactions? User input/control data? Network packet structure? Entity interactions? Database records? On-disk files? Each of these usage scenarios have different requirements. For example, as proposed, LLSD might be fine for service requests, but would probably fall short for something like terrain data (which requires indexing and random access). Sincerely, jw From dahliatrimble@gmail.com Wed Feb 11 10:47:00 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDA73A6D56 for ; Wed, 11 Feb 2009 10:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv3XxNYkSzyl for ; Wed, 11 Feb 2009 10:47:00 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id C229F3A6A88 for ; Wed, 11 Feb 2009 10:46:59 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so254861ana.4 for ; Wed, 11 Feb 2009 10:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=erY0mKJS0z3LfxnJH6k5rfssKdoBtgiVeSYmgR78AxI=; b=faQL048BFZi4IhFm+/b4eNZqbVi843e9pH4X5IW2jwCg13quWEh82hxElWcBj3i7Pv 8pO86IHbqH5yzjRmKJj3F+oqF0zvPrGYpmJl8Kru4I913wp9cSkzOtg/Q+CqxGLYmFPW J+kSJkOQj6fJkN7/g1OU/PkstDAox4sLfzAuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qpZrzvEDlpOIU35K3h/4YvRtCdLIiU0uvA7dhKejzIKWkxffONBR907kFHoQEGn1uc lwtB7D8jj9QddDS9hQmvbIqINHrafMANUb2kt5zpukTH+Ydvvwt+Ievfbtt2ZQIIXzhP 63LCEvL5Oa6nNgHwgzxtGTLiKiQj6wfnRFvSw= MIME-Version: 1.0 Received: by 10.142.173.14 with SMTP id v14mr2072504wfe.245.1234378021008; Wed, 11 Feb 2009 10:47:01 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Feb 2009 10:47:00 -0800 Message-ID: From: Dahlia Trimble To: Mark Lentczner Content-Type: multipart/alternative; boundary=000e0cd2e33475f7df0462a907a3 Cc: mmox@ietf.org Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 18:47:01 -0000 --000e0cd2e33475f7df0462a907a3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There are other uses of base 64 encoding of integers in LLSD in the LL protocol in the event queue. the "RegionHandle" and "GroupPowers" fields are base 64 encoded 64 bit unsigned, and "ParcelFlags" and "AuctionID" are 32 bit unsigned. Either of these may require endian conversion depending on architecture. In the case of "ParcelFlags" the original meaning of the data are further obscured as the meaning of each individual flag is not specified in the message. It would seem that rather specifying each flag as a boolean would serve to improve human readability, if human readability were indeed a goal. There may be other cases where similar encodings are used but I haven't seen them yet. On Wed, Feb 11, 2009 at 9:08 AM, Mark Lentczner wrote: > The original design of LLSD had 64 bit integers. I argued for and switch > the definition to 32 bit several years ago. My rationale was thus: > > It is the goal that LLSD data, when in memory and being operated on by a > program, use native data types as much as possible. In particular, when LLSD > data is in a scripting language such as Perl, Python or PHP, then the types > should be the corresponding native data types. > > For Integers, choosing 32 bits means that integers are just plain, native > integers in the vast majority of languages in use today. While many of these > languages have facilities for dealing with larger integral numbers, they are > often not uniform to work with, convenient or efficient by orders of > magnitude than the native, 32 bit integers. > > There is also the fact that there has been little call for 64 bit integers > in the interfaces and APIs that we have built for virtual worlds. The only > place I know of in our entire protocol is an obvious design mistake: Two 32 > bit integers are concatenated to form a 64 bit identifier. It would have > been better to just treat the array of the two integers as the identifier. > > - Mark > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --000e0cd2e33475f7df0462a907a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There are other uses of base 64 encoding of integers in LLSD in the LL prot= ocol in the event queue. the "RegionHandle" and "GroupPowers= " fields are base 64 encoded 64 bit unsigned, and  "Par= celFlags" and "AuctionID" are 32 bit unsigned. Either of the= se may require endian conversion depending on architecture. In the case of = "ParcelFlags" the original meaning of the data are further obscur= ed as the meaning of each individual flag is not specified in the message. = It would seem that rather specifying each flag as a boolean would serve to = improve human readability, if human readability were indeed a goal.

There may be other cases where similar encodings are used bu= t I haven't seen them yet.



On Wed, Feb 11, 2009 at 9:08 AM, Mark Lentczner <markl@lindenlab.com<= /a>> wrote:
The original design of LLSD had 64 bit inte= gers.  I argued for and switch the definition to 32 bit several years = ago. My rationale was thus:

It is the goal that LLSD data, when in memory and being operated on by a pr= ogram, use native data types as much as possible. In particular, when LLSD = data is in a scripting language such as Perl, Python or PHP, then the types= should be the corresponding native data types.

For Integers, choosing 32 bits means that integers are just plain, native i= ntegers in the vast majority of languages in use today. While many of these= languages have facilities for dealing with larger integral numbers, they a= re often not uniform to work with, convenient or efficient by orders of mag= nitude than the native, 32 bit integers.

There is also the fact that there has been little call for 64 bit integers = in the interfaces and APIs that we have built for virtual worlds. The only = place I know of in our entire protocol is an obvious design mistake: Two 32= bit integers are concatenated to form a 64 bit identifier. It would have b= een better to just treat the array of the two integers as the identifier.
       - Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

markl@lindenlab.co= m

Zero Linden
zero.linden= @secondlife.com





_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--000e0cd2e33475f7df0462a907a3-- From jwatte@gmail.com Wed Feb 11 11:07:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CE73A6929 for ; Wed, 11 Feb 2009 11:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDUgJy6OxG6M for ; Wed, 11 Feb 2009 11:07:26 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 98F9B3A6911 for ; Wed, 11 Feb 2009 11:07:26 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so405284yxm.49 for ; Wed, 11 Feb 2009 11:07:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4cBHWyTSW1fG2DfJ7FA9ictGSrX9nON6Jg0aukr1OEk=; b=qqDp9TNk+HDhQnwjHiartnGFQRZucidhS/B1Dng8DHuycYscbQmBZK/CvkeqWHBX9P Ta7DxxsDvVW0RGt5nfJsv1fxADn55xK+cHr+xgNiO2LKNhZfQ/l4Q8EE/57O44O6C+56 37pBJ7DNDxsjoM330EDsSrMbl1zxmUjvwqKLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jkhzTyhK/5bWmmRi5PJpZfgq4GXxPtexxiObr2JVDq1KYIOi+zLnzpp9VS2Rr/Mgog eMp00q+D6bEMYi0o83CBYtuJ8O51DIsXGtHwa78asRdC2JMqIRu3unRQgZMLmj5mQCCI 2ol/ipBlXcaEDjOFviqNP/STppEkg/G5YP0Mc= Received: by 10.100.143.14 with SMTP id q14mr3375087and.47.1234379250213; Wed, 11 Feb 2009 11:07:30 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c23sm17604620ana.52.2009.02.11.11.07.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Feb 2009 11:07:29 -0800 (PST) Message-ID: <499321F0.4010508@gmail.com> Date: Wed, 11 Feb 2009 11:07:28 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mark Lentczner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 19:07:27 -0000 Mark Lentczner wrote: > There is also the fact that there has been little call for 64 bit > integers in the interfaces and APIs that we have built for virtual > worlds. The only place I know of in our entire protocol is an obvious > design mistake: Two 32 bit integers are concatenated to form a 64 bit > identifier. It would have been better to just treat the array of the > two integers as the identifier. Our system uses 64-bit integers extensively for object identifiers, time step counters, virtual currency, and other such potentially "large" quantities. I would say that any forward-looking standard needs to support 64-bit integer domains. One way to solve this is to leave the max size of integers as something that's specified on a per-field basis, and/or support continuation encoding of integers (7 bits per byte; if high bit is set, shift and concatenate the next 7 bits. Repeat). Sincerely, jw From john.hurliman@intel.com Wed Feb 11 12:08:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C42D23A6981 for ; Wed, 11 Feb 2009 12:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvsEuAAcP7lH for ; Wed, 11 Feb 2009 12:08:53 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id CF1023A659C for ; Wed, 11 Feb 2009 12:08:53 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 11 Feb 2009 12:02:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,193,1233561600"; d="scan'208";a="489212798" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga001.jf.intel.com with ESMTP; 11 Feb 2009 12:08:45 -0800 Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by rrsmsx603.amr.corp.intel.com (10.31.0.57) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 11 Feb 2009 13:08:58 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Wed, 11 Feb 2009 13:08:57 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Wed, 11 Feb 2009 13:08:52 -0700 Thread-Topic: [mmox] LLSD -- 64 bit Integers Thread-Index: AcmMeShQEMXL1wULTzuESUbU1Ad0HwACxlvw Message-ID: <62BFE5680C037E4DA0B0A08946C0933D500EB791@rrsmsx506.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:08:55 -0000 The integer->binary->base64->binary->integer dance also happens for unsigne= d 32-bit integers in the current LLSD spec. While 64-bit integers might be = hand waved away as unnecessary, it seems odd to make 32-bit unsigned intege= rs so difficult to deal with. John >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Dahlia Trimble >Sent: Wednesday, February 11, 2009 10:47 AM >To: Mark Lentczner >Cc: mmox@ietf.org >Subject: Re: [mmox] LLSD -- 64 bit Integers > >There are other uses of base 64 encoding of integers in LLSD in the LL >protocol in the event queue. the "RegionHandle" and "GroupPowers" fields >are base 64 encoded 64 bit unsigned, and "ParcelFlags" and "AuctionID" >are 32 bit unsigned. Either of these may require endian conversion >depending on architecture. In the case of "ParcelFlags" the original >meaning of the data are further obscured as the meaning of each >individual flag is not specified in the message. It would seem that >rather specifying each flag as a boolean would serve to improve human >readability, if human readability were indeed a goal. > >There may be other cases where similar encodings are used but I haven't >seen them yet. > > > >On Wed, Feb 11, 2009 at 9:08 AM, Mark Lentczner >wrote: > > > The original design of LLSD had 64 bit integers. I argued for and >switch the definition to 32 bit several years ago. My rationale was >thus: > > It is the goal that LLSD data, when in memory and being operated >on by a program, use native data types as much as possible. In >particular, when LLSD data is in a scripting language such as Perl, >Python or PHP, then the types should be the corresponding native data >types. > > For Integers, choosing 32 bits means that integers are just plain, >native integers in the vast majority of languages in use today. While >many of these languages have facilities for dealing with larger integral >numbers, they are often not uniform to work with, convenient or >efficient by orders of magnitude than the native, 32 bit integers. > > There is also the fact that there has been little call for 64 bit >integers in the interfaces and APIs that we have built for virtual >worlds. The only place I know of in our entire protocol is an obvious >design mistake: Two 32 bit integers are concatenated to form a 64 bit >identifier. It would have been better to just treat the array of the two >integers as the identifier. > > - Mark > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > >=20 From infinity@lindenlab.com Wed Feb 11 12:13:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A934D3A6BF1 for ; Wed, 11 Feb 2009 12:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgww9HlGNpOD for ; Wed, 11 Feb 2009 12:13:58 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id BF35828C0DE for ; Wed, 11 Feb 2009 12:13:58 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id EBF893DBC0A5; Wed, 11 Feb 2009 12:14:02 -0800 (PST) Message-Id: <096325C6-CF87-4260-B0DA-B85D43D206B5@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: "Hurliman, John" In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D500EB791@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 12:14:01 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D500EB791@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:13:59 -0000 John, i'm not sure what you mean by this. assuming you're on a system that does 2's complement notation, the conversion between unsigned and signed is trivial. and there's nothing that REQUIREs you to represent a 32 bit integer as a binary, but if you want to, and then you want to serialize it, maintaining the ability to deserialize it seems like a "good thing." -cheers -meadhbh On Feb 11, 2009, at 12:08 PM, Hurliman, John wrote: > The integer->binary->base64->binary->integer dance also happens for > unsigned 32-bit integers in the current LLSD spec. While 64-bit > integers might be hand waved away as unnecessary, it seems odd to > make 32-bit unsigned integers so difficult to deal with. > > John > >> -----Original Message----- >> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On >> Behalf Of >> Dahlia Trimble >> Sent: Wednesday, February 11, 2009 10:47 AM >> To: Mark Lentczner >> Cc: mmox@ietf.org >> Subject: Re: [mmox] LLSD -- 64 bit Integers >> >> There are other uses of base 64 encoding of integers in LLSD in the >> LL >> protocol in the event queue. the "RegionHandle" and "GroupPowers" >> fields >> are base 64 encoded 64 bit unsigned, and "ParcelFlags" and >> "AuctionID" >> are 32 bit unsigned. Either of these may require endian conversion >> depending on architecture. In the case of "ParcelFlags" the original >> meaning of the data are further obscured as the meaning of each >> individual flag is not specified in the message. It would seem that >> rather specifying each flag as a boolean would serve to improve human >> readability, if human readability were indeed a goal. >> >> There may be other cases where similar encodings are used but I >> haven't >> seen them yet. >> >> >> >> On Wed, Feb 11, 2009 at 9:08 AM, Mark Lentczner >> wrote: >> >> >> The original design of LLSD had 64 bit integers. I argued for and >> switch the definition to 32 bit several years ago. My rationale was >> thus: >> >> It is the goal that LLSD data, when in memory and being operated >> on by a program, use native data types as much as possible. In >> particular, when LLSD data is in a scripting language such as Perl, >> Python or PHP, then the types should be the corresponding native data >> types. >> >> For Integers, choosing 32 bits means that integers are just plain, >> native integers in the vast majority of languages in use today. While >> many of these languages have facilities for dealing with larger >> integral >> numbers, they are often not uniform to work with, convenient or >> efficient by orders of magnitude than the native, 32 bit integers. >> >> There is also the fact that there has been little call for 64 bit >> integers in the interfaces and APIs that we have built for virtual >> worlds. The only place I know of in our entire protocol is an obvious >> design mistake: Two 32 bit integers are concatenated to form a 64 bit >> identifier. It would have been better to just treat the array of >> the two >> integers as the identifier. >> >> - Mark >> >> Mark Lentczner >> Sr. Systems Architect >> Technology Integration >> Linden Lab >> >> markl@lindenlab.com >> >> Zero Linden >> zero.linden@secondlife.com >> >> >> >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From echeslack@gmail.com Wed Feb 11 12:36:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD2A3A6B0B for ; Wed, 11 Feb 2009 12:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSv6JTuLRzxY for ; Wed, 11 Feb 2009 12:36:24 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 67D263A6AA1 for ; Wed, 11 Feb 2009 12:36:24 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so456654yxm.49 for ; Wed, 11 Feb 2009 12:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Gp2/UvLQ3NcVJMp6bXjDs91pXiQX9DcNbLBZKMwx3Dw=; b=AkSMRpUjd0tHKY28iYScLNzMNiHAbPLN9heAGdFUaqRrgEr6R/e5fGBiiMHccHeGyQ aGGpVNAvOl6fUSrGFOXnRr8aL0nWrk5tNMpxJ01tUQm/AtE9wE4NVFZUl6iei8GDm0hR OKH//SBIWDHdk1fMI6gPgdKuV9gV0UEjcal/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=BMhbgS5KUWx+FxxpfIIVCblCPK2S5XpPFPp8s/ojYUPDd0nOspMXyAr/TCMwYH1Ic4 hMRexm2Cj96d4jHqGMWY5ZGQxmlmSdbYJHZHnf6k3LpcETY6TR++SeJ3dL68m0ohClLi OO3KzU1vsRcG7AC7yNCoD4mzYxriKjabIRRN0= MIME-Version: 1.0 Sender: echeslack@gmail.com Received: by 10.220.77.18 with SMTP id e18mr1401vck.85.1234384587774; Wed, 11 Feb 2009 12:36:27 -0800 (PST) In-Reply-To: <499321F0.4010508@gmail.com> References: <499321F0.4010508@gmail.com> Date: Wed, 11 Feb 2009 12:36:27 -0800 X-Google-Sender-Auth: 65c4a8efc266ec64 Message-ID: From: Ewen Cheslack-Postava To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:37:12 -0000 On Wed, Feb 11, 2009 at 11:07 AM, Jon Watte wrote: > Mark Lentczner wrote: >> >> There is also the fact that there has been little call for 64 bit integers >> in the interfaces and APIs that we have built for virtual worlds. The only >> place I know of in our entire protocol is an obvious design mistake: Two 32 >> bit integers are concatenated to form a 64 bit identifier. It would have >> been better to just treat the array of the two integers as the identifier. > > Our system uses 64-bit integers extensively for object identifiers, time > step counters, virtual currency, and other such potentially "large" > quantities. I would say that any forward-looking standard needs to support > 64-bit integer domains. One way to solve this is to leave the max size of > integers as something that's specified on a per-field basis, and/or support > continuation encoding of integers (7 bits per byte; if high bit is set, > shift and concatenate the next 7 bits. Repeat). There are a number of places I'd expect 64 bit integers to be used as well, absolute time points being the most obvious. But beyond that, the reasoning given leads to a *very* slippery slope, the bottom of which is a "least common denominator" approach. In this case the issue is efficiency, but it seems to me that's a bad argument. Because python (or some other language) doesn't have native support for a feature, no language gets to use it. Now if I want to represent a time as a 64bit int, I have to use 2x32bit ints and do the munging manually. Suddenly my C++ code, which could handle this efficiently, also becomes inefficient. Either that or we end up with layers on top of the standard interface to provide these features/conversions for "free". But then we might as well include them in the standard since they'll be implemented for every language anyway. Computational efficiency isn't the only concern either. Currently there is only support for double precision in xxSD. Is this a foregone conclusion since Ruby doesn't support native single precision floats? This is a wire protocol, so there should be efficient encodings when necessary. Forcing double precision is wasteful in a lot of case, e.g. when specifying location information in a local frame (mesh vertices) or specifying normals, which shouldn't require so much precision. The barrier to entry should be "is this feature useful and does it have a reasonable implementation" not "can this feature be implemented efficiently everywhere." If you really need some service to be implemented very efficiently and it has to handle a lot of data which potentially uses 64bit ints, then maybe Python isn't the right language for that implementation. The intent isn't to start a language flame war, but to point out that if the desire is to have a fairly language agnostic type system, then specific considerations for specific languages generally shouldn't enter the equation. -Ewen > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From john.hurliman@intel.com Wed Feb 11 12:48:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F0C28C19D for ; Wed, 11 Feb 2009 12:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDZCKXskyHMy for ; Wed, 11 Feb 2009 12:48:43 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 8AB4928C120 for ; Wed, 11 Feb 2009 12:48:43 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 11 Feb 2009 12:42:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,194,1233561600"; d="scan'208";a="386021188" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga002.jf.intel.com with ESMTP; 11 Feb 2009 12:57:41 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Wed, 11 Feb 2009 13:48:48 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Wed, 11 Feb 2009 13:48:41 -0700 Thread-Topic: [mmox] LLSD -- 64 bit Integers Thread-Index: AcmMhUpAoHLSMiHIQC+SW6x6ZByEGwABBYUQ Message-ID: <62BFE5680C037E4DA0B0A08946C0933D500EB7CE@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D500EB791@rrsmsx506.amr.corp.intel.com> <096325C6-CF87-4260-B0DA-B85D43D206B5@lindenlab.com> In-Reply-To: <096325C6-CF87-4260-B0DA-B85D43D206B5@lindenlab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:48:44 -0000 If support for unsigned 32-bit integers is implemented by typecasting to a = signed integer, sending over the wire, and assuming the other side knows to= typecast back to an unsigned, that should be explicitly stated in the spec= . How do you state this in LLIDL? John >-----Original Message----- >From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com] >Sent: Wednesday, February 11, 2009 12:14 PM >To: Hurliman, John >Cc: mmox@ietf.org >Subject: Re: [mmox] LLSD -- 64 bit Integers > >John, i'm not sure what you mean by this. > >assuming you're on a system that does 2's complement notation, the >conversion between unsigned and signed is trivial. > >and there's nothing that REQUIREs you to represent a 32 bit integer as >a binary, but if you want to, and then you want to serialize it, >maintaining the ability to deserialize it seems like a "good thing." > >-cheers >-meadhbh > >On Feb 11, 2009, at 12:08 PM, Hurliman, John wrote: > >> The integer->binary->base64->binary->integer dance also happens for >> unsigned 32-bit integers in the current LLSD spec. While 64-bit >> integers might be hand waved away as unnecessary, it seems odd to >> make 32-bit unsigned integers so difficult to deal with. >> >> John >> >>> -----Original Message----- >>> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On >>> Behalf Of >>> Dahlia Trimble >>> Sent: Wednesday, February 11, 2009 10:47 AM >>> To: Mark Lentczner >>> Cc: mmox@ietf.org >>> Subject: Re: [mmox] LLSD -- 64 bit Integers >>> >>> There are other uses of base 64 encoding of integers in LLSD in the >>> LL >>> protocol in the event queue. the "RegionHandle" and "GroupPowers" >>> fields >>> are base 64 encoded 64 bit unsigned, and "ParcelFlags" and >>> "AuctionID" >>> are 32 bit unsigned. Either of these may require endian conversion >>> depending on architecture. In the case of "ParcelFlags" the original >>> meaning of the data are further obscured as the meaning of each >>> individual flag is not specified in the message. It would seem that >>> rather specifying each flag as a boolean would serve to improve human >>> readability, if human readability were indeed a goal. >>> >>> There may be other cases where similar encodings are used but I >>> haven't >>> seen them yet. >>> >>> >>> >>> On Wed, Feb 11, 2009 at 9:08 AM, Mark Lentczner >>> wrote: >>> >>> >>> The original design of LLSD had 64 bit integers. I argued for and >>> switch the definition to 32 bit several years ago. My rationale was >>> thus: >>> >>> It is the goal that LLSD data, when in memory and being operated >>> on by a program, use native data types as much as possible. In >>> particular, when LLSD data is in a scripting language such as Perl, >>> Python or PHP, then the types should be the corresponding native data >>> types. >>> >>> For Integers, choosing 32 bits means that integers are just plain, >>> native integers in the vast majority of languages in use today. While >>> many of these languages have facilities for dealing with larger >>> integral >>> numbers, they are often not uniform to work with, convenient or >>> efficient by orders of magnitude than the native, 32 bit integers. >>> >>> There is also the fact that there has been little call for 64 bit >>> integers in the interfaces and APIs that we have built for virtual >>> worlds. The only place I know of in our entire protocol is an obvious >>> design mistake: Two 32 bit integers are concatenated to form a 64 bit >>> identifier. It would have been better to just treat the array of >>> the two >>> integers as the identifier. >>> >>> - Mark >>> >>> Mark Lentczner >>> Sr. Systems Architect >>> Technology Integration >>> Linden Lab >>> >>> markl@lindenlab.com >>> >>> Zero Linden >>> zero.linden@secondlife.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >>> >> >>> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > From dahliatrimble@gmail.com Wed Feb 11 12:54:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D219F3A6BFD for ; Wed, 11 Feb 2009 12:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UyjJNwb7LgJs for ; Wed, 11 Feb 2009 12:54:33 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by core3.amsl.com (Postfix) with ESMTP id 425B83A6AB2 for ; Wed, 11 Feb 2009 12:54:32 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so376772ele.13 for ; Wed, 11 Feb 2009 12:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=5gYfA+ecb/Mq9JMjkkSGjv86k2ZIkajlzpLnIW4/8OQ=; b=TxXO0JUBvvAhD5PSToyEL40xcWSSb5Rh/eXiQHS1d2R3JiMcnbnyXHg9dYEB/sVPdR zNtotaU7kvDU5PVy09R4Uy52qo0eblYvqfHCMYpqSznjEVTRy54I7lLLa5gyTfc5SBLI mZuuATDbVOqeto/4l/bjY1QCyUOIEHmjFM1zg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BvzxM2oAvBGeFjPieub+uECDLLNtqqggTE+VTSFkriNrJCk4U5nnVjtO04giAO9Mjt xC0OhBmPyVtsH2DTyjP8Go1xS7y9N2OzIvhuEgE072vHmLduSSFs5fdpavb2xyFgDMsg cf3w2I9aoULSH4EW5t6w5HUd8BUrkRp7+csbo= MIME-Version: 1.0 Received: by 10.143.15.14 with SMTP id s14mr16482wfi.284.1234385676509; Wed, 11 Feb 2009 12:54:36 -0800 (PST) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D500EB7CE@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D500EB791@rrsmsx506.amr.corp.intel.com> <096325C6-CF87-4260-B0DA-B85D43D206B5@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D500EB7CE@rrsmsx506.amr.corp.intel.com> Date: Wed, 11 Feb 2009 12:54:36 -0800 Message-ID: From: Dahlia Trimble To: "mmox@ietf.org" Content-Type: multipart/alternative; boundary=001636e1fbd1c3a10b0462aacfc3 Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:54:34 -0000 --001636e1fbd1c3a10b0462aacfc3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Wouldn't the capacity to store an order of magnitude be lost by typecasting? I thought that was one of the reasons to consider using an unsigned int rather than a signed one. On Wed, Feb 11, 2009 at 12:48 PM, Hurliman, John wrote: > If support for unsigned 32-bit integers is implemented by typecasting to a > signed integer, sending over the wire, and assuming the other side knows to > typecast back to an unsigned, that should be explicitly stated in the spec. > How do you state this in LLIDL? > > John > > >-----Original Message----- > >From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com] > >Sent: Wednesday, February 11, 2009 12:14 PM > >To: Hurliman, John > >Cc: mmox@ietf.org > >Subject: Re: [mmox] LLSD -- 64 bit Integers > > > >John, i'm not sure what you mean by this. > > > >assuming you're on a system that does 2's complement notation, the > >conversion between unsigned and signed is trivial. > > > >and there's nothing that REQUIREs you to represent a 32 bit integer as > >a binary, but if you want to, and then you want to serialize it, > >maintaining the ability to deserialize it seems like a "good thing." > > > >-cheers > >-meadhbh > > > >On Feb 11, 2009, at 12:08 PM, Hurliman, John wrote: > > > >> The integer->binary->base64->binary->integer dance also happens for > >> unsigned 32-bit integers in the current LLSD spec. While 64-bit > >> integers might be hand waved away as unnecessary, it seems odd to > >> make 32-bit unsigned integers so difficult to deal with. > >> > >> John > >> > >>> -----Original Message----- > >>> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On > >>> Behalf Of > >>> Dahlia Trimble > >>> Sent: Wednesday, February 11, 2009 10:47 AM > >>> To: Mark Lentczner > >>> Cc: mmox@ietf.org > >>> Subject: Re: [mmox] LLSD -- 64 bit Integers > >>> > >>> There are other uses of base 64 encoding of integers in LLSD in the > >>> LL > >>> protocol in the event queue. the "RegionHandle" and "GroupPowers" > >>> fields > >>> are base 64 encoded 64 bit unsigned, and "ParcelFlags" and > >>> "AuctionID" > >>> are 32 bit unsigned. Either of these may require endian conversion > >>> depending on architecture. In the case of "ParcelFlags" the original > >>> meaning of the data are further obscured as the meaning of each > >>> individual flag is not specified in the message. It would seem that > >>> rather specifying each flag as a boolean would serve to improve human > >>> readability, if human readability were indeed a goal. > >>> > >>> There may be other cases where similar encodings are used but I > >>> haven't > >>> seen them yet. > >>> > >>> > >>> > >>> On Wed, Feb 11, 2009 at 9:08 AM, Mark Lentczner > >>> wrote: > >>> > >>> > >>> The original design of LLSD had 64 bit integers. I argued for and > >>> switch the definition to 32 bit several years ago. My rationale was > >>> thus: > >>> > >>> It is the goal that LLSD data, when in memory and being operated > >>> on by a program, use native data types as much as possible. In > >>> particular, when LLSD data is in a scripting language such as Perl, > >>> Python or PHP, then the types should be the corresponding native data > >>> types. > >>> > >>> For Integers, choosing 32 bits means that integers are just plain, > >>> native integers in the vast majority of languages in use today. While > >>> many of these languages have facilities for dealing with larger > >>> integral > >>> numbers, they are often not uniform to work with, convenient or > >>> efficient by orders of magnitude than the native, 32 bit integers. > >>> > >>> There is also the fact that there has been little call for 64 bit > >>> integers in the interfaces and APIs that we have built for virtual > >>> worlds. The only place I know of in our entire protocol is an obvious > >>> design mistake: Two 32 bit integers are concatenated to form a 64 bit > >>> identifier. It would have been better to just treat the array of > >>> the two > >>> integers as the identifier. > >>> > >>> - Mark > >>> > >>> Mark Lentczner > >>> Sr. Systems Architect > >>> Technology Integration > >>> Linden Lab > >>> > >>> markl@lindenlab.com > >>> > >>> Zero Linden > >>> zero.linden@secondlife.com > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> mmox mailing list > >>> mmox@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmox > >>> > >>> > >> > >>> > >> _______________________________________________ > >> mmox mailing list > >> mmox@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmox > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --001636e1fbd1c3a10b0462aacfc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Wouldn't the capacity to store an order of magnitude be lost by typecas= ting? I thought that was one of the reasons to consider using an unsigned i= nt rather than a signed one.

On Wed, Feb = 11, 2009 at 12:48 PM, Hurliman, John <john.hurliman@intel.com> wrote:
If support for unsigned 32-bit integers is = implemented by typecasting to a signed integer, sending over the wire, and = assuming the other side knows to typecast back to an unsigned, that should = be explicitly stated in the spec. How do you state this in LLIDL?

John

>-----Original Message-----
>From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com]
>Sent: Wednesday, February 11, 2009 12:14 PM
>To: Hurliman, John
>Cc: mmox@ietf.org
>Subject: Re: [mmox] LLSD -- 64 bit Integers
>
>John, i'm not sure what you mean by this.
>
>assuming you're on a system that does 2's complement notation, = the
>conversion between unsigned and signed is trivial.
>
>and there's nothing that REQUIREs you to represent a 32 bit integer= as
>a binary, but if you want to, and then you want to serialize it,
>maintaining the ability to deserialize it seems like a "good thing= ."
>
>-cheers
>-meadhbh
>
>On Feb 11, 2009, at 12:08 PM, Hurliman, John wrote:
>
>> The integer->binary->base64->binary->integer dance als= o happens for
>> unsigned 32-bit integers in the current LLSD spec. While 64-bit >> integers might be hand waved away as unnecessary, it seems odd to<= br> >> make 32-bit unsigned integers so difficult to deal with.
>>
>> John
>>
>>> -----Original Message-----
>>> From: mmox-bounces@ie= tf.org [mailto:mmox-bounces@ie= tf.org] On
>>> Behalf Of
>>> Dahlia Trimble
>>> Sent: Wednesday, February 11, 2009 10:47 AM
>>> To: Mark Lentczner
>>> Cc: mmox@ietf.org
>>> Subject: Re: [mmox] LLSD -- 64 bit Integers
>>>
>>> There are other uses of base 64 encoding of integers in LLSD i= n the
>>> LL
>>> protocol in the event queue. the "RegionHandle" and = "GroupPowers"
>>> fields
>>> are base 64 encoded 64 bit unsigned, and  "ParcelFla= gs" and
>>> "AuctionID"
>>> are 32 bit unsigned. Either of these may require endian conver= sion
>>> depending on architecture. In the case of "ParcelFlags&qu= ot; the original
>>> meaning of the data are further obscured as the meaning of eac= h
>>> individual flag is not specified in the message. It would seem= that
>>> rather specifying each flag as a boolean would serve to improv= e human
>>> readability, if human readability were indeed a goal.
>>>
>>> There may be other cases where similar encodings are used but = I
>>> haven't
>>> seen them yet.
>>>
>>>
>>>
>>> On Wed, Feb 11, 2009 at 9:08 AM, Mark Lentczner <markl@lindenlab.com>
>>> wrote:
>>>
>>>
>>>     The original design of LLSD had 64 bit integers.=  I argued for and
>>> switch the definition to 32 bit several years ago. My rational= e was
>>> thus:
>>>
>>>     It is the goal that LLSD data, when in memory an= d being operated
>>> on by a program, use native data types as much as possible. In=
>>> particular, when LLSD data is in a scripting language such as = Perl,
>>> Python or PHP, then the types should be the corresponding nati= ve data
>>> types.
>>>
>>>     For Integers, choosing 32 bits means that intege= rs are just plain,
>>> native integers in the vast majority of languages in use today= . While
>>> many of these languages have facilities for dealing with large= r
>>> integral
>>> numbers, they are often not uniform to work with, convenient o= r
>>> efficient by orders of magnitude than the native, 32 bit integ= ers.
>>>
>>>     There is also the fact that there has been littl= e call for 64 bit
>>> integers in the interfaces and APIs that we have built for vir= tual
>>> worlds. The only place I know of in our entire protocol is an = obvious
>>> design mistake: Two 32 bit integers are concatenated to form a= 64 bit
>>> identifier. It would have been better to just treat the array = of
>>> the two
>>> integers as the identifier.
>>>
>>>            - Mark
>>>
>>>     Mark Lentczner
>>>     Sr. Systems Architect
>>>     Technology Integration
>>>     Linden Lab
>>>
>>>     markl@lin= denlab.com
>>>
>>>     Zero Linden
>>>     ze= ro.linden@secondlife.com
>>>
>>>
>>>
>>>
>>>
>>>     _______________________________________________<= br> >>>     mmox mailing list
>>>     mmox@ietf.org
>>>     https://www.ietf.org/mailman/listinfo/mmox
>>>
>>>
>>
>>>
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox

>
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--001636e1fbd1c3a10b0462aacfc3-- From dwl@us.ibm.com Wed Feb 11 13:02:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823723A680E; Wed, 11 Feb 2009 13:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usy5neOUqz54; Wed, 11 Feb 2009 13:02:01 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 053533A67F0; Wed, 11 Feb 2009 13:01:57 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1BKxw4i016043; Wed, 11 Feb 2009 15:59:58 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1BL21qF178136; Wed, 11 Feb 2009 16:02:01 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n1BL21vW010478; Wed, 11 Feb 2009 16:02:01 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n1BL21t1010473; Wed, 11 Feb 2009 16:02:01 -0500 In-Reply-To: To: Ewen Cheslack-Postava MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Wed, 11 Feb 2009 16:02:00 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/11/2009 16:02:00, Serialize complete at 02/11/2009 16:02:00 Content-Type: multipart/alternative; boundary="=_alternative 00738A1A8525755A_=" Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:02:02 -0000 This is a multipart message in MIME format. --=_alternative 00738A1A8525755A_= Content-Type: text/plain; charset="US-ASCII" I think Ewen's posited ground rule feels right. The presence or absence of a native 64 bit type in a specific language is a very weak reason to support it in a wire format intended to be language independent. Further, per comments from several others, if we're doing this with native types and possible type casting in various ways, we need the wire format to be quite unambiguous about signed, unsigned, and so on. Ambiguity has no place at all in this sort of specification, the fact that questions about sign bits showed up today, is a hint to be careful on that. - David W. Levine ~ Zha Ewry (ISL) Ewen Cheslack-Postava Sent by: mmox-bounces@ietf.org 02/11/2009 03:36 PM To Jon Watte cc mmox@ietf.org Subject Re: [mmox] LLSD -- 64 bit Integers On Wed, Feb 11, 2009 at 11:07 AM, Jon Watte wrote: > Mark Lentczner wrote: >> >> There is also the fact that there has been little call for 64 bit integers >> in the interfaces and APIs that we have built for virtual worlds. The only >> place I know of in our entire protocol is an obvious design mistake: Two 32 >> bit integers are concatenated to form a 64 bit identifier. It would have >> been better to just treat the array of the two integers as the identifier. > > Our system uses 64-bit integers extensively for object identifiers, time > step counters, virtual currency, and other such potentially "large" > quantities. I would say that any forward-looking standard needs to support > 64-bit integer domains. One way to solve this is to leave the max size of > integers as something that's specified on a per-field basis, and/or support > continuation encoding of integers (7 bits per byte; if high bit is set, > shift and concatenate the next 7 bits. Repeat). There are a number of places I'd expect 64 bit integers to be used as well, absolute time points being the most obvious. But beyond that, the reasoning given leads to a *very* slippery slope, the bottom of which is a "least common denominator" approach. In this case the issue is efficiency, but it seems to me that's a bad argument. Because python (or some other language) doesn't have native support for a feature, no language gets to use it. Now if I want to represent a time as a 64bit int, I have to use 2x32bit ints and do the munging manually. Suddenly my C++ code, which could handle this efficiently, also becomes inefficient. Either that or we end up with layers on top of the standard interface to provide these features/conversions for "free". But then we might as well include them in the standard since they'll be implemented for every language anyway. Computational efficiency isn't the only concern either. Currently there is only support for double precision in xxSD. Is this a foregone conclusion since Ruby doesn't support native single precision floats? This is a wire protocol, so there should be efficient encodings when necessary. Forcing double precision is wasteful in a lot of case, e.g. when specifying location information in a local frame (mesh vertices) or specifying normals, which shouldn't require so much precision. The barrier to entry should be "is this feature useful and does it have a reasonable implementation" not "can this feature be implemented efficiently everywhere." If you really need some service to be implemented very efficiently and it has to handle a lot of data which potentially uses 64bit ints, then maybe Python isn't the right language for that implementation. The intent isn't to start a language flame war, but to point out that if the desire is to have a fairly language agnostic type system, then specific considerations for specific languages generally shouldn't enter the equation. -Ewen > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --=_alternative 00738A1A8525755A_= Content-Type: text/html; charset="US-ASCII"
I think Ewen's posited ground rule feels right. The presence or absence of a native 64 bit type in a specific language is a very weak reason to support it in a wire format intended to be language independent.
Further, per comments from several others, if we're doing this with native types and possible type casting in various ways, we need the wire format to be quite unambiguous about signed, unsigned, and so on. Ambiguity has no place at all in this sort of specification, the fact that questions about sign bits showed up today, is a hint to be careful on that.

- David W. Levine
~ Zha Ewry (ISL)




Ewen Cheslack-Postava <ewencp@gmail.com>
Sent by: mmox-bounces@ietf.org

02/11/2009 03:36 PM

To
Jon Watte <jwatte@gmail.com>
cc
mmox@ietf.org
Subject
Re: [mmox] LLSD -- 64 bit Integers





On Wed, Feb 11, 2009 at 11:07 AM, Jon Watte <jwatte@gmail.com> wrote:
> Mark Lentczner wrote:
>>
>> There is also the fact that there has been little call for 64 bit integers
>> in the interfaces and APIs that we have built for virtual worlds. The only
>> place I know of in our entire protocol is an obvious design mistake: Two 32
>> bit integers are concatenated to form a 64 bit identifier. It would have
>> been better to just treat the array of the two integers as the identifier.
>
> Our system uses 64-bit integers extensively for object identifiers, time
> step counters, virtual currency, and other such potentially "large"
> quantities. I would say that any forward-looking standard needs to support
> 64-bit integer domains. One way to solve this is to leave the max size of
> integers as something that's specified on a per-field basis, and/or support
> continuation encoding of integers (7 bits per byte; if high bit is set,
> shift and concatenate the next 7 bits. Repeat).

There are a number of places I'd expect 64 bit integers to be used as
well, absolute time points being the most obvious.

But beyond that, the reasoning given leads to a *very* slippery slope,
the bottom of which is a "least common denominator" approach.  In this
case the issue is efficiency, but it seems to me that's a bad
argument.  Because python (or some other language) doesn't have native
support for a feature, no language gets to use it.  Now if I want to
represent a time as a 64bit int, I have to use 2x32bit ints and do the
munging manually.  Suddenly my C++ code, which could handle this
efficiently, also becomes inefficient.  Either that or we end up with
layers on top of the standard interface to provide these
features/conversions for "free".  But then we might as well include
them in the standard since they'll be implemented for every language
anyway.

Computational efficiency isn't the only concern either.  Currently
there is only support for double precision in xxSD.  Is this a
foregone conclusion since Ruby doesn't support native single precision
floats?  This is a wire protocol, so there should be efficient
encodings when necessary.  Forcing double precision is wasteful in a
lot of case, e.g. when specifying location information in a local
frame (mesh vertices) or specifying normals, which shouldn't require
so much precision.

The barrier to entry should be "is this feature useful and does it
have a reasonable implementation" not "can this feature be implemented
efficiently everywhere."  If you really need some service to be
implemented very efficiently and it has to handle a lot of data which
potentially uses 64bit ints, then maybe Python isn't the right
language for that implementation.  The intent isn't to start a
language flame war, but to point out that if the desire is to have a
fairly language agnostic type system, then specific considerations for
specific languages generally shouldn't enter the equation.

-Ewen

>
> Sincerely,
>
> jw
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--=_alternative 00738A1A8525755A_=-- From infinity@lindenlab.com Wed Feb 11 13:46:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A20D28C100 for ; Wed, 11 Feb 2009 13:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDC0XYgSfOBN for ; Wed, 11 Feb 2009 13:46:17 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 613D828C0D7 for ; Wed, 11 Feb 2009 13:46:17 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id A95903DBC0A3; Wed, 11 Feb 2009 13:46:21 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Dahlia Trimble In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-3-531026881 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 11 Feb 2009 13:46:20 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D500EB791@rrsmsx506.amr.corp.intel.com ><096325C6-CF87-4260-B0DA-B85D43D206B5@lindenlab.com><62BFE5680C037E4DA0B0A08946C0933D500EB7CE@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:46:18 -0000 --Apple-Mail-3-531026881 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit no, it isn't. On Feb 11, 2009, at 12:54 PM, Dahlia Trimble wrote: > Wouldn't the capacity to store an order of magnitude be lost by > typecasting? I thought that was one of the reasons to consider using > an unsigned int rather than a signed one. > > On Wed, Feb 11, 2009 at 12:48 PM, Hurliman, John > wrote: > If support for unsigned 32-bit integers is implemented by > typecasting to a signed integer, sending over the wire, and assuming > the other side knows to typecast back to an unsigned, that should be > explicitly stated in the spec. How do you state this in LLIDL? > > John > > >-----Original Message----- > >From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com] > >Sent: Wednesday, February 11, 2009 12:14 PM > >To: Hurliman, John > >Cc: mmox@ietf.org > >Subject: Re: [mmox] LLSD -- 64 bit Integers > > > >John, i'm not sure what you mean by this. > > > >assuming you're on a system that does 2's complement notation, the > >conversion between unsigned and signed is trivial. > > > >and there's nothing that REQUIREs you to represent a 32 bit integer > as > >a binary, but if you want to, and then you want to serialize it, > >maintaining the ability to deserialize it seems like a "good thing." > > > >-cheers > >-meadhbh > > > >On Feb 11, 2009, at 12:08 PM, Hurliman, John wrote: > > > >> The integer->binary->base64->binary->integer dance also happens for > >> unsigned 32-bit integers in the current LLSD spec. While 64-bit > >> integers might be hand waved away as unnecessary, it seems odd to > >> make 32-bit unsigned integers so difficult to deal with. > >> > >> John > >> > >>> -----Original Message----- > >>> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On > >>> Behalf Of > >>> Dahlia Trimble > >>> Sent: Wednesday, February 11, 2009 10:47 AM > >>> To: Mark Lentczner > >>> Cc: mmox@ietf.org > >>> Subject: Re: [mmox] LLSD -- 64 bit Integers > >>> > >>> There are other uses of base 64 encoding of integers in LLSD in > the > >>> LL > >>> protocol in the event queue. the "RegionHandle" and "GroupPowers" > >>> fields > >>> are base 64 encoded 64 bit unsigned, and "ParcelFlags" and > >>> "AuctionID" > >>> are 32 bit unsigned. Either of these may require endian conversion > >>> depending on architecture. In the case of "ParcelFlags" the > original > >>> meaning of the data are further obscured as the meaning of each > >>> individual flag is not specified in the message. It would seem > that > >>> rather specifying each flag as a boolean would serve to improve > human > >>> readability, if human readability were indeed a goal. > >>> > >>> There may be other cases where similar encodings are used but I > >>> haven't > >>> seen them yet. > >>> > >>> > >>> > >>> On Wed, Feb 11, 2009 at 9:08 AM, Mark Lentczner > > >>> wrote: > >>> > >>> > >>> The original design of LLSD had 64 bit integers. I argued > for and > >>> switch the definition to 32 bit several years ago. My rationale > was > >>> thus: > >>> > >>> It is the goal that LLSD data, when in memory and being > operated > >>> on by a program, use native data types as much as possible. In > >>> particular, when LLSD data is in a scripting language such as > Perl, > >>> Python or PHP, then the types should be the corresponding native > data > >>> types. > >>> > >>> For Integers, choosing 32 bits means that integers are just > plain, > >>> native integers in the vast majority of languages in use today. > While > >>> many of these languages have facilities for dealing with larger > >>> integral > >>> numbers, they are often not uniform to work with, convenient or > >>> efficient by orders of magnitude than the native, 32 bit integers. > >>> > >>> There is also the fact that there has been little call for > 64 bit > >>> integers in the interfaces and APIs that we have built for virtual > >>> worlds. The only place I know of in our entire protocol is an > obvious > >>> design mistake: Two 32 bit integers are concatenated to form a > 64 bit > >>> identifier. It would have been better to just treat the array of > >>> the two > >>> integers as the identifier. > >>> > >>> - Mark > >>> > >>> Mark Lentczner > >>> Sr. Systems Architect > >>> Technology Integration > >>> Linden Lab > >>> > >>> markl@lindenlab.com > >>> > >>> Zero Linden > >>> zero.linden@secondlife.com > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> mmox mailing list > >>> mmox@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmox > >>> > >>> > >> > >>> > >> _______________________________________________ > >> mmox mailing list > >> mmox@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmox > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-3-531026881 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable no, it = isn't.

On Feb 11, 2009, at 12:54 PM, Dahlia Trimble = wrote:

Wouldn't the capacity to store an order of magnitude be = lost by typecasting? I thought that was one of the reasons to consider = using an unsigned int rather than a signed one.

On Wed, Feb 11, 2009 at 12:48 PM, Hurliman, John = <john.hurliman@intel.com> wrote:
If support for = unsigned 32-bit integers is implemented by typecasting to a signed = integer, sending over the wire, and assuming the other side knows to = typecast back to an unsigned, that should be explicitly stated in the = spec. How do you state this in LLIDL?

= John

= >-----Original Message-----
>From: Meadhbh Hamrick (Infinity) = [mailto:infinity@lindenlab.com]
= >Sent: Wednesday, February 11, 2009 12:14 PM
>To: Hurliman, John
= >Cc: mmox@ietf.org
>Subject: = Re: [mmox] LLSD -- 64 bit Integers
>
>John, i'm not sure what = you mean by this.
>
>assuming you're on a system that does 2's = complement notation, the
>conversion between unsigned and signed is = trivial.
>
>and there's nothing that REQUIREs you to represent a = 32 bit integer as
>a binary, but if you want to, and then you want = to serialize it,
>maintaining the ability to deserialize it seems = like a "good thing."
>
>-cheers
>-meadhbh
>
>On Feb = 11, 2009, at 12:08 PM, Hurliman, John wrote:
>
>> The = integer->binary->base64->binary->integer dance also happens for
>> = unsigned 32-bit integers in the current LLSD spec. While 64-bit
>> = integers might be hand waved away as unnecessary, it seems odd to
>> = make 32-bit unsigned integers so difficult to deal with.
>>
>> = John
>>
>>> -----Original Message-----
>>> From: mmox-bounces@ietf.org = [mailto:mmox-bounces@ietf.org] On
= >>> Behalf Of
>>> Dahlia Trimble
>>> Sent: Wednesday, February = 11, 2009 10:47 AM
>>> To: Mark Lentczner
>>> Cc: mmox@ietf.org
>>> Subject: Re: = [mmox] LLSD -- 64 bit Integers
>>>
>>> There are other uses of = base 64 encoding of integers in LLSD in the
>>> LL
>>> protocol = in the event queue. the "RegionHandle" and "GroupPowers"
>>> = fields
>>> are base 64 encoded 64 bit unsigned, and =  "ParcelFlags" and
>>> "AuctionID"
>>> are 32 bit unsigned. = Either of these may require endian conversion
>>> depending on = architecture. In the case of "ParcelFlags" the original
>>> meaning = of the data are further obscured as the meaning of each
>>> = individual flag is not specified in the message. It would seem that
= >>> rather specifying each flag as a boolean would serve to improve = human
>>> readability, if human readability were indeed a goal.
= >>>
>>> There may be other cases where similar encodings are used = but I
>>> haven't
>>> seen them yet.
>>>
>>>
>>>
= >>> On Wed, Feb 11, 2009 at 9:08 AM, Mark Lentczner <markl@lindenlab.com>
>>> = wrote:
>>>
>>>
>>>     The original design of LLSD = had 64 bit integers.  I argued for and
>>> switch the = definition to 32 bit several years ago. My rationale was
>>> = thus:
>>>
>>>     It is the goal that LLSD data, when = in memory and being operated
>>> on by a program, use native data = types as much as possible. In
>>> particular, when LLSD data is in a = scripting language such as Perl,
>>> Python or PHP, then the types = should be the corresponding native data
>>> types.
>>>
>>> =     For Integers, choosing 32 bits means that integers are = just plain,
>>> native integers in the vast majority of languages in = use today. While
>>> many of these languages have facilities for = dealing with larger
>>> integral
>>> numbers, they are often not = uniform to work with, convenient or
>>> efficient by orders of = magnitude than the native, 32 bit integers.
>>>
>>>   =   There is also the fact that there has been little call for 64 = bit
>>> integers in the interfaces and APIs that we have built for = virtual
>>> worlds. The only place I know of in our entire protocol = is an obvious
>>> design mistake: Two 32 bit integers are = concatenated to form a 64 bit
>>> identifier. It would have been = better to just treat the array of
>>> the two
>>> integers as = the identifier.
>>>
>>>           =  - Mark
>>>
>>>     Mark Lentczner
>>>   =   Sr. Systems Architect
>>>     Technology = Integration
>>>     Linden Lab
>>>
>>>   =   markl@lindenlab.com
= >>>
>>>     Zero Linden
>>>     zero.linden@secondlife.com<= br> >>>
>>>
>>>
>>>
>>>
>>>     = _______________________________________________
>>>     = mmox mailing list
>>>     mmox@ietf.org
>>>     https://www.ietf.org/mailman/listinfo/mmox
= >>>
>>>
>>
>>>
>> = _______________________________________________
>> mmox mailing = list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
=
>
_______________________________________________
mmox = mailing list
mmox@ietf.org
= https://www.ietf.org/mailman/listinfo/mmox
=

= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mmox

= --Apple-Mail-3-531026881-- From cathypfeffer@gmail.com Wed Feb 11 15:12:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CFFC3A68FA for ; Wed, 11 Feb 2009 15:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M14J4DboMY-t for ; Wed, 11 Feb 2009 15:12:22 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id D92CC3A68E5 for ; Wed, 11 Feb 2009 15:12:21 -0800 (PST) Received: by ewy14 with SMTP id 14so373207ewy.13 for ; Wed, 11 Feb 2009 15:12:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=0pEYZU26XUlfXSeXVr52YrvZrPHhMwOqsUmWWXoTEiU=; b=NDvfKmtUKfxgqPufOhCfF2MHeni/1iXfrmaPAhaJ5hyilCfrDduVTLnjUuv14JrnJ5 Og0wWFF7n0RsLeX7hiIpSXwHWaQc04d798/6gPe15UzjE5nMKDLJXGqQ7W3esonzWU1a kboZwROypQw+Z0SeHZEVoUW+1TTJ8TbQQu0KM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=I+cHiduokzKJiqDV5UNrt/T17I7M2uOuzUSgbeaCgC3DlDkZnmaBIkKCGL3GTn2Ibf pJpIFPNldjF3jiQnLT+Ig5KUhkhDMzc63mwCP+JWdXHnTYY+LpUJOV/YEuJGkU0JRbfa K3lpmDc4Bh5Uonynw8HMOJj9tGmgbDhS6nQJ4= MIME-Version: 1.0 Received: by 10.210.54.19 with SMTP id c19mr117681eba.168.1234393944846; Wed, 11 Feb 2009 15:12:24 -0800 (PST) Date: Thu, 12 Feb 2009 00:12:24 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c3e549871040462acbc2c Subject: [mmox] data types: consensus? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:12:23 -0000 --0015174c3e549871040462acbc2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Zha said: >Ambiguity has >no place at all in this sort of specification, the fact that questions >about sign bits showed up today, is a hint to be careful on that. The "obvious" solution seems to do what programming languages have now done for decades: integer 32 bit unsigned integer 32 bit long integer 64 bit long unsigned integer 64 bit float single double float double I know that's 6 types instead of two, but isn't there a big win in terms of scalability, better definition of data types, and also of fine-tuning the future standard, so that we won't use more bandwidth than necessary? [ Names like int32, uint32, etc would be okay too. ] [ I'm saying "float" and not "real" because, mathematically, "real" was incorrect ] -- Cathy --0015174c3e549871040462acbc2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Zha said:
>Ambiguity has
>no place at all in this sort of spec= ification, the fact that questions
>about sign bits showed up today,= is a hint to be careful on that.

The "obvious&qu= ot; solution seems to do what programming languages have now done for decad= es:

integer          &nbs= p;            &= nbsp;    32 bit
unsigned integer    &= nbsp;        32 bit
long integer = ;            &n= bsp;      64 bit
long unsigned integer &nb= sp;   64 bit

float      &nbs= p;            &= nbsp;            sin= gle
double float          &nb= sp;         double

I know th= at's 6 types instead of two, but isn't there a big win in terms of = scalability, better definition of data types, and also of fine-tuning the f= uture standard, so that we won't use more bandwidth than necessary?

[ Names like int32, uint32, etc would be okay too. ]

[ I'm s= aying "float" and not "real" because, mathematically, &= quot;real" was incorrect ]

--
Cathy
--0015174c3e549871040462acbc2c-- From jwatte@gmail.com Wed Feb 11 15:20:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030783A682F for ; Wed, 11 Feb 2009 15:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.533 X-Spam-Level: X-Spam-Status: No, score=-1.533 tagged_above=-999 required=5 tests=[AWL=1.066, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+NJKja7TaH8 for ; Wed, 11 Feb 2009 15:20:31 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 2E6D93A67CF for ; Wed, 11 Feb 2009 15:20:30 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so357468ana.4 for ; Wed, 11 Feb 2009 15:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xv5sBQV+R9PZmIZC6w/qXD+6C5vkn7TBOEEhy8SaMPs=; b=A9IWX4Ozrv/ocvjG8mep2ePABhOVma6AYyRAche2jwby9UT53xFnB+m6+7RJP5bTtk gc1AbRUq2kVoyqUMM2UICVk8MPT9lEarl5DHsM9oFiPXvRvEnrIa0fo+ZYd0A/3Atl6p sLV2oJiI0KC5PrwO+LB4Aw2fkfCba2hdGLOBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Mv2jnp6jH1tRBmq2n5zXtlF+D3UMWtMolNjlD/zgGWCWTZV+WST+A2RDmhTwbXlX3i Gb3jrcfKTkanw4qir7JdvJ9ktU39Ap3okNh4qGCYS3qFfAGHWpNksTjt0q4/ifCOxvcb A6VNlviaGVvz27aYroRXtFlrXDXe176CwsxfE= Received: by 10.100.143.17 with SMTP id q17mr393601and.29.1234394435116; Wed, 11 Feb 2009 15:20:35 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c37sm9860446ana.2.2009.02.11.15.20.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Feb 2009 15:20:34 -0800 (PST) Message-ID: <49935D40.5040002@gmail.com> Date: Wed, 11 Feb 2009 15:20:32 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "mmox@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mmox] data types: consensus? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:20:32 -0000 Catherine Pfeffer wrote: > integer 32 bit > unsigned integer 32 bit > long integer 64 bit > long unsigned integer 64 bit > > float single > double float double If we actually care about size and efficiency, wouldn't we want to specify number of bits, and signed-ness, on a per-field basis? E g, if you're enumerating "cardinal directions" in 3D, then there are exactly 26 of those, and 5 unsigned bits ought to be enough. If the argument is that specifying a number of bits up front would cause short-sighted lock-in, then wouldn't the answer to that argument would be to make every integer potentially 64 bits, and encoded using a variable-length encoding? Sincerely, jw From dwl@us.ibm.com Wed Feb 11 18:01:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8113A67F6; Wed, 11 Feb 2009 18:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.765 X-Spam-Level: X-Spam-Status: No, score=-5.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1zY0QAL4dyo; Wed, 11 Feb 2009 18:01:33 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id B54363A6B1F; Wed, 11 Feb 2009 18:01:32 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1C1xanq028574; Wed, 11 Feb 2009 20:59:36 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1C21afU193832; Wed, 11 Feb 2009 21:01:37 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1C21adM014752; Wed, 11 Feb 2009 21:01:36 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1C21a2m014747; Wed, 11 Feb 2009 21:01:36 -0500 In-Reply-To: To: Catherine Pfeffer MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Wed, 11 Feb 2009 21:01:36 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/11/2009 21:01:35, Serialize complete at 02/11/2009 21:01:35 Content-Type: multipart/alternative; boundary="=_alternative 000B22018525755B_=" Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] data types: consensus? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 02:01:34 -0000 This is a multipart message in MIME format. --=_alternative 000B22018525755B_= Content-Type: text/plain; charset="US-ASCII" Sigh... The obvious, of corse, is anything but, when you look at enough programming languages. Python, Javascript, Ruby, and a number of other languages do things on the order of "A Fixnum holds Integer values that can be represented in a native machine word (minus 1 bit). This effectively means that the maximum range of a Fixnum value depends on the architecture of the system on which the code is executing." The moment you drop a 64 bit int into a ruby integer on *many* platforms, it will end up in a"bignum" with the corresponding performance pain. Python does similar things. I'm really not happy about saying things like "Sure we can define all six, but if you use the two 64 bit ones, about 1/4 of the platforms out there will howl in pain at the performance coast." I'd like to say, "Well, its 2009, 64 Bit integers are pretty common" But, are they common enough? - David ~ Zha Catherine Pfeffer Sent by: mmox-bounces@ietf.org 02/11/2009 06:12 PM To mmox@ietf.org cc Subject [mmox] data types: consensus? Zha said: >Ambiguity has >no place at all in this sort of specification, the fact that questions >about sign bits showed up today, is a hint to be careful on that. The "obvious" solution seems to do what programming languages have now done for decades: integer 32 bit unsigned integer 32 bit long integer 64 bit long unsigned integer 64 bit float single double float double I know that's 6 types instead of two, but isn't there a big win in terms of scalability, better definition of data types, and also of fine-tuning the future standard, so that we won't use more bandwidth than necessary? [ Names like int32, uint32, etc would be okay too. ] [ I'm saying "float" and not "real" because, mathematically, "real" was incorrect ] -- Cathy_______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --=_alternative 000B22018525755B_= Content-Type: text/html; charset="US-ASCII"
Sigh... The obvious, of corse, is anything but, when you look at enough programming languages.  Python, Javascript, Ruby, and a number of other languages do things on the order of  "A Fixnum holds Integer values that can be represented in a native machine word (minus 1 bit). This effectively means that the maximum range of a Fixnum value depends on the architecture of the system on which the code is executing." The moment you drop a 64 bit int into a ruby integer on *many* platforms, it will end up in a"bignum" with the corresponding performance pain. Python does similar things.

I'm really not happy about saying things like "Sure we can define all six, but if you use the two 64 bit ones, about 1/4 of the platforms out there will howl in pain at the performance coast." I'd like to say,  "Well, its 2009, 64 Bit integers are pretty common" But, are they common enough?

- David
~ Zha





Catherine Pfeffer <cathypfeffer@gmail.com>
Sent by: mmox-bounces@ietf.org

02/11/2009 06:12 PM

To
mmox@ietf.org
cc
Subject
[mmox] data types: consensus?





Zha said:
>Ambiguity has
>no place at all in this sort of specification, the fact that questions
>about sign bits showed up today, is a hint to be careful on that.

The "obvious" solution seems to do what programming languages have now done for decades:

integer                            32 bit
unsigned integer             32 bit
long integer                    64 bit
long unsigned integer     64 bit

float                                single
double float                    double

I know that's 6 types instead of two, but isn't there a big win in terms of scalability, better definition of data types, and also of fine-tuning the future standard, so that we won't use more bandwidth than necessary?

[ Names like int32, uint32, etc would be okay too. ]

[ I'm saying "float" and not "real" because, mathematically, "real" was incorrect ]

--
Cathy_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--=_alternative 000B22018525755B_=-- From morgaine.dinova@googlemail.com Wed Feb 11 19:05:43 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7733A6916 for ; Wed, 11 Feb 2009 19:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ai7K1L7m4Ro for ; Wed, 11 Feb 2009 19:05:42 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 9ECD23A69B9 for ; Wed, 11 Feb 2009 19:05:42 -0800 (PST) Received: by qyk4 with SMTP id 4so771171qyk.13 for ; Wed, 11 Feb 2009 19:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=JFIl8rFhP4Vf1MKq7f4iswGAmvJzuPqjayBeeKkSW0g=; b=nQnXM0gREHLbZqqsWBsgRJMSI1ix54B+hWoKbfE3sBprP+gEflTG5NYqL98Ed/A8vb o6llYmMrUarIZyuZyurYPzoQxT53QCxZkBEeYh1MUmIkQX1leo0EPyPnDme6JCHqFGg+ HkqNyRLorcVKMw5mJNg/jZ5t8zArVU52+kZ0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y3WjI9WQnGxDO1wMRt6EFCZK7ZqRv2hx1GSMsCIYQuHFKBd4/sAyqq9DzLWRKERaap +qXiHL+ngQG/lNHo4y+7bUUr8OaGYxtTHoOhm74HkOFAp/bedsKg6WSb20WEs14yGIww 42ocNL7AcZqXf+sxeIlO8OR1Vh+SMFImUtm3Y= MIME-Version: 1.0 Received: by 10.224.54.75 with SMTP id p11mr326768qag.208.1234407946342; Wed, 11 Feb 2009 19:05:46 -0800 (PST) In-Reply-To: <49930A69.7090702@lindenlab.com> References: <49930A69.7090702@lindenlab.com> Date: Thu, 12 Feb 2009 03:05:46 +0000 Message-ID: From: Morgaine Dinova To: Meadhbh Hamrick Content-Type: multipart/alternative; boundary=0015175cdef22652680462afff48 Cc: mmox@ietf.org Subject: Re: [mmox] [Fwd: Re: Proposal for small enhancement in the LLSD draft] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 03:05:43 -0000 --0015175cdef22652680462afff48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 11, 2009 at 5:27 PM, Meadhbh Hamrick wrote: > > but honestly... we might want to put this in a different document, > something like "the use of LLSD over HTTP" where we could discuss other > issues like character sets used, content encodings (we think people like > gzipped content, and we would like to produce it in a "standard" way.) and > also.. we all should probably take a closer look at section 12 of RFC2616 > before writing anything intended to be standardized. > > Yes, that would be exactly right. The document on Structured Data would be the wrong place for it. Options negotiation is a completely different concern from the definition of data and serializations. I'd go further and suggest that the three alternative serializations should be defined in separate documents too (or maybe as external Annexes to the main spec), otherwise adding a new serialization will require updating the original specification document, which is a bad thing. We've already identified here a fourth serialization that will be desired very strongly, which is Google Protocol Buffers, so this is an immediate requirement rather than a hypothetical one. On that note, the draft Structurd Data spec needs "Binary" serialization to be renamed to something less generic, since Protocol Buffers is a binary serialization as well. Morgaine. --0015175cdef22652680462afff48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 11, 2009 at 5:27 PM, Meadhbh= Hamrick <in= finity@lindenlab.com> wrote:

but honestly... we might want to put this in a different document, somethin= g like "the use of LLSD over HTTP" where we could discuss other i= ssues like character sets used, content encodings (we think people like gzi= pped content, and we would like to produce it in a "standard" way= .) and also.. we all should probably take a closer look at section 12 of RF= C2616 before writing anything intended to be standardized.

Yes, that would be exactly right.  The document= on Structured Data would be the wrong place for it.  Options negotiat= ion is a completely different concern from the definition of data and seria= lizations.

I'd go further and suggest that the three alternative serialization= s should be defined in separate documents too (or maybe as external Annexes= to the main spec), otherwise adding a new serialization will require updat= ing the original specification document, which is a bad thing.  We'= ;ve already identified here a fourth serialization that will be desired ver= y strongly, which is Google Protocol Buffers, so this is an immediate requi= rement rather than a hypothetical one.

On that note, the draft Structurd Data spec needs "Binary" se= rialization to be renamed to something less generic, since Protocol Buffers= is a binary serialization as well.

Morgaine.
--0015175cdef22652680462afff48-- From morgaine.dinova@googlemail.com Wed Feb 11 19:29:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539603A68C2 for ; Wed, 11 Feb 2009 19:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koeH+1dsToJT for ; Wed, 11 Feb 2009 19:29:06 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 015DD3A6A42 for ; Wed, 11 Feb 2009 19:29:01 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so192285qwe.31 for ; Wed, 11 Feb 2009 19:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=RlLBpjoPuxNmzH4YMzwUqNoPuCHUEQN2XIN3fR15P/c=; b=l1NnsbWMSZGz219XHYuvsJ/+lgpESfMlGOgDa/7x9Bx5t2Rc6rcOWsc9UQD8it6qqQ 0T9zy2+BRU7g4qLm5RLmVKK6Fvdg+O/RzDZFrrbpl7cTZtu4d0NmdsEGXhtzYAEvTxUl WcazpySl/zf/J4gGohaHyPi2j3ucO5fhfi7tM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CvnUrxzdHeLydSawgn5LAJIoolCReyKTL/1brkdFdOOAgdtOMJrJXh9S0Bxjb00gWi 6pmE8s/0LQ4lLceal/nJKZsdQ3AqItHgPSg0VCluQ0KB4YGaeXQSvi2kBLf7XXhI9c0w Hp4Y7r3BcZCrAM6qWNDgEG3gr4uMHUZZnf/o0= MIME-Version: 1.0 Received: by 10.224.45.76 with SMTP id d12mr367556qaf.158.1234409346016; Wed, 11 Feb 2009 19:29:06 -0800 (PST) In-Reply-To: <49930D07.10408@lindenlab.com> References: <4992E35B.5060200@gmail.com> <49930D07.10408@lindenlab.com> Date: Thu, 12 Feb 2009 03:29:05 +0000 Message-ID: From: Morgaine Dinova To: Meadhbh Hamrick Content-Type: multipart/alternative; boundary=0015175cde2c93a4860462b0529b Cc: mmox@ietf.org Subject: Re: [mmox] Third and last proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 03:29:07 -0000 --0015175cde2c93a4860462b0529b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 11, 2009 at 5:38 PM, Meadhbh Hamrick wrote: > you're free to create your own specification (VWSD) that includes concepts > from LLSD or even references LLSD but adds the component language. > There might be some merit in that. The relationships might be something like the following (where "MMOP" is the extensible core protocol created by MMOX: 1) LLSD: defines a foundational ADT definition and an extensible set of serializations as used by Linden Lab in SL. This is general purpose and independent of any application domain, ie. it does not refer to VW conceps at all. (It may need to be extended though, in which case the name might change.) 2) VWSD: defines the set of ADTs (taken from LLSD[-Extended]) that form the "universe of discourse" for VW interop. In other words, VWs communicate by interchange of these elements of data, and no others. Most importantly, VWSD defines how VW-specific concepts are mapped onto the chosen ADTs. 3) MMOP: defines how the data elements described in VWSD are used in the interop protocol. This is much higher level than VWSD and introduces many VW semantic elements, but it defines no new data types and uses the VW-ADT mappings defined in VWSD. That seems fairly reasonable. VWSD would provide a very concise definition of the data used by VWs (the specific bit definitions would be in LLSD), and people could still use the generic tools that they've developed for LLSD since VWSD is just a subset of LLSD with extra mapping information. Does this sound right? Morgaine. --0015175cde2c93a4860462b0529b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 11, 2009 at 5:38 PM, Meadhbh= Hamrick <in= finity@lindenlab.com> wrote:
 
you're free to create your own specification (VWSD) that includes conce= pts from LLSD or even references LLSD but adds the component language.
 
There might be some merit in that. = ; The relationships might be something like the following (where "MMOP= " is the extensible core protocol created by MMOX:


1) LLSD:= defines a foundational ADT definition and an extensible set of serializati= ons as used by Linden Lab in SL.  This is general purpose and independ= ent of any application domain, ie. it does not refer to VW conceps at all.&= nbsp; (It may need to be extended though, in which case the name might chan= ge.)

2) VWSD: defines the set of ADTs (taken from LLSD[-Extended]) that form= the "universe of discourse" for VW interop.  In other words= , VWs communicate by interchange of these elements of data, and no others.&= nbsp; Most importantly, VWSD defines how VW-specific concepts are mapped on= to the chosen ADTs.

3) MMOP: defines how the data elements described in VWSD are used in th= e interop protocol.  This is much higher level than VWSD and introduce= s many VW semantic elements, but it defines no new data types and uses the = VW-ADT mappings defined in VWSD.


That seems fairly reasonable.  VWSD would provide a very conci= se definition of the data used by VWs (the specific bit definitions would b= e in LLSD), and people could still use the generic tools that they've d= eveloped for LLSD since VWSD is just a subset of LLSD with extra mapping in= formation.

Does this sound right?

Morgaine.
--0015175cde2c93a4860462b0529b-- From morgaine.dinova@googlemail.com Wed Feb 11 20:07:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 664363A696E for ; Wed, 11 Feb 2009 20:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gMJCSkm-5N2 for ; Wed, 11 Feb 2009 20:07:57 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 061033A68C3 for ; Wed, 11 Feb 2009 20:07:56 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so196308qwe.31 for ; Wed, 11 Feb 2009 20:08:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LpY0tO6UTBNGCG19zuKEoucBmKJB9Fn/V+OfaZ1SPN8=; b=nitumB5/0ke8VkI2RHZ276taMuiwCFbkJjv9Bi2L/thp9Fc3B5iOu1cAxVkpwOxCpG VdYnCq72OMPRhEIyh7NQoILHD+QaIs96wMEzOOC/sLTvxySw7j08W4sj6MYHJ0MmB/Oe u1bIf5PJR3b2GE0pwNduDpgNmUDXDi8aRusns= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lxcG6HBb9x2jSZ0Tg4swCAH6Bnpe720rma0R6FEtfacngHLpyVMdX6HXsbthmmnXGd XUXWsrZHNhFOtdLmp8AlSxfjqW9RVlwz3vI6Tytn7FWS1F95m3zcPZ31uiFztuXJOspY njS6naq4Rp38dRNFerkVLTPxB9qNKuZ75MG/8= MIME-Version: 1.0 Received: by 10.224.61.14 with SMTP id r14mr394899qah.253.1234411681025; Wed, 11 Feb 2009 20:08:01 -0800 (PST) In-Reply-To: <1A437F8E-2A23-4F4C-B9D6-03D827BAB66F@lindenlab.com> References: <1A437F8E-2A23-4F4C-B9D6-03D827BAB66F@lindenlab.com> Date: Thu, 12 Feb 2009 04:08:00 +0000 Message-ID: From: Morgaine Dinova To: Mark Lentczner Content-Type: multipart/alternative; boundary=0015175ce0f0c10f680462b0dd24 Cc: mmox@ietf.org Subject: Re: [mmox] LLSD -- Serialization Priority X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 04:07:58 -0000 --0015175ce0f0c10f680462b0dd24 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The IETF's "Robustness Principle" suggests a good approach to use in this area: "*be conservative in what you do, be liberal in what you accept from others*". In terms of serializations, this probably means something like: 1) If at all possible, always offer more than one alternative. "Power providers" should aim at more alternatives rather than fewer, to embrace as many other VWs as possible. 2) Never make one alternative mandatory, particularly a heavyweight one since that would tend to exclude restricted-capability clients from interop. 3) Be fluid, let progress and experience establish preferences rather than imposing them in a spec. After all, none of us knows what the VW universe will be like in just a few short years, and trying to force a direction on the Internet is like herding cats. I believe that we're heading in the right direction already for this, in making alternative serializations foundational. Strong prescriptive requirements would I think not help. Morgaine. On Wed, Feb 11, 2009 at 4:47 PM, Mark Lentczner wrote: > I agree there is some ambiguity about what is the intent of having multiple > serializations. I see several possible approaches: > > 1) We insist that all systems that accept LLSD implement all > serializations. This leaves the choice up to the generator of the data. > > 2) We leave the choice up to the consumer of the data, and declare that all > requests for LLSD must include some content type negotiation mechanism (such > as in HTTP), and therefore all generators of LLSD must support all > serializations. > > 3) One serialization is chosen to be "mandatory", the rest are optional. > > 4) No preference or requirement of support is stated. > > Working backwards: > > I don't support #4, because it doesn't ensure interoperability. It means > different systems would have to advertise, out of band, what forms they > accepted and generated. This strikes me of being like the early days of > TIFF format, where complaint software would often be unable to read each > others' files. > > Option #3 has the easiest interoperability story. But, unless there are > major advantages to the non-required serializations, there will be little > support for them. After all, once you've done the one required format, why > do the others? We only have internal experience data to compare two of the > formats, and not enough inter-system experience to know what would be best > here. If experience shows that there is little practical difference between > supporting the different serializations, then one might question why define > alternatives. > > If we thought there would be many many more consumers of LLSD vs. > producers, then #2 would make sense. However, it does place a burden of > content negotiation on any protocol or process that transmits serialized > LLSD. On the face of it, I think the premise here is false: I believe that > all sub-systems in an OGP network will produce and consume LLSD with equal > frequency. Another argument in favor of #2 is that parsing tends to be the > more expensive operation in LLSD transport, and different implementations > will favor different parsing solutions, often because they match the > semantics and/or type systems of the implementation language. > > If there was a substantial expense in serializing LLSD, then #1 would allow > implementations to choose what suits them best. However, this is also not > borne out by experience: Generating these different serializations takes > about the same amount of work. In fact they can all easily be generated by > the same code using a common base class and having subclasses supply strings > for structure and a few overridden routines for string escaping and such. > > My sense is that we will settle on either #3 or #2. Until then, I think we > are all operating under approach #5: > > 5) Support for all serializations is mandatory. > > - Mark > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --0015175ce0f0c10f680462b0dd24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The IETF's "Robustness Principle" suggests a good approach to= use in this area:  "be conservative in what you do, be libera= l in what you accept from others".  In terms of serialization= s, this probably means something like:


1) If at all possible, always offer more than one alternative. = ; "Power providers" should aim at more alternatives rather than f= ewer, to embrace as many other VWs as possible.

2) Never make one al= ternative mandatory, particularly a heavyweight one since that would tend t= o exclude restricted-capability clients from interop.

3) Be fluid, let progress and experience establish preferences rather t= han imposing them in a spec.  After all, none of us knows what the VW = universe will be like in just a few short years, and trying to force a dire= ction on the Internet is like herding cats.


I believe that we're heading in the right direction already for= this, in making alternative serializations foundational.  Strong pres= criptive requirements would I think not help.


Morgaine.

<= br>
On Wed, Feb 11, 2009 at 4:47 PM, Mark Lentcz= ner <markl@lind= enlab.com> wrote:
I agree there is some ambiguity about what is the intent of having multiple= serializations. I see several possible approaches:

1) We insist that all systems that accept LLSD implement all serializations= .  This leaves the choice up to the generator of the data.

2) We leave the choice up to the consumer of the data, and declare that all= requests for LLSD must include some content type negotiation mechanism (su= ch as in HTTP), and therefore all generators of LLSD must support all seria= lizations.

3) One serialization is chosen to be "mandatory", the rest are op= tional.

4) No preference or requirement of support is stated.

Working backwards:

I don't support #4, because it doesn't ensure interoperability. It = means different systems would have to advertise, out of band, what forms th= ey accepted and generated.  This strikes me of being like the early da= ys of TIFF format, where complaint software would often be unable to read e= ach others' files.

Option #3 has the easiest interoperability story.  But, unless there a= re major advantages to the non-required serializations, there will be littl= e support for them. After all, once you've done the one required format= , why do the others? We only have internal experience data to compare two o= f the formats, and not enough inter-system experience to know what would be= best here. If experience shows that there is little practical difference b= etween supporting the different serializations, then one might question why= define alternatives.

If we thought there would be many many more consumers of LLSD vs. producers= , then #2 would make sense. However, it does place a burden of content nego= tiation on any protocol or process that transmits serialized LLSD. On the f= ace of it, I think the premise here is false: I believe that all sub-system= s in an OGP network will produce and consume LLSD with equal frequency. Ano= ther argument in favor of #2 is that parsing tends to be the more expensive= operation in LLSD transport, and different implementations will favor diff= erent parsing solutions, often because they match the semantics and/or type= systems of the implementation language.

If there was a substantial expense in serializing LLSD, then #1 would allow= implementations to choose what suits them best. However, this is also not = borne out by experience: Generating these different serializations takes ab= out the same amount of work. In fact they can all easily be generated by th= e same code using a common base class and having subclasses supply strings = for structure and a few overridden routines for string escaping and such.
My sense is that we will settle on either #3 or #2. Until then, I think we = are all operating under approach #5:

5) Support for all serializations is mandatory.

       - Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

markl@lindenlab.co= m

Zero Linden
zero.linden= @secondlife.com





_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--0015175ce0f0c10f680462b0dd24-- From morgaine.dinova@googlemail.com Wed Feb 11 20:23:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984B23A6778 for ; Wed, 11 Feb 2009 20:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+RPUwD4hv9a for ; Wed, 11 Feb 2009 20:23:16 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 5CBB33A6927 for ; Wed, 11 Feb 2009 20:23:16 -0800 (PST) Received: by qyk4 with SMTP id 4so800966qyk.13 for ; Wed, 11 Feb 2009 20:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Qi/78RH/SkgDhcv60sJVcqIsVBSyX/Y77v2/UZXCknQ=; b=WXRsWbNR4Ye96yhTHWBlBYuIP/S7+BRNaIl9lGVZapyjGfuM6rcSj5cybWAivR/+HE ZZgZqy2jSYiMSs2Al72QdZd5iaQGXg61n7plllKvY2vq0y0oN3ow1VXrXy73ylygwTcf ru/ZgxV1zbLY3nx93jAE6b2eF1AZTcYC252jA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NPgfDZd7ZF7GZnAlTlqvCq/ryT6VAZp8oioppfg6PmZtTp9C2xaxeAaR43LBumsQRY lSnNpzrWgVRpkY68hZfSy/VXOJY4KttGWEFfyKWJ2VVVrz2qcmD+CkRXxXQx2hTYHvfD oP6dPxbcr2sT+fHO+NGg6Lv0uTg8fyjE4XxsU= MIME-Version: 1.0 Received: by 10.224.89.10 with SMTP id c10mr389340qam.371.1234412599996; Wed, 11 Feb 2009 20:23:19 -0800 (PST) In-Reply-To: <49931BAA.10109@gmail.com> References: <49931BAA.10109@gmail.com> Date: Thu, 12 Feb 2009 04:23:19 +0000 Message-ID: From: Morgaine Dinova To: Jon Watte Content-Type: multipart/alternative; boundary=0015175cdbc687723a0462b11461 Cc: mmox@ietf.org Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 04:23:17 -0000 --0015175cdbc687723a0462b11461 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jon makes an important point through his question I think. Unless the MMOX protocols are intended to carry EVERYTHING related to VWs (and they well might, though I doubt it), we really need to partition the universe of discourse into those things that we intend to cover and those things that we don't. A list of inclusions and exclusions (if any) would be very useful to direct the discussion ahead. As OGP is currently the only specific proposal on the table (we're waiting for John to deliver his counter-proposal), I think it would be appropriate and helpful if OGP designers could give us a tentative list here to outline their thinking. Morgaine. On Wed, Feb 11, 2009 at 6:40 PM, Jon Watte wrote: > Catherine Pfeffer wrote: > >> I propose to tighten the link to virtual words by specifying how typical >> virtual worlds data fit in the general principles expressed in the draft. >> > > What kinds of virtual world data do you imagine running through this > system? > Service requests? > Service request responses? > Mesh data? > Animation data? > Terrain data? > Entity behavior? > Multimedia streams? > Real-time interactions? > User input/control data? > Network packet structure? > Entity interactions? > Database records? > On-disk files? > > Each of these usage scenarios have different requirements. For example, as > proposed, LLSD might be fine for service requests, but would probably fall > short for something like terrain data (which requires indexing and random > access). > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --0015175cdbc687723a0462b11461 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jon makes an important point through his question I think.

Unless th= e MMOX protocols are intended to carry EVERYTHING related to VWs (and they = well might, though I doubt it), we really need to partition the universe of= discourse into those things that we intend to cover and those things that = we don't.  A list of inclusions and exclusions (if any) would be v= ery useful to direct the discussion ahead.

As OGP is currently the only specific proposal on the table (we're = waiting for John to deliver his counter-proposal), I think it would be appr= opriate and helpful if OGP designers could give us a tentative list here to= outline their thinking.

Morgaine.



On Wed, Feb 11, 200= 9 at 6:40 PM, Jon Watte <jwatte@gmail.com> wrote:
Catherine Pfeffer wrote:
I propose to tighten the link to virtual words by specifying how typical vi= rtual worlds data fit in the general principles expressed in the draft.

What kinds of virtual world data do you imagine running through this system= ?
Service requests?
Service request responses?
Mesh data?
Animation data?
Terrain data?
Entity behavior?
Multimedia streams?
Real-time interactions?
User input/control data?
Network packet structure?
Entity interactions?
Database records?
On-disk files?

Each of these usage scenarios have different requirements. For example, as = proposed, LLSD might be fine for service requests, but would probably fall = short for something like terrain data (which requires indexing and random a= ccess).

Sincerely,

jw

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--0015175cdbc687723a0462b11461-- From morgaine.dinova@googlemail.com Wed Feb 11 21:21:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66CB3A696C for ; Wed, 11 Feb 2009 21:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdT4JP6ciyo7 for ; Wed, 11 Feb 2009 21:21:28 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id AADE63A6778 for ; Wed, 11 Feb 2009 21:21:28 -0800 (PST) Received: by qyk4 with SMTP id 4so817689qyk.13 for ; Wed, 11 Feb 2009 21:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ttkd3j6nsUbkJcGF6uailNoY1e43jxxZIOJniE81SXY=; b=i2jBiUHBIryaudLj+GaHBkeP+CFNX5D8wZJ7aoQOGbR1hHdzs0QY2xV0PHGGsZd9bh Vzaf+DtkdHLnIJRsgzD1KFkS7FP2YQP4IifNiMp7ne9kl40OYbYJO6wmNJPRBAdcqVf1 1tupSv9ANJAiwYXg8zQKO39V9fmnz3MRea5G0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NDnIxNAL7/8nu5B6rFG4UZLH0YW+dCGIujg1wV4cqthDRePMtWEW8qjr6XUWO74QaJ kfVa109PLadoLqBVl3FU6eXZ49Czvd1fTEGdMzR5Z0BLTxM270mDZHsz+F4a9WtXVFHI m5YR4r6gNEtkXXeNREV1U2WyiN3Y6MlT+WzBk= MIME-Version: 1.0 Received: by 10.224.2.205 with SMTP id 13mr414172qak.343.1234416093491; Wed, 11 Feb 2009 21:21:33 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2009 05:21:33 +0000 Message-ID: From: Morgaine Dinova To: Cenji Neutra Content-Type: multipart/alternative; boundary=0015175ca88ec1f5040462b1e423 Cc: mmox@ietf.org Subject: Re: [mmox] Proposal for small enhancement in the LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 05:21:30 -0000 --0015175ca88ec1f5040462b1e423 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 11, 2009 at 4:24 PM, Cenji Neutra wrote: > > Perhaps xxSD doesn't belong in any MMOX standard at all, except as > being referenced as a preferred (or maintained) format for message > exchange in some VW-specific protocols the standard defines. In that > case it may need to be standardized elsewhere (though I'm not sure it > adds sufficient additional benefits over its concrete serializations > in XML or JSON to warrant that). > And what you say reflects reality too --- LLSD is an independent data types specification that isn't tied to VW use at all, so it doesn't fall naturally into MMOX's native domain anyway. We are mere USERS of such a spec, in the same way that we will be mere users of many other RFCs and Internet standards. This is why LLSD as a milestone was omitted from the latest version of the MMOX draft charter. It's an LL milestone, not a MMOX one, and as Infinity rightly pointed out, MMOX efforts are better spent dealing with VW concerns rather than with abstract data type specifications. Of course, if we find that an LL-published LLSD RFC is not adequate for our needs then we will be making a modified/extended specification (or use something different entirely) as a MMOX deliverable too, but nobody has suggested a serious counter-proposal to using LLSD yet. Morgaine. --0015175ca88ec1f5040462b1e423 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 11, 2009 at 4:24 PM, Cenji N= eutra <cenji= .neutra@gmail.com> wrote:

Perhaps xxSD doesn't belong in any MMOX standard at all, except as
being referenced as a preferred (or maintained) format for message
exchange in some VW-specific protocols the standard defines.  In that<= br> case it may need to be standardized elsewhere (though I'm not sure it adds sufficient additional benefits over its concrete serializations
in XML or JSON to warrant that).

And what you say reflects reality too --- LLSD is an = independent data types specification that isn't tied to VW use at all, = so it doesn't fall naturally into MMOX's native domain anyway. = ; We are mere USERS of such a spec, in the same way that we will be mere us= ers of many other RFCs and Internet standards.

This is why LLSD as a milestone was omitted from the latest version of = the MMOX draft charter.  It's an LL milestone, not a MMOX one, and= as Infinity rightly pointed out, MMOX efforts are better spent dealing wit= h VW concerns rather than with abstract data type specifications.

Of course, if we find that an LL-published LLSD RFC is not adequate for= our needs then we will be making a modified/extended specification (or use= something different entirely) as a MMOX deliverable too, but nobody has su= ggested a serious counter-proposal to using LLSD yet.

Morgaine.

--0015175ca88ec1f5040462b1e423-- From cathypfeffer@gmail.com Thu Feb 12 00:55:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3393A6971 for ; Thu, 12 Feb 2009 00:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4vKhpFqQ8Da for ; Thu, 12 Feb 2009 00:55:54 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id B2AA83A68CC for ; Thu, 12 Feb 2009 00:55:53 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so56538eya.31 for ; Thu, 12 Feb 2009 00:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=QA/9X10zw+KcZsoqWdxJx+vIZoNWaFZIHy3/wSlN+U4=; b=Ocb0PjzVZAZMTSDZCJt4oiHzO99l+OU4Z+QiVcTKJh8OMHIxQKtltUhweYiCibSnNb yCrKG97AyRM311HNAGM1eYwsZqW9wxkvjGzBOWRfCCE0e9taRksv/ZeiTi8r/vhMFXpz 41EXWsoa1U/FjOKucKVVvq//3q3FVbzTtLpWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=C4/FoWf/FgmB3tMF4y32caDNv8NFj2OJ8Fm8wZ00CTlDe9a8eG8nXOUdNGl3XugCL6 hlsa8SwYIYqV5poyJPIq0R5Tx8jtqu8YOyMpVJB4wids0z+tDm8B0T8475zAT8aZBJ9Z AKO84ynyvh3pGWZF39S8cQKj1UpVmylvz3ZlU= MIME-Version: 1.0 Received: by 10.210.57.5 with SMTP id f5mr526199eba.14.1234428958493; Thu, 12 Feb 2009 00:55:58 -0800 (PST) Date: Thu, 12 Feb 2009 09:55:58 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c1796924a9f0462b4e305 Subject: [mmox] LLSD, VWSD and MMOP X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 08:55:55 -0000 --0015174c1796924a9f0462b4e305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Morgaine said: > 1) LLSD: defines a foundational ADT definition and an extensible set of > serializations as used by Linden Lab in SL. > 2) VWSD: defines the set of ADTs (taken from LLSD[-Extended]) that form the > "universe of discourse" for VW interop. > 3) MMOP: defines how the data elements described in VWSD are used in the > interop protocol. > Does this sound right? > since VWSD is just a subset of LLSD with extra mapping information. Taking the example of 64 bit integers, I don't see how 64 bit integers could be defined in a subset of a 32 bit only standard. It would rather be the reverse way then, LLSD as a subset of VWSD. Besides that, I'm not sure that decoupling communication with other grids from SL internal mechanisms is a good idea. Or did I miss your point? -- Cathy --0015174c1796924a9f0462b4e305 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Morgaine said:
> 1) LLSD: defines a foundational ADT definition and a= n extensible set of
> serializations as used by Linden Lab in SL.
= > 2) VWSD: defines the set of ADTs (taken from LLSD[-Extended]) that for= m the
> "universe of discourse" for VW interop.
> 3) MMOP: def= ines how the data elements described in VWSD are used in the
> intero= p protocol.
> Does this sound right?

> since VWSD is just a subset of LLSD with extra mapping information= .

Taking the example of 64 bit integers, I don't see how 64 bit = integers could be defined in a subset of a 32 bit only standard. It would r= ather be the reverse way then, LLSD as a subset of VWSD.

Besides that, I'm not sure that decoupling communication with other= grids from SL internal mechanisms is a good idea.

Or did I miss you= r point?

--
Cathy
--0015174c1796924a9f0462b4e305-- From morgaine.dinova@googlemail.com Thu Feb 12 03:01:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0FDB3A6A71 for ; Thu, 12 Feb 2009 03:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWl4u7wZ1egQ for ; Thu, 12 Feb 2009 03:01:49 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 8FE413A6B32 for ; Thu, 12 Feb 2009 03:01:49 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so230828qwe.31 for ; Thu, 12 Feb 2009 03:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=FfKnO3lmZtf2HUIXPswrUg38lr/qQjgAZlMmYWXlsa0=; b=HiiN/dHvstohfe3ZdmyANCgiqFx9i9mzh9OjFy16YgZ3DYNbGa7GdW5+toDZt6l2U8 h0bsArIEWCDIRieWiNWmDVTHd1wL20tI9jslrmKGgwuIHE8wzKjniIskfZV+cGrO+Ph+ RON3R24PFK9tuKagNgCACv/qkvyTN+8mqE/3Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=i4W9IFtEWVrOrHUIkboiXo/CDd2SO7SbBgKBbEkOQzMWQzdsWF2vU3TulVe1y2Ie1M bCIwxw+8swkS1fU/xh3KDoJxgriI7m6gTuEiiQvbE+0R/ecahDstgKcWpW1wwSElTDhx O114GQlpQJ47H9iujWTRPTLg4JoIUDPiDpz38= MIME-Version: 1.0 Received: by 10.224.28.143 with SMTP id m15mr962003qac.82.1234436513660; Thu, 12 Feb 2009 03:01:53 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2009 11:01:53 +0000 Message-ID: From: Morgaine Dinova To: Catherine Pfeffer Content-Type: multipart/alternative; boundary=0015175cb144e500050462b6a5eb Cc: mmox@ietf.org Subject: Re: [mmox] LLSD, VWSD and MMOP X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 11:01:51 -0000 --0015175cb144e500050462b6a5eb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Apparently LLSD is being modified for 64-bit integers, which would still allow LLSD to be the independent and generic superset of all types required by VWSD. If so then this decoupling into 3 levels of specification would still be possible. Indeed, if LL is willing to update LLSD regularly with every new data type that we require, this situation could continue indefinitely, ie. LLSD always defining the low-level bits in an application-agnostic manner. I particularly like idea of VWSD defining the mapping of special VW types into LLSD data types without itself introducing new data types. This is clean separation of concerns, allowing LLSD to be generic and MMOP to be compact and concerned with protocol only. Morgaine. On Thu, Feb 12, 2009 at 8:55 AM, Catherine Pfeffer wrote: > Morgaine said: > > 1) LLSD: defines a foundational ADT definition and an extensible set of > > serializations as used by Linden Lab in SL. > > 2) VWSD: defines the set of ADTs (taken from LLSD[-Extended]) that form > the > > "universe of discourse" for VW interop. > > 3) MMOP: defines how the data elements described in VWSD are used in the > > interop protocol. > > Does this sound right? > > > since VWSD is just a subset of LLSD with extra mapping information. > > Taking the example of 64 bit integers, I don't see how 64 bit integers > could be defined in a subset of a 32 bit only standard. It would rather be > the reverse way then, LLSD as a subset of VWSD. > > Besides that, I'm not sure that decoupling communication with other grids > from SL internal mechanisms is a good idea. > > Or did I miss your point? > > -- > Cathy > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --0015175cb144e500050462b6a5eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Apparently LLSD is being modified for 64-bit integers, which would still al= low LLSD to be the independent and generic superset of all types required b= y VWSD.  If so then this decoupling into 3 levels of specification wou= ld still be possible.

Indeed, if LL is willing to update LLSD regularly with every new data t= ype that we require, this situation could continue indefinitely, ie. LLSD a= lways defining the low-level bits in an application-agnostic manner.

I particularly like idea of VWSD defining the mapping of special VW typ= es into LLSD data types without itself introducing new data types.  Th= is is clean separation of concerns, allowing LLSD to be generic and MMOP to= be compact and concerned with protocol only.

Morgaine.



On Thu, Feb 12, 200= 9 at 8:55 AM, Catherine Pfeffer <cathypfeffer@gmail.com> wrote:
Morgaine said:
> 1) LLSD: defines a foundational ADT definition and a= n extensible set of
> serializations as used by Linden Lab in SL.
= > 2) VWSD: defines the set of ADTs (taken from LLSD[-Extended]) that for= m the
> "universe of discourse" for VW interop.
> 3) MMOP: def= ines how the data elements described in VWSD are used in the
> intero= p protocol.
> Does this sound right?

> since VWSD is just a subset of LLSD with extra mapping information= .

Taking the example of 64 bit integers, I don't see how 64 bit = integers could be defined in a subset of a 32 bit only standard. It would r= ather be the reverse way then, LLSD as a subset of VWSD.

Besides that, I'm not sure that decoupling communication with other= grids from SL internal mechanisms is a good idea.

Or did I miss you= r point?

--
Cathy

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--0015175cb144e500050462b6a5eb-- From cathypfeffer@gmail.com Thu Feb 12 06:53:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C30828C1AC for ; Thu, 12 Feb 2009 06:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhdX9RshcTNL for ; Thu, 12 Feb 2009 06:53:06 -0800 (PST) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by core3.amsl.com (Postfix) with ESMTP id 5F9C63A6886 for ; Thu, 12 Feb 2009 06:53:06 -0800 (PST) Received: by ewy14 with SMTP id 14so620642ewy.13 for ; Thu, 12 Feb 2009 06:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=vaKl2UtxvRUki4R8vEOIEbDFYNqLQpA8zWwW0CVoPLk=; b=gnamneVOmKgry0qPvyMXkr0N7UYyo7GnPf0CaiBNnse9lv3fV4uNZ7OlVv2OcGaBsm mOHMempHjv3ltU+bprWGoTw0kh8/rLG3zDZBYbFiJsCp/RXZRG58rFlyyGnYzQkkNhMu CoRK2IE1ot783Mmizm5wxrnNInSwOXy44DQNs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=iI3GnYHVv6CqtqDXAdvOVu/QrmWpVBAGAPCtB1S00dEG8YKBsdRGxuOdBABpOPFMUy P5/Kx8RP4glX/oMXZ5hVMn4h6DTSNKKB3N2JyGU6Sf1eW4E/SXoigrIWhzsSIiEd2VmJ FWB6iMgWSxQ/R60Obs6SOTpHjUXnkS4BGJgLs= MIME-Version: 1.0 Received: by 10.210.57.5 with SMTP id f5mr758783eba.14.1234450390894; Thu, 12 Feb 2009 06:53:10 -0800 (PST) Date: Thu, 12 Feb 2009 15:53:10 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c17960ac7680462b9e1c9 Subject: [mmox] LLSD, VWSD and MMOP X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 14:53:07 -0000 --0015174c17960ac7680462b9e1c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Indeed, if LL is willing to update LLSD regularly with every new data type > that we require, this situation could continue indefinitely, ie. LLSD always > defining the low-level bits in an application-agnostic manner. Ah OK, now I understand what you meant. I'm quite confident that, with the introduction of more scalar types, apparition of new species (Hi, Darwin!) of data types would stop there. After all, Second Life works rather well currently with the reduced set of data types that is currently in LLSD. And even if more data types appear to be necessary later on (hum, like a date and time elementary format), there's nothing wrong with going back to xxSD draft and adding provision for the missing data type. As long as it is a draft, nothing is engraved into stone and it is okay that xxSD and whatever is built on top of it enrich themselves mutually. But what you propose is okay too. It's just a different way of organizing the standard. Personally I prefer something a bit simpler, like the current draft, that's all. -- Cathy --0015174c17960ac7680462b9e1c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Indeed, if LL is willing to update LLSD regularly with every new data = type
> that we require, this situation could continue indefinitely, i= e. LLSD always
> defining the low-level bits in an application-agnost= ic manner.

Ah OK, now I understand what you meant.

I'm quite confident = that, with the introduction of more scalar types, apparition of new species= (Hi, Darwin!) of data types would stop there. After all, Second Life works= rather well currently with the reduced set of data types that is currently= in LLSD.

And even if more data types appear to be necessary later on (hum, like = a date and time elementary format), there's nothing wrong with going ba= ck
to xxSD draft and adding provision for the missing data type. As long= as it is a draft, nothing is engraved into stone and it is okay that xxSD = and whatever is built on top of it enrich themselves mutually.

But what you propose is okay too. It's just a different way of orga= nizing the standard. Personally I prefer something a bit simpler, like the = current draft, that's all.


--
Cathy
--0015174c17960ac7680462b9e1c9-- From morgaine.dinova@googlemail.com Thu Feb 12 07:17:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1D3428C1F3; Thu, 12 Feb 2009 07:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.143 X-Spam-Level: X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0CdU5RcU11K; Thu, 12 Feb 2009 07:16:59 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id DE32A3A69E4; Thu, 12 Feb 2009 07:16:58 -0800 (PST) Received: by qyk4 with SMTP id 4so999842qyk.13 for ; Thu, 12 Feb 2009 07:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=acBwAlDOm7qjc/Sygc/z//YhrtlL+M6dtXuqCKYYaaM=; b=rldmN/8INVFBBz94OPduJSQmpZLUj8g/1BYP2rXHiSSNLAfjuOAhKf6sRTKAmO58Mi FIDTfN11UWI4n9ro0A1i9luDXutswORyQFYBAe+jPw39Mc69+8qFgIRdoE3HZyI2at0e M3VlXGvbXqeBX1xIexn2sF5Ox7b3qh0nyPoik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bR1tpqn/+0ic/+4s6Gn9N60lo9s+QlY4dcksfpuItz0rFGLyP/NwqoIsp+csegJeh+ 2tWrogANTjg5FwRvE/sFNzsiPwL8SGJloknE2lH0F9IJQTteMdlhg3YPorp8Cn0GcitI jWMt6Wf3zEi1D6uWTZcDolxCi3wFXr5cD+Y+U= MIME-Version: 1.0 Received: by 10.224.19.206 with SMTP id c14mr1382949qab.26.1234451823090; Thu, 12 Feb 2009 07:17:03 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2009 15:17:03 +0000 Message-ID: From: Morgaine Dinova To: David W Levine Content-Type: multipart/alternative; boundary=0015175cba66685e090462ba36a0 Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] LLSD -- 64 bit Integers X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:17:03 -0000 --0015175cba66685e090462ba36a0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 11, 2009 at 9:02 PM, David W Levine wrote: > > I think Ewen's posited ground rule feels right. The presence or absence of > a native 64 bit type in a specific language is a very weak reason to support > it in a wire format intended to be language independent. > Further, per comments from several others, if we're doing this with native > types and possible type casting in various ways, we need the wire format to > be quite unambiguous about signed, unsigned, and so on. Ambiguity has no > place at all in this sort of specification, the fact that questions about > sign bits showed up today, is a hint to be careful on that. > > - David W. Levine > ~ Zha Ewry (ISL) > > I second both parts of that argument. I also worry that we're not addressing its second part at all. By restricting ourselves to a single form of integer, we seem to be heading directly towards defeat in the battle against ambiguity. Defining multiple distinct integer types is almost completely free of cost, yet I've heard many people reject the idea through an incomprehensible "proliferation" argument. Defining numerous types to support myriad very diverse components most effectively is the basis of engineering, and we should embrace it, not shy away from it. Morgaine. > > *Ewen Cheslack-Postava * > Sent by: mmox-bounces@ietf.org > > 02/11/2009 03:36 PM > To > Jon Watte > cc > mmox@ietf.org Subject > Re: [mmox] LLSD -- 64 bit Integers > > > > > On Wed, Feb 11, 2009 at 11:07 AM, Jon Watte wrote: > > Mark Lentczner wrote: > >> > >> There is also the fact that there has been little call for 64 bit > integers > >> in the interfaces and APIs that we have built for virtual worlds. The > only > >> place I know of in our entire protocol is an obvious design mistake: Two > 32 > >> bit integers are concatenated to form a 64 bit identifier. It would have > >> been better to just treat the array of the two integers as the > identifier. > > > > Our system uses 64-bit integers extensively for object identifiers, time > > step counters, virtual currency, and other such potentially "large" > > quantities. I would say that any forward-looking standard needs to > support > > 64-bit integer domains. One way to solve this is to leave the max size of > > integers as something that's specified on a per-field basis, and/or > support > > continuation encoding of integers (7 bits per byte; if high bit is set, > > shift and concatenate the next 7 bits. Repeat). > > There are a number of places I'd expect 64 bit integers to be used as > well, absolute time points being the most obvious. > > But beyond that, the reasoning given leads to a *very* slippery slope, > the bottom of which is a "least common denominator" approach. In this > case the issue is efficiency, but it seems to me that's a bad > argument. Because python (or some other language) doesn't have native > support for a feature, no language gets to use it. Now if I want to > represent a time as a 64bit int, I have to use 2x32bit ints and do the > munging manually. Suddenly my C++ code, which could handle this > efficiently, also becomes inefficient. Either that or we end up with > layers on top of the standard interface to provide these > features/conversions for "free". But then we might as well include > them in the standard since they'll be implemented for every language > anyway. > > Computational efficiency isn't the only concern either. Currently > there is only support for double precision in xxSD. Is this a > foregone conclusion since Ruby doesn't support native single precision > floats? This is a wire protocol, so there should be efficient > encodings when necessary. Forcing double precision is wasteful in a > lot of case, e.g. when specifying location information in a local > frame (mesh vertices) or specifying normals, which shouldn't require > so much precision. > > The barrier to entry should be "is this feature useful and does it > have a reasonable implementation" not "can this feature be implemented > efficiently everywhere." If you really need some service to be > implemented very efficiently and it has to handle a lot of data which > potentially uses 64bit ints, then maybe Python isn't the right > language for that implementation. The intent isn't to start a > language flame war, but to point out that if the desire is to have a > fairly language agnostic type system, then specific considerations for > specific languages generally shouldn't enter the equation. > > -Ewen > > > > > Sincerely, > > > > jw > > > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --0015175cba66685e090462ba36a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 11, 2009 at 9:02 PM, David W= Levine <dwl@us.ibm.= com> wrote:

I think Ewen's posited ground = rule feels right. The presence or absence of a native 64 bit type in a specific langua= ge is a very weak reason to support it in a wire format intended to be languag= e independent.
Further, per comments from several= others, if we're doing this with native types and possible type casting in vari= ous ways, we need the wire format to be quite unambiguous about signed, unsigne= d, and so on. Ambiguity has no place at all in this sort of specification, the fact that questions about sign bits showed up today, is a hint to be careful on that.

- David W. Levine
~ Zha Ewry (ISL)


I second both parts of that argument.  I also wo= rry that we're not addressing its second part at all.

By restric= ting ourselves to a single form of integer, we seem to be heading directly = towards defeat in the battle against ambiguity.  Defining multiple dis= tinct integer types is almost completely free of cost, yet I've heard m= any people reject the idea through an incomprehensible "proliferation&= quot; argument.  Defining numerous types to support myriad very divers= e components most effectively is the basis of engineering, and we should em= brace it, not shy away from it.

Morgaine.
 



 

Ewen Cheslack-Pos= tava <ewencp@gmail= .com>
Sent by: mmox-bounces@ietf.org

02/11/2009 03:36 PM

To
Jon Wat= te <jwatte@gmail.c= om>
cc
mmox@ietf.org
Subject
Re: [mmox] LLSD -- 64 bit Int= egers





On Wed, Feb 11, 2009 at 11:07 AM, Jon Watte <jwatte@gmail.com>= ; wrote:
> Mark Lentczner wrote:
>>
>> There is also the fact that there has been little call for 64 bit integers
>> in the interfaces and APIs that we have built for virtual worlds. The only
>> place I know of in our entire protocol is an obvious design mistak= e: Two 32
>> bit integers are concatenated to form a 64 bit identifier. It would have
>> been better to just treat the array of the two integers as the identifier.
>
> Our system uses 64-bit integers extensively for object identifiers, time
> step counters, virtual currency, and other such potentially "larg= e"
> quantities. I would say that any forward-looking standard needs to support
> 64-bit integer domains. One way to solve this is to leave the max size of
> integers as something that's specified on a per-field basis, and/o= r support
> continuation encoding of integers (7 bits per byte; if high bit is set,
> shift and concatenate the next 7 bits. Repeat).

There are a number of places I'd expect 64 bit integers to be used as well, absolute time points being the most obvious.

But beyond that, the reasoning given leads to a *very* slippery slope,
the bottom of which is a "least common denominator" approach.  In this
case the issue is efficiency, but it seems to me that's a bad
argument.  Because python (or some other language) doesn't have na= tive
support for a feature, no language gets to use it.  Now if I want to
represent a time as a 64bit int, I have to use 2x32bit ints and do the
munging manually.  Suddenly my C++ code, which could handle this
efficiently, also becomes inefficient.  Either that or we end up with<= br> layers on top of the standard interface to provide these
features/conversions for "free".  But then we might as well include
them in the standard since they'll be implemented for every language anyway.

Computational efficiency isn't the only concern either.  Currently=
there is only support for double precision in xxSD.  Is this a
foregone conclusion since Ruby doesn't support native single precision<= br> floats?  This is a wire protocol, so there should be efficient
encodings when necessary.  Forcing double precision is wasteful in a
lot of case, e.g. when specifying location information in a local
frame (mesh vertices) or specifying normals, which shouldn't require so much precision.

The barrier to entry should be "is this feature useful and does it
have a reasonable implementation" not "can this feature be implem= ented
efficiently everywhere."  If you really need some service to be
implemented very efficiently and it has to handle a lot of data which
potentially uses 64bit ints, then maybe Python isn't the right
language for that implementation.  The intent isn't to start a
language flame war, but to point out that if the desire is to have a
fairly language agnostic type system, then specific considerations for
specific languages generally shouldn't enter the equation.

-Ewen

>
> Sincerely,
>
> jw
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox
>
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--0015175cba66685e090462ba36a0-- From morgaine.dinova@googlemail.com Thu Feb 12 07:41:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D336F3A63EB for ; Thu, 12 Feb 2009 07:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQJ8AfNxfF5G for ; Thu, 12 Feb 2009 07:41:22 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 8748E3A67F0 for ; Thu, 12 Feb 2009 07:41:22 -0800 (PST) Received: by qyk4 with SMTP id 4so1022608qyk.13 for ; Thu, 12 Feb 2009 07:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=idWTLugXYZ+o6REKutWxzdYQQvzES42LqLsvTmpavLQ=; b=WWmVfbJWAY/L44JMdXNm5+Knuy0+ZYLbf+vhHUuZ0QWEMW4Uk38gwaE6xZ9CC8rFnK BiSKMS/TIVM2NjbDehrjwGNK81cJci8Lo9B03sNawHE+Iho3aoppYMtgNgbYp1U28ny3 SX8ZQBW0otmCj1g/HLcTvQT/Iw68jFdqp4eks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bOsZaEc9uec0/8E8MEi/aUTzLWJM10B7JRT4d7s9a7uNj5dQhJDFDU8QAPNlpNiM7I tevzhhdES+4h2wD4juIYyeatWGaGq3in/vp5s80+lB6GagOZw1+PCER6NzilpynIvTuc 7x28WP3upIkoXn6I3vFgm+HaTQ+ZaDcB/dfMk= MIME-Version: 1.0 Received: by 10.224.28.207 with SMTP id n15mr1410850qac.87.1234453287872; Thu, 12 Feb 2009 07:41:27 -0800 (PST) In-Reply-To: References: Date: Thu, 12 Feb 2009 15:41:27 +0000 Message-ID: From: Morgaine Dinova To: Catherine Pfeffer Content-Type: multipart/alternative; boundary=0015175cb556b728ef0462ba8de0 Cc: mmox@ietf.org Subject: Re: [mmox] LLSD, VWSD and MMOP X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:41:23 -0000 --0015175cb556b728ef0462ba8de0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 12, 2009 at 2:53 PM, Catherine Pfeffer wrote: > > Indeed, if LL is willing to update LLSD regularly with every new data > type > > that we require, this situation could continue indefinitely, ie. LLSD > always > > defining the low-level bits in an application-agnostic manner. > > Ah OK, now I understand what you meant. > > I'm quite confident that, with the introduction of more scalar types, > apparition of new species (Hi, Darwin!) of data types would stop there. > After all, Second Life works rather well currently with the reduced set of > data types that is currently in LLSD. > > And even if more data types appear to be necessary later on (hum, like a > date and time elementary format), there's nothing wrong with going back > to xxSD draft and adding provision for the missing data type. As long as it > is a draft, nothing is engraved into stone and it is okay that xxSD and > whatever is built on top of it enrich themselves mutually. > > But what you propose is okay too. It's just a different way of organizing > the standard. Personally I prefer something a bit simpler, like the current > draft, that's all. > Well I was just trying to find a way for us to move forward. LLSD is in production use in Second Life, so LL wants to keep its name on LLSD and to be in control of the LLSD spec, which is natural. Unfortunately, we in MMOX need the flexibility to modify our foundational ADT, which we cannot do if LL controls it. So I was trying to find a happy medium in which LL can still control their RFC spec (not a MMOX standard) while we put everything that deviates from it into VWSD. It's not ideal, but I was just trying to live within the current situation. Fortunately that separation is quite nice (and can be justified as a technical decision) if VWSD contains only the mappings from VW data to LLSD data. Morgaine. --0015175cb556b728ef0462ba8de0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Feb 12, 2009 at 2:53 PM, Catherine Pfeffer <cathypfeffer@gmail.com> wrote:
> Indeed, if LL is willing to update LLSD regularly with every new data = type
> that we require, this situation could continue indefinitely, i= e. LLSD always
> defining the low-level bits in an application-agnost= ic manner.

Ah OK, now I understand what you meant.

I'm quite confident = that, with the introduction of more scalar types, apparition of new species= (Hi, Darwin!) of data types would stop there. After all, Second Life works= rather well currently with the reduced set of data types that is currently= in LLSD.

And even if more data types appear to be necessary later on (hum, like = a date and time elementary format), there's nothing wrong with going ba= ck
to xxSD draft and adding provision for the missing data type. As long= as it is a draft, nothing is engraved into stone and it is okay that xxSD = and whatever is built on top of it enrich themselves mutually.

But what you propose is okay too. It's just a different way of orga= nizing the standard. Personally I prefer something a bit simpler, like the = current draft, that's all.


Well I was just trying to find a way for us to move forward.
LLSD is in production use in Second Life, so LL wants to keep its nam= e on LLSD and to be in control of the LLSD spec, which is natural.  Un= fortunately, we in MMOX need the flexibility to modify our foundational ADT= , which we cannot do if LL controls it.  So I was trying to find a hap= py medium in which LL can still control their RFC spec (not a MMOX standard= ) while we put everything that deviates from it into VWSD.

It's not ideal, but I was just trying to live within the current si= tuation.

Fortunately that separation is quite nice (and can be justi= fied as a technical decision) if VWSD contains only the mappings from VW da= ta to LLSD data.


Morgaine.
--0015175cb556b728ef0462ba8de0-- From jwatte@gmail.com Thu Feb 12 11:39:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA5928C157 for ; Thu, 12 Feb 2009 11:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+yvBqHMCpfu for ; Thu, 12 Feb 2009 11:39:14 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 46CE73A6B94 for ; Thu, 12 Feb 2009 11:39:14 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so1082224ywh.49 for ; Thu, 12 Feb 2009 11:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=buQZIFNdZEW5nYA1r8nQq/lakZGaz0lhp22cHcGrHgc=; b=tgV8GvKKhJKOe1qmxUuvckZw8ijYgix7ScRdO2Kn0J7snVAe5SdPHeVpDIdAbiTPot Vv2Bz0qooY3sXtd3qctR8OhswyGJkh4ddP0Vymz50K/NYAAojMOY16U7/PWrRdVndxxs iV6INRjQdK0Nbd72hfKjQhpHT3tWX/OjOBNXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=YCnV2F4Jn3x8qwciF9SHUx94+IpJoHje2uGmFDd05GFgeIwQfUsqzcoO62A6o5roOZ f1bqKK9BZUaRtTu/GMeFXGESqNQi+62Fq5WtXL5eTnsQ23myZhPJrOITKwqhwYKtGFh4 nmr0nGWJ/5oIy1+w20XG70cW2K2qMJaQymo8M= Received: by 10.100.164.12 with SMTP id m12mr1535022ane.144.1234467558899; Thu, 12 Feb 2009 11:39:18 -0800 (PST) Received: from ?192.168.168.106? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c28sm587565anc.25.2009.02.12.11.39.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Feb 2009 11:39:17 -0800 (PST) Message-ID: <49947AE3.9020504@gmail.com> Date: Thu, 12 Feb 2009 11:39:15 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mmox@ietf.org References: <49931BAA.10109@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 19:39:15 -0000 Morgaine Dinova wrote: > Unless the MMOX protocols are intended to carry EVERYTHING related to > VWs (and they well might, though I doubt it), we really need to > partition the universe of discourse into those things that we intend > to cover and those things that we don't. A list of inclusions and > exclusions (if any) would be very useful to direct the discussion ahead. I don't even yet understand what mode of interoperability you're tackling here. For example, there's the "universal client" ghost, which doesn't actually solve any real business problems. Then there's the "porting content" area, where we're seeing a lot of demand from customers. There's also "tieing servers together" which actually enables new and interesting, never-before-seen applications. For an argument for why a "universal client" is a non-solution, see http://www.interopworld.com/node/31 For a description of what "tieing server together" might enable, see http://www.interopworld.com/node/22 So, before we start talking too much about specific details of serializing data, I think it would be great if we first figured out what kinds of new applications we're trying to enable through interoperability. Sincerely, jw From lenglish5@cox.net Thu Feb 12 14:09:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AA393A672F for ; Thu, 12 Feb 2009 14:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zS+JDj5zZps6 for ; Thu, 12 Feb 2009 14:09:16 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 64E883A6B2E for ; Thu, 12 Feb 2009 14:09:16 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090212220920.FJHH131.fed1rmmtao107.cox.net@fed1rmimpo03.cox.net>; Thu, 12 Feb 2009 17:09:20 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id FA9K1b00Y4N6T0Q04A9LUP; Thu, 12 Feb 2009 17:09:20 -0500 X-Authority-Analysis: v=1.0 c=1 a=3HaRd9e9D8cA:10 a=6_kJvGWQ5rYA:10 a=Wajolswj7cQA:10 a=q-rQxIYZAAAA:8 a=48vgC7mUAAAA:8 a=SxT4F4qNKmcuunVmWmwA:9 a=-U7yBSitD2GyeFxO4IQA:7 a=ZIvde7lhH34ivkTE828uQAjAWEkA:4 a=lZB815dzVvQA:10 a=oltX7JrCFroA:10 X-CM-Score: 0.00 Message-ID: <49949E0F.6060207@cox.net> Date: Thu, 12 Feb 2009 15:09:19 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> In-Reply-To: <49947AE3.9020504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 22:09:17 -0000 A fully universal client would be, as you put it, impossible, if for no other reason than proprietary innnovation would preclude an open source version, but that doesn't mean we can't work on a reasonably robust lowest common denominator of some kind that will handle most cases. Look at what the people from realXtend have managed to do with the GPL Second Life client, even given its legacy [non] design. L Jon Watte wrote: > Morgaine Dinova wrote: >> Unless the MMOX protocols are intended to carry EVERYTHING related to >> VWs (and they well might, though I doubt it), we really need to >> partition the universe of discourse into those things that we intend >> to cover and those things that we don't. A list of inclusions and >> exclusions (if any) would be very useful to direct the discussion ahead. > > I don't even yet understand what mode of interoperability you're > tackling here. For example, there's the "universal client" ghost, > which doesn't actually solve any real business problems. Then there's > the "porting content" area, where we're seeing a lot of demand from > customers. There's also "tieing servers together" which actually > enables new and interesting, never-before-seen applications. > > For an argument for why a "universal client" is a non-solution, see > http://www.interopworld.com/node/31 > For a description of what "tieing server together" might enable, see > http://www.interopworld.com/node/22 > > So, before we start talking too much about specific details of > serializing data, I think it would be great if we first figured out > what kinds of new applications we're trying to enable through > interoperability. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From jwatte@gmail.com Thu Feb 12 15:22:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE2928C264 for ; Thu, 12 Feb 2009 15:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfzEEVUAfpc4 for ; Thu, 12 Feb 2009 15:22:23 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id BE00328C232 for ; Thu, 12 Feb 2009 15:22:22 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so757444ana.4 for ; Thu, 12 Feb 2009 15:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=C36TBjr4RZGjHHM2r5PgcmcflQdYoqpl2EGEvrzCeaQ=; b=eilnGVIc1cm+D4b9EgERlpIHF3zt2bVsSC9WwV+o0NROULQDzQV8bwV4tWMfdjFPBn PiPGN1T9MZYQdfP4+lwysxRR9Cx7RlsU+HquIdaBIGOu6d9/LuNIsD6jcel8KRUchFVJ /wu9AHD1OwTtdGAsEJGbBHpfuJNtmHLthgoCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Pf4zaUH9syfnnPrGyS0mrgy3F24xB/pvlkDV20ZKW50ZWVeXJrx6j/R7WONJNAkE0F b/2X8t5Um30Z05DfgPp14EnqTpdf+GW4ehAJimQLgOH3I2PDXjhpH9lO9mlTMu9ZTz7j bhtaR/27C9lCWpmfBPVdpGsLT0eS51ENAzsnw= Received: by 10.100.32.6 with SMTP id f6mr1967729anf.90.1234480947607; Thu, 12 Feb 2009 15:22:27 -0800 (PST) Received: from ?192.168.168.106? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d22sm913264and.7.2009.02.12.15.22.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Feb 2009 15:22:26 -0800 (PST) Message-ID: <4994AF30.1050005@gmail.com> Date: Thu, 12 Feb 2009 15:22:24 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> <49949E0F.6060207@cox.net> In-Reply-To: <49949E0F.6060207@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 23:22:23 -0000 Lawson English wrote: > A fully universal client would be, as you put it, impossible, if for > no other reason than proprietary innnovation would preclude an open > source version, but that doesn't mean we can't work on a reasonably > robust lowest common denominator of some kind that will handle most > cases. Look at what the people from realXtend have managed to do with > the GPL Second Life client, even given its legacy [non] design. I believe that argument misses the point: A universal client is almost value-less to a typical user. The only problem a universal client woudl solve is having to install two separate binaries on the hard disk. If you play both WoW and Counterstrike, how much would it be worth to you to be able to keep one binary on the hard disk instead of two? (Note that the assets, which are the majority of the size, still need to be separate) My estimation is "not more than a few cents," and certainly not worth spending any actual time on anytime soon. A universal client doesn't actually enable any new applications. A new application is to have virtual world A and virtual world B collaborate, so that users in one see users/objects/interactions in the other, and vice versa. A universal client doesn't do that at all, because it would have to treat two different virtual worlds as separate walled gardens. The whole point of interoperability, to me, is to tear down those walls. It shouldn't matter if you, personally, use Qwaq Web Forums, Active Worlds, OLIVE, Second Life, Open Sim, Proton Media, Blue Mars, Kaneva, Multiverse, Areae or one of the many other virtual worlds on the market that solve different problems. You should still be able to "go visit" with some of your friends in some shared space, with friends who use some other platform. Once you apply that concept to real activities (city planning, emergency management, corporate meetings, etc) you have something truly powerful and worthwhile -- similar to long distance telephones being able to call between different phone company customers, using switching equipment purchased from different vendors. Note that, once you have that working, you don't even need a universal client, because you can go visit any world through the system you're using (you're most comfortable with, or your enterprise has standardized on, or whatever). Compare with Lotus Notes, Microsoft Exchange, Sendmail and other mail solutions. They don't use the same client/server protocol for the clients, but they interoperate just fine! So, again, let's back up to a higher level: /Is the goal to make sure that different virtual worlds, from different vendors, can meaningfully interoperate?/ If so, the particular data marshaling solution chosen for the lowest level of some of the protocols involved is a fairly insignificant part compared to the whole scope of what needs to be done. For example, I would assume that geometry and animation interop happens through some already existing, well-defined open standard, such as COLLADA or X3D, rather than some arbitrary binary format, either new or vendor-specific. Those open formats aren't tied to LLSD (or any other serialization library) at all, and probably represent the largest amount of data that needs to be exchanged, except for terrain. Sincerely, jw From dahliatrimble@gmail.com Thu Feb 12 16:27:53 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5003A680C for ; Thu, 12 Feb 2009 16:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u99ozHMaS6Gl for ; Thu, 12 Feb 2009 16:27:52 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id AF0D83A68F9 for ; Thu, 12 Feb 2009 16:27:52 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1021679wfd.31 for ; Thu, 12 Feb 2009 16:27:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=OFDB/L0ZDLlvSRsPvvkXdee9surTNvU67CDdu0UZbVE=; b=QCmpBr9k4/xiDkJbT5URZlmeO5Vg0q0MA1F3rICzPZx+fT2BSpHahNWMzCn9jI2XAh g8xn2Pirv9MehI8OeoeE1g0rijK2mjJ4UmfCjYfkHDP2ZCKpEz+hAW2IteDiLJm1E64O bjdbkYr5E4pUG3OCC4pNtSssTItaaodYYxJ/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=lDvE63pC0/gHiZ4SnH7WtW1iuJNvMZ3Yl8eGASnYSbF+vhTQpWdy/K5p7avrI4D2rL qd108FpoMkVC6mhZPPJVd5hLkITlGszVp+f0zMqszjcYt1krYOcOKYnIWRdDgeecYh+7 eO5zLGcKfgh8A3dSCV/K0LAQFEp5XvKpaz+dg= MIME-Version: 1.0 Received: by 10.142.43.7 with SMTP id q7mr689619wfq.155.1234484878657; Thu, 12 Feb 2009 16:27:58 -0800 (PST) In-Reply-To: <4994AF30.1050005@gmail.com> References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> <49949E0F.6060207@cox.net> <4994AF30.1050005@gmail.com> Date: Thu, 12 Feb 2009 16:27:58 -0800 Message-ID: From: Dahlia Trimble To: "mmox@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd30470ac4b0c0462c1e8cb Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 00:27:54 -0000 --000e0cd30470ac4b0c0462c1e8cb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think Collada is intended as a way to connect design tools together in a content creation workflow and is not really meant to be a wire protocol for end-user mass distribution of content, such as may occur between a virtual reality simulation between servers and clients. Collada is not designed for efficiency of asset size. On Thu, Feb 12, 2009 at 3:22 PM, Jon Watte wrote: > Lawson English wrote: > >> A fully universal client would be, as you put it, impossible, if for no >> other reason than proprietary innnovation would preclude an open source >> version, but that doesn't mean we can't work on a reasonably robust lowest >> common denominator of some kind that will handle most cases. Look at what >> the people from realXtend have managed to do with the GPL Second Life >> client, even given its legacy [non] design. >> > > I believe that argument misses the point: A universal client is almost > value-less to a typical user. The only problem a universal client woudl > solve is having to install two separate binaries on the hard disk. If you > play both WoW and Counterstrike, how much would it be worth to you to be > able to keep one binary on the hard disk instead of two? (Note that the > assets, which are the majority of the size, still need to be separate) My > estimation is "not more than a few cents," and certainly not worth spending > any actual time on anytime soon. > > A universal client doesn't actually enable any new applications. > > A new application is to have virtual world A and virtual world B > collaborate, so that users in one see users/objects/interactions in the > other, and vice versa. A universal client doesn't do that at all, because it > would have to treat two different virtual worlds as separate walled gardens. > The whole point of interoperability, to me, is to tear down those walls. It > shouldn't matter if you, personally, use Qwaq Web Forums, Active Worlds, > OLIVE, Second Life, Open Sim, Proton Media, Blue Mars, Kaneva, Multiverse, > Areae or one of the many other virtual worlds on the market that solve > different problems. You should still be able to "go visit" with some of your > friends in some shared space, with friends who use some other platform. Once > you apply that concept to real activities (city planning, emergency > management, corporate meetings, etc) you have something truly powerful and > worthwhile -- similar to long distance telephones being able to call between > different phone company customers, using switching equipment purchased from > different vendors. > > Note that, once you have that working, you don't even need a universal > client, because you can go visit any world through the system you're using > (you're most comfortable with, or your enterprise has standardized on, or > whatever). Compare with Lotus Notes, Microsoft Exchange, Sendmail and other > mail solutions. They don't use the same client/server protocol for the > clients, but they interoperate just fine! > > So, again, let's back up to a higher level: > /Is the goal to make sure that different virtual worlds, from different > vendors, can meaningfully interoperate?/ > If so, the particular data marshaling solution chosen for the lowest level > of some of the protocols involved is a fairly insignificant part compared to > the whole scope of what needs to be done. > > For example, I would assume that geometry and animation interop happens > through some already existing, well-defined open standard, such as COLLADA > or X3D, rather than some arbitrary binary format, either new or > vendor-specific. Those open formats aren't tied to LLSD (or any other > serialization library) at all, and probably represent the largest amount of > data that needs to be exchanged, except for terrain. > > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --000e0cd30470ac4b0c0462c1e8cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think Collada is intended as a way to connect design tools together in a = content creation workflow and is not really meant to be a wire protocol for= end-user mass distribution of content, such as may occur between a virtual= reality simulation between servers and clients. Collada is not designed fo= r efficiency of asset size. 

On Thu, Feb 12, 2009 at 3:22 PM, Jon Watte <= span dir=3D"ltr"><jwatte@gmail.com> wrote:
Lawson English wrote:
A fully universal client would be, as you put it, impossible, if for no oth= er reason than proprietary innnovation would preclude an open source versio= n, but that doesn't mean we can't work on a reasonably robust lowes= t common denominator of some kind that will handle most cases. Look at what= the people from realXtend have managed to do with the GPL Second Life clie= nt, even given its legacy [non] design.

I believe that argument misses the point: A universal client is almost valu= e-less to a typical user. The only problem a universal client woudl solve i= s having to install two separate binaries on the hard disk. If you play bot= h WoW and Counterstrike, how much would it be worth to you to be able to ke= ep one binary on the hard disk instead of two? (Note that the assets, which= are the majority of the size, still need to be separate) My estimation is = "not more than a few cents," and certainly not worth spending any= actual time on anytime soon.

A universal client doesn't actually enable any new applications.

A new application is to have virtual world A and virtual world B collaborat= e, so that users in one see users/objects/interactions in the other, and vi= ce versa. A universal client doesn't do that at all, because it would h= ave to treat two different virtual worlds as separate walled gardens. The w= hole point of interoperability, to me, is to tear down those walls. It shou= ldn't matter if you, personally, use Qwaq Web Forums, Active Worlds, OL= IVE, Second Life, Open Sim, Proton Media, Blue Mars, Kaneva, Multiverse, Ar= eae or one of the many other virtual worlds on the market that solve differ= ent problems. You should still be able to "go visit" with some of= your friends in some shared space, with friends who use some other platfor= m. Once you apply that concept to real activities (city planning, emergency= management, corporate meetings, etc) you have something truly powerful and= worthwhile -- similar to long distance telephones being able to call betwe= en different phone company customers, using switching equipment purchased f= rom different vendors.

Note that, once you have that working, you don't even need a universal = client, because you can go visit any world through the system you're us= ing (you're most comfortable with, or your enterprise has standardized = on, or whatever). Compare with Lotus Notes, Microsoft Exchange, Sendmail an= d other mail solutions. They don't use the same client/server protocol = for the clients, but they interoperate just fine!

So, again, let's back up to a higher level:
/Is the goal to make sure that different virtual worlds, from different ven= dors, can meaningfully interoperate?/
If so, the particular data marshaling solution chosen for the lowest level = of some of the protocols involved is a fairly insignificant part compared t= o the whole scope of what needs to be done.

For example, I would assume that geometry and animation interop happens thr= ough some already existing, well-defined open standard, such as COLLADA or = X3D, rather than some arbitrary binary format, either new or vendor-specifi= c. Those open formats aren't tied to LLSD (or any other serialization l= ibrary) at all, and probably represent the largest amount of data that need= s to be exchanged, except for terrain.

--000e0cd30470ac4b0c0462c1e8cb-- From jwatte@gmail.com Thu Feb 12 20:35:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866383A6910 for ; Thu, 12 Feb 2009 20:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOn2fdcMHtFV for ; Thu, 12 Feb 2009 20:35:12 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id AE3FF3A682D for ; Thu, 12 Feb 2009 20:35:12 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1129113wfd.31 for ; Thu, 12 Feb 2009 20:35:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ub50KHcTfKqOgdIxP3OFwlkvHCGrm/T1BBePQbdso/U=; b=m8otuvwEN3AVQ9PA0w9ZAJKl3mjdz/Q9AxScivSL83a2m0Zn7WbiMBy0kg/qSisryA ZZUEeW/xYvCGbc5iHyKREMgJW3HjvdTmMG92/0DfKymAHH8EZftsDfEiB9HoKDpTcxie yRfh3NfCQDjYHGTyGaJTR3gZvFrNTfFn3AKzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=AIWhC+H/hrWo8GMYCVehgODb6vozbfydpCcvveK9j65QuAkEP5kPhpuBO5fq+HmFeu sQMvAkFMS+1+gcSsHgxnBhFqxFtlsSLNfo2KND0XPn04tDqkYOoZ0N/9ZcZLMf1Rqwox cJs5pteXnVa8r1p0ofwwMBjXXWTmDh+/z5DaI= Received: by 10.142.72.4 with SMTP id u4mr769348wfa.216.1234499718960; Thu, 12 Feb 2009 20:35:18 -0800 (PST) Received: from ?192.168.0.11? (c-67-180-103-175.hsd1.ca.comcast.net [67.180.103.175]) by mx.google.com with ESMTPS id 22sm1770632wfi.41.2009.02.12.20.35.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Feb 2009 20:35:16 -0800 (PST) Message-ID: <4994F883.8060703@gmail.com> Date: Thu, 12 Feb 2009 20:35:15 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dahlia Trimble References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> <49949E0F.6060207@cox.net> <4994AF30.1050005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 04:35:13 -0000 Dahlia Trimble wrote: > I think Collada is intended as a way to connect design tools together > in a content creation workflow and is not really meant to be a wire > protocol for end-user mass distribution of content, such as may occur > between a virtual reality simulation between servers and clients. > Collada is not designed for efficiency of asset size. Are you saying that using an established public standard is not desirable, or do you have a specific problem with COLLADA? Compare to X3D or MPEG-4 meshes, say? (which have a binary representation, and are designed explicitly for virtual worlds) I think COLLADA may actually win out for pragmatic reasons, though. It has excellent tools support compared to most other formats, and a number of large content repositories (including the Google Warehouse) are available in COLLADA (that's what's on the inside of the kmz files). Given that the kmz files are compressed, the size is not orders of magnitude bigger than what you would see with a custom format anyway. If you want a really compressed, custom, binary format, that is still a well-defined standard, then take a look at the MPEG-4 mesh and avatar standards. They are also well defined standards, since many years back, and there exist people who implement it, but personally I think it's the least well supported of the three open standards (COLLADA being tops, followed by X3D, followed by MPEG-4). Sincerely, jw From morgaine.dinova@googlemail.com Thu Feb 12 22:45:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F293A6BE9 for ; Thu, 12 Feb 2009 22:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsWYVEIsrhVK for ; Thu, 12 Feb 2009 22:45:51 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 510233A6BE6 for ; Thu, 12 Feb 2009 22:45:51 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so391148qwe.31 for ; Thu, 12 Feb 2009 22:45:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vbMuWSNtZRbAYpUde0aInSSpERK/74LCxn9G6dSfD+w=; b=NjWgkOnMkgXzmN1E5b24KXyFfigfFklJGQxlF02MgtdQfpcHLMoSzrhSKGBGQ4xCEo VY3TOunovYln493fT80riFNF9zGy8wulKtN0jCAt64UzTutdXvTv9N8v1qcFVqs0juLe PfTZYfMlRbCG3NvBC6rs1cnSZp374Uc6kip4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lpb3rTC4OfO1F7wvZx7BRieidZ+S01SsS0npBZHBvSHngoVyf/tA91PmCbvqlGToKV jaoifGdnH/UWSvRGmfSMJ75xBoBuOxoK6ep8VYaaPSPOxNQZLvCkcQXHe1iLHWgWzYLn Y/GfXmxgChM+HYUUbXqCoFg8RVnxTW/xdzjP4= MIME-Version: 1.0 Received: by 10.224.15.10 with SMTP id i10mr1859773qaa.6.1234507556044; Thu, 12 Feb 2009 22:45:56 -0800 (PST) In-Reply-To: <49947AE3.9020504@gmail.com> References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> Date: Fri, 13 Feb 2009 06:45:55 +0000 Message-ID: From: Morgaine Dinova To: Jon Watte Content-Type: multipart/alternative; boundary=0015175cbb1e59be650462c73076 Cc: mmox@ietf.org Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 06:45:52 -0000 --0015175cbb1e59be650462c73076 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 12, 2009 at 7:39 PM, Jon Watte wrote: > I don't even yet understand what mode of interoperability you're tackling > here. For example, there's the "universal client" ghost, which doesn't > actually solve any real business problems. Then there's the "porting > content" area, where we're seeing a lot of demand from customers. There's > also "tieing servers together" which actually enables new and interesting, > never-before-seen applications. > Jon, we've been discussing interoperability goals and designs in the Architecture Working Group (AWG), a technical group hosted within the Second Life world, for 16 months now, and many of us a lot longer. The AWG was founded with the dual goals of addressing broad interoperability and also the high scalability needs that come naturally with interoperating worlds. If you had been part of that process, the premise and goals would hopefully be clear. This of course can be remedied. One of our tasks in MMOX should probably be to make readily available adequate background information to help answer such questions, since they will be asked frequently. This information forms the premise for our work, and therefore we have to describe it effectively. In a nutshell though, our interoperability goals are as minimally prescriptive as possible, because different worlds will differ markedly in both philosophy and implementation, and therefore it is simply not possible to impose anything amounting to a straightjacket. It would not be accepted, and quite possibly it would not be viable to implement either. Therefore our overall goal is a lightweight one that can embrace diversity. In my own words and very much off the cuff, we are defining a protocol that allows entirely different virtual worlds to access and exchange data objects that are meaningful across a large spectrum of world types. This is achieved by limiting the protocol to common concepts such as login (for identity), location, teleport, travel, avatars, and messaging, as well as offering an extensible set of common 3D objects as building blocks that can be exchanged. It is a strongly abstracted approach, as independent of actual implementation details as we can make it, because there is no other way to embrace the current diversity of worlds let alone the future one. This will not have answered your question to any useful extent, but I hope that you'll see why and where we're going and the fruits of the long process that has led to MMOX in the week to come. Meanwhile, it would indeed help if the primary OGP designers were to enumerate what is included and what is excluded from the design proposal that will be presented as one possible starting point for MMOX consideration. (OGP is the interop protocol and project started by LL+AWG several months ago, of which a very small part is already implemented in Second Life.) Morgaine. --0015175cbb1e59be650462c73076 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 12, 2009 at 7:39 PM, Jon Wat= te <jwatte@gmail.c= om> wrote:
 
I don't even yet understand what mode of interoperability you're ta= ckling here. For example, there's the "universal client" ghos= t, which doesn't actually solve any real business problems. Then there&= #39;s the "porting content" area, where we're seeing a lot of= demand from customers. There's also "tieing servers together"= ; which actually enables new and interesting, never-before-seen application= s.

Jon, we've been discussing interoperability goals= and designs in the Architecture Working Group (AWG), a technical group hos= ted within the Second Life world, for 16 months now, and many of us a lot l= onger.  The AWG was founded with the dual goals of addressing broad in= teroperability and also the high scalability needs that come naturally with= interoperating worlds.  If you had been part of that process, the pre= mise and goals would hopefully be clear.

This of course can be remedied.  One of our tasks in MMOX should p= robably be to make readily available adequate background information to hel= p answer such questions, since they will be asked frequently.  This in= formation forms the premise for our work, and therefore we have to describe= it effectively.

In a nutshell though, our interoperability goals are as minimally presc= riptive as possible, because different worlds will differ markedly in both = philosophy and implementation, and therefore it is simply not possible to i= mpose anything amounting to a straightjacket.  It would not be accepte= d, and quite possibly it would not be viable to implement either.  The= refore our overall goal is a lightweight one that can embrace diversity.
In my own words and very much off the cuff, we are defining a protocol = that allows entirely different virtual worlds to access and exchange data o= bjects that are meaningful across a large spectrum of world types.  Th= is is achieved by limiting the protocol to common concepts such as login (f= or identity), location, teleport, travel, avatars, and messaging, as well a= s offering an extensible set of common 3D objects as building blocks that c= an be exchanged.  It is a strongly abstracted approach, as independent= of actual implementation details as we can make it, because there is no ot= her way to embrace the current diversity of worlds let alone the future one= .

This will not have answered your question to any useful extent, but I h= ope that you'll see why and where we're going and the fruits of the= long process that has led to MMOX in the week to come.

Meanwhile, i= t would indeed help if the primary OGP designers were to enumerate what is = included and what is excluded from the design proposal that will be present= ed as one possible starting point for MMOX consideration.  (OGP is the= interop protocol and project started by LL+AWG several months ago, of whic= h a very small part is already implemented in Second Life.)


Morgaine.

--0015175cbb1e59be650462c73076-- From dahliatrimble@gmail.com Fri Feb 13 00:36:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6353A67C0 for ; Fri, 13 Feb 2009 00:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P83nq7O5ZfR8 for ; Fri, 13 Feb 2009 00:36:32 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 6076428C121 for ; Fri, 13 Feb 2009 00:36:32 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so574648rvb.49 for ; Fri, 13 Feb 2009 00:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=M+VKOef4j6gLGJvRo9b5g+KLZqBDesLH41MTU239HEM=; b=WNIsvvXtT1uS6tb5FzjXbGwPrTviBGNtopLnSDwtYGHsrFD0NdJRY8sm+ad3to0gPE /gOV7wCT4pU+krGlGOcZ0r9FhuaFPa6QdRIPoDuBE794jU9FYRGI3zHCJlfK6gvJr0V4 KzSuBzDEJn8M5mL0603OaZOVr+/x3imlvz5S0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G09TJn5BIxYSa2HZ/vqtlEcD7MvTaEjmrV5EM2YrRgjHHaFjP7ratCHexa0ReaYkiz elj4BtIwvqCaiIFzWAPeSI22yP6H/zUrmn8JnP966WxRUvv/XqWNzwqizsYIgqytDWjw wBDWsC9IIYm0x3u0JwK8hbNSXswKsTwQ/v+fw= MIME-Version: 1.0 Received: by 10.142.214.11 with SMTP id m11mr847655wfg.183.1234514198104; Fri, 13 Feb 2009 00:36:38 -0800 (PST) In-Reply-To: <4994F883.8060703@gmail.com> References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> <49949E0F.6060207@cox.net> <4994AF30.1050005@gmail.com> <4994F883.8060703@gmail.com> Date: Fri, 13 Feb 2009 00:36:38 -0800 Message-ID: From: Dahlia Trimble To: Jon Watte Content-Type: multipart/alternative; boundary=000e0cd2e61c3f8c810462c8bc20 Cc: "mmox@ietf.org" Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 08:36:33 -0000 --000e0cd2e61c3f8c810462c8bc20 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have nothing against Collada. Here is a quote from http://www.khronos.org/collada/ "*COLLADA is a XML database schema for 3D assets* COLLADA is an intermediate language - not a delivery format and not a scene graph" On Thu, Feb 12, 2009 at 8:35 PM, Jon Watte wrote: > Dahlia Trimble wrote: > >> I think Collada is intended as a way to connect design tools together in a >> content creation workflow and is not really meant to be a wire protocol for >> end-user mass distribution of content, such as may occur between a virtual >> reality simulation between servers and clients. Collada is not designed for >> efficiency of asset size. >> > > Are you saying that using an established public standard is not desirable, > or do you have a specific problem with COLLADA? Compare to X3D or MPEG-4 > meshes, say? (which have a binary representation, and are designed > explicitly for virtual worlds) > > I think COLLADA may actually win out for pragmatic reasons, though. It has > excellent tools support compared to most other formats, and a number of > large content repositories (including the Google Warehouse) are available in > COLLADA (that's what's on the inside of the kmz files). Given that the kmz > files are compressed, the size is not orders of magnitude bigger than what > you would see with a custom format anyway. > > If you want a really compressed, custom, binary format, that is still a > well-defined standard, then take a look at the MPEG-4 mesh and avatar > standards. They are also well defined standards, since many years back, and > there exist people who implement it, but personally I think it's the least > well supported of the three open standards (COLLADA being tops, followed by > X3D, followed by MPEG-4). > > Sincerely, > > jw > > --000e0cd2e61c3f8c810462c8bc20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have nothing against Collada. Here is a quote from http://www.khronos.org/collada/

"COLLADA is a XML database = schema for 3D assets 
COLLADA is an intermediate language - not a delivery format and not a scene= graph"

<= span class=3D"Apple-style-span" style=3D"color: rgb(34, 34, 34); font-size:= 12px; line-height: 17px;">

On Thu, Feb 12, 2009 at 8:35 PM, Jon = Watte <jwatte@gmai= l.com> wrote:
Dahlia Trimble wrote:
I think Collada is intended as a way to connect design tools together in a = content creation workflow and is not really meant to be a wire protocol for= end-user mass distribution of content, such as may occur between a virtual= reality simulation between servers and clients. Collada is not designed fo= r efficiency of asset size.

Are you saying that using an established public standard is not desirable, = or do you have a specific problem with COLLADA? Compare to X3D or MPEG-4 me= shes, say? (which have a binary representation, and are designed explicitly= for virtual worlds)

I think COLLADA may actually win out for pragmatic reasons, though. It has = excellent tools support compared to most other formats, and a number of lar= ge content repositories (including the Google Warehouse) are available in C= OLLADA (that's what's on the inside of the kmz files). Given that t= he kmz files are compressed, the size is not orders of magnitude bigger tha= n what you would see with a custom format anyway.

If you want a really compressed, custom, binary format, that is still a wel= l-defined standard, then take a look at the MPEG-4 mesh and avatar standard= s. They are also well defined standards, since many years back, and there e= xist people who implement it, but personally I think it's the least wel= l supported of the three open standards (COLLADA being tops, followed by X3= D, followed by MPEG-4).

Sincerely,

jw


--000e0cd2e61c3f8c810462c8bc20-- From tk@research.att.com Fri Feb 13 04:22:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28E23A6869 for ; Fri, 13 Feb 2009 04:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaqxAnxnz9BB for ; Fri, 13 Feb 2009 04:22:12 -0800 (PST) Received: from mail-yellow.research.att.com (mail-dark.research.att.com [192.20.225.112]) by core3.amsl.com (Postfix) with ESMTP id E9F5F3A6784 for ; Fri, 13 Feb 2009 04:22:11 -0800 (PST) Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.176.254]) by mail-blue.research.att.com (Postfix) with ESMTP id 6DFF1F0FBB for ; Fri, 13 Feb 2009 07:22:18 -0500 (EST) Received: from fabrik.research.att.com (fabrik.client.research.att.com [135.207.174.197]) by unixmail.research.att.com (8.13.7+Sun/8.13.7) with ESMTP id n1DCMI4t012150; Fri, 13 Feb 2009 07:22:18 -0500 (EST) Received: by fabrik.research.att.com (Postfix, from userid 58282) id 18315A33827; Fri, 13 Feb 2009 07:22:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18837.26104.857554.366250@fabrik.client.research.att.com> Date: Fri, 13 Feb 2009 07:22:16 -0500 From: thomas kirk To: mmox@ietf.org In-Reply-To: <4994AF30.1050005@gmail.com> References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> <49949E0F.6060207@cox.net> <4994AF30.1050005@gmail.com> X-Mailer: VM 7.19 under Emacs 22.1.50.5 Subject: [mmox] interoperability goals X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tk@research.att.com List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 12:22:12 -0000 the suggestion from Jon Watte to pop up to a higher level of discussion is a good one -- seems worthwhile to start off with some common understanding of what interoperability means. Long-time AWG members undoubtedly have particular notions of interoperability, so that's probably a good starting point, but the rest of us are missing that context, and laying out a clear high-level roadmap would make the overall objectives more accessible to other communities who may wish to be involved with this work (or at least be aware of it). From suzyque@gmail.com Fri Feb 13 05:43:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516063A6B49 for ; Fri, 13 Feb 2009 05:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LImMbaC7rkvl for ; Fri, 13 Feb 2009 05:43:52 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 983293A6B3A for ; Fri, 13 Feb 2009 05:43:52 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so428196qwe.31 for ; Fri, 13 Feb 2009 05:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1R3TgDUqyFbNtWDHXba4cpnTTc4hVTpj/myY1Hh40Js=; b=N2J40kK+G/80RCKSBor4CJIK3eg+UH/3JjIbegDUmkw2M4M5CFg69kK4yE8jcM2/qj 8uRxQBTQYN4YL+R5gXufyDK6IfMfAI6VHnK9+9yrM5r5Aak9I5waoSJsmfFB9SKptZrC lFRhrJr5CibuM0DUkJqR8yZ6kFuryCttiHCow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Va41kwrFt380yjVq+TbmtvfeaO4yLMNRW4Zwt2TP/4rYYCap7VjBLpFJRKJ4dLN7As a3vMbZVYVfITkpeBr1sDyoS8eV4z59rKwHvLQqDj7VyyGSqkj/eJQUHERZv6FuTxd4XN j7ru62azvhskK8qFqrO+oz5FNNtTJkH9QTDYI= MIME-Version: 1.0 Sender: suzyque@gmail.com Received: by 10.224.89.10 with SMTP id c10mr3242070qam.368.1234532638066; Fri, 13 Feb 2009 05:43:58 -0800 (PST) In-Reply-To: <4994F883.8060703@gmail.com> References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> <49949E0F.6060207@cox.net> <4994AF30.1050005@gmail.com> <4994F883.8060703@gmail.com> Date: Fri, 13 Feb 2009 07:43:58 -0600 X-Google-Sender-Auth: 0092ac74aafa538f Message-ID: <2bd5b7f10902130543w3767fc84h1c5672b2287f3f06@mail.gmail.com> From: Suzy Deffeyes To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , Dahlia Trimble Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: suzyq@pobox.com List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 13:43:57 -0000 On Thu, Feb 12, 2009 at 10:35 PM, Jon Watte wrote: > I think COLLADA may actually win out for pragmatic reasons I also think COLLADA will be popular in this space for interchange, For example, it's already extending beyond its original intended use as a toolchain interchange format for game developers into the CAD space (COLLADA 1.5 brep spec). X3D tends to force an event model on your app, and it has had a tough time overcoming the baggage of being a descendant of VRML. I don't think we'd be able to build consensus in adopting it in MMOX. That said, I think the geometry interchange might not be the first thing the group tackles. (please, as a COLLADA working group member, I'd love it if you prove me wrong!). I think we should look for something small that can be sanely separated and would have a consensus among the wide use cases we want to support. Am I unrealistic? What would that small piece be? Suzy Deffeyes IBM From lenglish5@cox.net Fri Feb 13 12:22:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D8DA3A6C9E for ; Fri, 13 Feb 2009 12:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6b4OKqu+SdO for ; Fri, 13 Feb 2009 12:22:36 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id 625BD3A6C10 for ; Fri, 13 Feb 2009 12:22:33 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090213202213.JKSC12838.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>; Fri, 13 Feb 2009 15:22:13 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id FYNE1b0034N6T0Q03YNEWG; Fri, 13 Feb 2009 15:22:14 -0500 X-Authority-Analysis: v=1.0 c=1 a=3HaRd9e9D8cA:10 a=6_kJvGWQ5rYA:10 a=Wajolswj7cQA:10 a=4u8p1NLJ6dfoKWvI9iEA:9 a=5eLJayOLyRGNOhavsn0A:7 a=9zDSr-VUrfvElDumW7maKPlM5S4A:4 a=MSl-tDqOz04A:10 a=gx5bkW9XiUAA:10 X-CM-Score: 0.00 Message-ID: <4995D676.6010908@cox.net> Date: Fri, 13 Feb 2009 13:22:14 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: suzyq@pobox.com References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> <49949E0F.6060207@cox.net> <4994AF30.1050005@gmail.com> <4994F883.8060703@gmail.com> <2bd5b7f10902130543w3767fc84h1c5672b2287f3f06@mail.gmail.com> In-Reply-To: <2bd5b7f10902130543w3767fc84h1c5672b2287f3f06@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , Dahlia Trimble Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 20:22:37 -0000 Suzy Deffeyes wrote: > On Thu, Feb 12, 2009 at 10:35 PM, Jon Watte wrote: > >> I think COLLADA may actually win out for pragmatic reasons >> > > I also think COLLADA will be popular in this space for interchange, > For example, it's already extending beyond its original intended use > as a toolchain interchange format for game developers into the CAD > space (COLLADA 1.5 brep spec). > > X3D tends to force an event model on your app, and it has had a tough > time overcoming the baggage of being a descendant of VRML. I don't > think we'd be able to build consensus in adopting it in MMOX. > > That said, I think the geometry interchange might not be the first > thing the group tackles. (please, as a COLLADA working group member, > I'd love it if you prove me wrong!). > > I think we should look for something small that can be sanely > separated and would have a consensus among the wide use cases we want > to support. Am I unrealistic? What would that small piece be? > > > Suzy Deffeyes > IBM > _______________________________________________ > Even geometry exchange between "SL-compatible" worlds becomes a sticky issue. Compare realXtend avatars with SL avatars for example... One thing that everyone seems to want in SL is support for generic meshes ala .obj files. This is just the tip of the iceberg for what is needed for interop, of course. One of the biggest issues for Second Life, which few other virtual worlds have to address, is the economic/social/legal issues for intellectual property. There are people who make a real world living designing avatars and clothing for them in Second LIfe. How does one transport such stuff around in a metaverse? The technical details are nothing compared to the social/legal/ethical/etc details and interop protocols have to allow for THAT also. L. From jwatte@gmail.com Fri Feb 13 13:08:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5DC3A689D for ; Fri, 13 Feb 2009 13:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkWdVhCL6See for ; Fri, 13 Feb 2009 13:08:35 -0800 (PST) Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id A36843A6828 for ; Fri, 13 Feb 2009 13:08:35 -0800 (PST) Received: by gxk22 with SMTP id 22so1185260gxk.13 for ; Fri, 13 Feb 2009 13:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8veDCWGyEQz2rVeeKqits9pNDjr5ZkOpdusGvs2h4GE=; b=HRAABObN9cHVFF744QWsJoxwygJvGBY0e5MMJA0GqI3K4BOS+Gx8fCXpEEz1wvFRVB jgdfieB7JBxrbCYq9FPDgm3uIHGz3uaGjKNQuf5U7D9HxsCfxCJa0A1FvcJ/ztrfHsod f+vSWNMqXyqNIEYT4Pr+DXSPxJGVitRQkzVCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=l6yv8xtqIeo28//FZ3hnThDjbCdO6smq8onDwjRGYWUTQ+f68fzfORCfb6xw+xg4vb TxeT2GQDfn1EIL0UhpLiQTmZSXKyqGlz6I2kmItoRqT3YxAPfgND9iGR4rjvX2XLlmf7 Z4LHFP7vqXEuQQ7H1wAy5nf4sfCjC5KDVj16o= Received: by 10.100.5.15 with SMTP id 15mr3636389ane.50.1234559321487; Fri, 13 Feb 2009 13:08:41 -0800 (PST) Received: from ?192.168.168.105? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c9sm3083022ana.13.2009.02.13.13.08.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Feb 2009 13:08:40 -0800 (PST) Message-ID: <4995E156.50803@gmail.com> Date: Fri, 13 Feb 2009 13:08:38 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine Dinova References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 21:08:36 -0000 Morgaine Dinova wrote: > > Jon, we've been discussing interoperability goals and designs in the > Architecture Working Group (AWG), a technical group hosted within the > Second Life world, for 16 months now, and many of us a lot longer. > The AWG was founded with the dual goals of addressing broad > interoperability and also the high scalability needs that come > naturally with interoperating worlds. If you had been part of that > process, the premise and goals would hopefully be clear. > From what I understand, the AWG is Second Life derived technology specific, which is of very low interest to my particular market. The reason I found this BoF interesting was that it claimed to want to take a vendor neutral approach, which I'm all for. (I, too, sit on a code base of several million lines of code, with lots of heavily entrenched users accumulated over the last 10 years -- I wouldn't expect to standardize the internals of that) > In my own words and very much off the cuff, we are defining a protocol > that allows entirely different virtual worlds to access and exchange > data objects that are meaningful across a large spectrum of world > types. This is achieved by limiting the protocol to common concepts > such as login (for identity), location, teleport, travel, avatars, and > messaging, as well as offering an extensible set of common 3D objects > as building blocks that can be exchanged. It is a strongly abstracted > approach, as independent of actual implementation details as we can > make it, because there is no other way to embrace the current > diversity of worlds let alone the future one. That's fine. I believe that things like "terrain" or "avatar" or "interaction" are abstract enough that many different worlds can agree on them. In fact, I have been delivering interoperable virtual worlds to various organizational customers for the last 5 years or so, and a while back I wrote up my experiences from having done that. You probably will find some common ground if you read up on that (so I don't have to re-post all of it to this list, which would be pretty large and annoying): Starting with the use case here: http://www.interopworld.com/members/node/22 I go down one level in what pieces will actually be needed, with strawman examples as illustration: http://www.interopworld.com/vwsis For reference, the by far most successful virtual world interoperability protocol over the last 20 years is DIS (IEEE 1278). Unfortunately, it has a number of problems, such as being highly military specific, and being way too verbose (as it relies on PDUs and UDP broadcast sharing), but I think the success of DIS in bridging very disparate systems into functioning, shared worlds should not be under-estimated! Sincerely, jw From jwatte@gmail.com Fri Feb 13 13:16:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F4EE3A6AB3 for ; Fri, 13 Feb 2009 13:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDIlMqGUCSJ3 for ; Fri, 13 Feb 2009 13:16:56 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 083063A6B3F for ; Fri, 13 Feb 2009 13:16:55 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so1649738ywh.49 for ; Fri, 13 Feb 2009 13:17:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/hIHsPj/2T0p95X1pO2bI9fmoaZ79Xa9Uh64LqaiB1U=; b=cT/jPW21Pb2O8u5kyKlpF6W9UrW39B/BANCeRz/FSWRDwxR/YCGenDP1k3ycZIve0Z 2TZbP3Syx3HpJq/0Me/R2wJXaLRwMOXdQFywY5ZuIdZ9L03tzWPIPy+TXxntvLZ+/0o0 b82k95q09mYYi2nkzVWC1g9PD9975kiW3J+OQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=GVKfqtTcRc1E5U+GC/DREosAKYbzPPPqOM6t8rNkHhLxtIfTcgExobRqzNS7VQ++2E hNZCPMRSZh6zyneV09TnwGm4tC/aII6XEB7lNYDdLOs73+wOaG1XZxyxr7G87HdNDtNA 7CdRR/qfGA1RhBRoSt7jg9YmK1/BWFrIZDqII= Received: by 10.100.3.13 with SMTP id 13mr3381140anc.37.1234559820272; Fri, 13 Feb 2009 13:17:00 -0800 (PST) Received: from ?192.168.168.105? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d35sm1506810and.18.2009.02.13.13.16.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Feb 2009 13:16:59 -0800 (PST) Message-ID: <4995E349.2050100@gmail.com> Date: Fri, 13 Feb 2009 13:16:57 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> <49949E0F.6060207@cox.net> <4994AF30.1050005@gmail.com> <4994F883.8060703@gmail.com> <2bd5b7f10902130543w3767fc84h1c5672b2287f3f06@mail.gmail.com> <4995D676.6010908@cox.net> In-Reply-To: <4995D676.6010908@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , suzyq@pobox.com, Dahlia Trimble Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 21:16:57 -0000 Lawson English wrote: > One of the biggest issues for Second Life, which few other virtual > worlds have to address, is > the economic/social/legal issues for intellectual property. There are > people who make a real world > living designing avatars and clothing for them in Second LIfe. How > does one transport such stuff around > in a metaverse? The technical details are nothing compared to the > social/legal/ethical/etc details > and interop protocols have to allow for THAT also. > I think the There.com people has had some of the same problems for the last 6 years or so, btw. When I asked them how they solved it, they claim to solve it through their content submission screening process, which seems labor intensive to me, but does provide some level of value to their users and developers. However, at the extent, any object that you show to a general user is "open" to that user; he/she can use an asset ripper at one of many levels (including hooking the graphics drivers), so you can't technically prevent criminal intent. However, each particular world has to make a determination on how "far" their content sublicensing rights extend. For example, if I build a sofa, and sell it to you. Then you host a meeting SL where someone from There.com visits, then that sofa needs to be shared to the There.com system, and through that system to the viewing client. You have implicitly already given the viewing client the right to view the object, though, so it's not unreasonable to believe that any router, cache, or other system on the way also has the right to view the object. It seems to me that the important parts to make sure are represented are: 1) Make sure that authorship and sharing rights are carried as metadata with any object 2) Make sure that the policy for caching in different parts of the system take this into account 3) Put requirements that these policies are followed into the standards language After that, there's really nothing that a vendor can do, technically, to prevent users who want to break the law. So, I think it's fine to say that "any interoperability standard must address content metadata, including authorship, ownership and sharing rights," but I don't think that mandating specific technical solutions (like specific DRM solutions) would be fruitful. Sincerely, jw From jwatte@gmail.com Fri Feb 13 14:00:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83EFC3A6A94 for ; Fri, 13 Feb 2009 14:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qNsCiAA0bxP for ; Fri, 13 Feb 2009 14:00:02 -0800 (PST) Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id 5878B3A693B for ; Fri, 13 Feb 2009 14:00:02 -0800 (PST) Received: by gxk22 with SMTP id 22so1237366gxk.13 for ; Fri, 13 Feb 2009 14:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ebn6ditY1/vSCLWFiHCTY1sDR+mo1Z3DwtsC02W46Og=; b=f1t+PNovnvv+oZwEqNxjANRXIdkrIqCRNo9Te3CcJBrd6iAwXvaBjxErksbBNdBQ/1 QmdZ46m6UgWnnf9gHh4jZyPV4tpXximXONVqilQwURUFdqeE8n33sS9guAHgMH7WaFEC /QROwb8gcg11gBcH1yPZgG+/UidjSgI9iClc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=q9DZyTs6KGwByPV7Mp3S3otPl/wAfKpbmAbbGMFEU5PWxHyR0UPzuzbLf7xfbHGYTd Akpf+vKuAtSxP5CG9qfHSCGIkgrIXMCkKktbvRYWjWd1f2C4AEnVfBl0paS4mY6EcZoy 23tdpzsGYqsyfqrSOtKGnNRrjqr0wYV/CtxAI= Received: by 10.100.247.12 with SMTP id u12mr1586344anh.102.1234562408759; Fri, 13 Feb 2009 14:00:08 -0800 (PST) Received: from ?192.168.168.105? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c1sm2536127ana.0.2009.02.13.14.00.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Feb 2009 14:00:07 -0800 (PST) Message-ID: <4995ED65.6020904@gmail.com> Date: Fri, 13 Feb 2009 14:00:05 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine Dinova References: <49931BAA.10109@gmail.com> <49947AE3.9020504@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 22:00:03 -0000 Morgaine Dinova wrote: > the protocol to common concepts such as login (for identity) Hmm. I can't think of a good use case where "login" would make sense for standardization. If I'm logged into Blue Mars, and want to collaborate with someone in Club Penguin (run with me, here, this is an example :-), then I shouldn't have to have an account in Club Penguin to do that. The person I collaborate with should similarly not have to have an account with Blue Mars to interop. The concept of "identity" collapses down to "responsible party" I think. Thus, the entire "Club Penguin" system could be one "responsible party," although sub-identifiers for each user within there would probably be desirable. Thus, an authentication token might look something like: auth-domain : auth-name : expiry-time : auth-cookie (Kerberos, anyone? :-) In this case, "clubpenguin.com" : "My Cool Penguin" : "Tomorrow" : hash(expirytime + name + some secret key) For that, in turn, to make sense, there needs to be a separate back channel where the Blue Mars system can contact the club penguin system and verify that the credentials are indeed valid, and perhaps negotiate information about the credentials (age group for content rating, e-mail address for contact, perhaps in the future negotiated microtransactions, etc). I guess I think "identity" or "responsible party" is a better name for this concept than "login," because "login" has a number of connotations I don't think it shares. And, yes, in some future, certain providers may deem that other providers are un-trust-worthy, and restrict the set of available interactions (possibly down to zero) for certain auth domains. I think that needs to be a supported scenario. Sincerely, jw From infinity@lindenlab.com Fri Feb 13 14:20:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468013A68DF for ; Fri, 13 Feb 2009 14:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yjZALiC-SQb for ; Fri, 13 Feb 2009 14:20:30 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 5380A3A689D for ; Fri, 13 Feb 2009 14:20:30 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id E94EF3DBC07E for ; Fri, 13 Feb 2009 14:20:36 -0800 (PST) Message-Id: <45310FCA-B89E-4348-A7C2-C9AC8F27DF25@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: mmox@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 13 Feb 2009 14:20:36 -0800 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] NOTE WELL X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 22:20:31 -0000 Hey Everyone... Just a friendly reminder... this list is covered by the IETF's IPR disclosure policy described at http://www.ietf.org/NOTEWELL.html . Please read this page and the RFCs it references if you haven't done so already. I remind list members of this policy as several of us are participating using pseudonymous avatar names and that pseudonymous participation does not relieve you of your IPR disclosure responsibility. Also... IETF policy requires that RFCs and Internet Drafts not be attributed to anonymous or pseudonymous authors. -cheers -meadhbh hamrick (aka infinity linden) From dwl@us.ibm.com Fri Feb 13 17:39:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4723A69B8; Fri, 13 Feb 2009 17:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.181 X-Spam-Level: X-Spam-Status: No, score=-4.181 tagged_above=-999 required=5 tests=[AWL=-1.583, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzNK5wyCqB3T; Fri, 13 Feb 2009 17:39:39 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id 1C1433A6A45; Fri, 13 Feb 2009 17:39:36 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1E1WGmj030236; Fri, 13 Feb 2009 20:32:16 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1E1dgHq176172; Fri, 13 Feb 2009 20:39:42 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n1E1dfg0001428; Fri, 13 Feb 2009 20:39:42 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n1E1dfbM001425; Fri, 13 Feb 2009 20:39:41 -0500 In-Reply-To: <4995ED65.6020904@gmail.com> To: Jon Watte MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Fri, 13 Feb 2009 20:39:42 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/13/2009 20:39:41, Serialize complete at 02/13/2009 20:39:41 Content-Type: multipart/alternative; boundary="=_alternative 000920988525755D_=" Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 01:39:40 -0000 This is a multipart message in MIME format. --=_alternative 000920988525755D_= Content-Type: text/plain; charset="US-ASCII" I think this is one way (quite possibly the predominant way) that we will handle "cross domain" issues of identity and authentication. I would add one non-trivial caveat here. We probably can (and should) design things so that decisions such as "I require an explicit login to my local service from the end user" are driven by policy, rather than mechanism. I for one don't care to log in, in various ways, to various systems in order to interact with users on them. At the same time, I can see cases where there will be deployed portions of a greater grid of immersive virtual spaces which do not share mutual trust at the level required to permit a "system mediated cross authentication" Ideally, this can be handled by policy, and people who wish to deploy such systems can share as much or as little trust as they care to. The mechanisms don't change, just the policy. Having said this, I will freely admit the balancing act here. The more you push choices out to policy, the easier it is to create fully compliant implementations which interoperate only in the very most theoretical sense, and end up having to have profiles, or similar mechanisms so you can decide if you can, in fact talk to a compliant services. - David W. Levine ~ Zha Ewry (ISL) Jon Watte Sent by: mmox-bounces@ietf.org 02/13/2009 05:00 PM To Morgaine Dinova cc mmox@ietf.org Subject Re: [mmox] Another proposal for LLSD draft Morgaine Dinova wrote: > the protocol to common concepts such as login (for identity) Hmm. I can't think of a good use case where "login" would make sense for standardization. If I'm logged into Blue Mars, and want to collaborate with someone in Club Penguin (run with me, here, this is an example :-), then I shouldn't have to have an account in Club Penguin to do that. The person I collaborate with should similarly not have to have an account with Blue Mars to interop. The concept of "identity" collapses down to "responsible party" I think. Thus, the entire "Club Penguin" system could be one "responsible party," although sub-identifiers for each user within there would probably be desirable. Thus, an authentication token might look something like: auth-domain : auth-name : expiry-time : auth-cookie (Kerberos, anyone? :-) In this case, "clubpenguin.com" : "My Cool Penguin" : "Tomorrow" : hash(expirytime + name + some secret key) For that, in turn, to make sense, there needs to be a separate back channel where the Blue Mars system can contact the club penguin system and verify that the credentials are indeed valid, and perhaps negotiate information about the credentials (age group for content rating, e-mail address for contact, perhaps in the future negotiated microtransactions, etc). I guess I think "identity" or "responsible party" is a better name for this concept than "login," because "login" has a number of connotations I don't think it shares. And, yes, in some future, certain providers may deem that other providers are un-trust-worthy, and restrict the set of available interactions (possibly down to zero) for certain auth domains. I think that needs to be a supported scenario. Sincerely, jw _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --=_alternative 000920988525755D_= Content-Type: text/html; charset="US-ASCII"
I think this is one way  (quite possibly the predominant way) that we will handle "cross domain" issues of identity and authentication. I would add one non-trivial caveat here. We probably can (and should) design things so that decisions such as "I require an explicit login to my local service from the end user" are driven by policy, rather than mechanism.  I for one don't  care to log in, in various ways, to various systems in order to interact with users on them. At the same time, I can see cases where there will be deployed portions of a greater grid of immersive virtual spaces which do not share mutual trust at the level required to permit a "system mediated cross authentication"  Ideally, this can be handled by policy, and  people who wish to deploy such systems can share as much or as little trust as they care to. The mechanisms don't change, just the policy.

Having said this, I will freely admit the balancing act here. The more you push choices out to policy, the easier it is to create fully compliant implementations which interoperate only in the very most theoretical sense, and end up having to have profiles, or similar mechanisms so you can decide if you can, in fact talk to a compliant services.

- David W. Levine
~ Zha Ewry (ISL)




Jon Watte <jwatte@gmail.com>
Sent by: mmox-bounces@ietf.org

02/13/2009 05:00 PM

To
Morgaine Dinova <morgaine.dinova@googlemail.com>
cc
mmox@ietf.org
Subject
Re: [mmox] Another proposal for LLSD draft





Morgaine Dinova wrote:
> the protocol to common concepts such as login (for identity)

Hmm. I can't think of a good use case where "login" would make sense for
standardization.

If I'm logged into Blue Mars, and want to collaborate with someone in
Club Penguin (run with me, here, this is an example :-), then I
shouldn't have to have an account in Club Penguin to do that. The person
I collaborate with should similarly not have to have an account with
Blue Mars to interop.

The concept of "identity" collapses down to "responsible party" I think.
Thus, the entire "Club Penguin" system could be one "responsible party,"
although sub-identifiers for each user within there would probably be
desirable. Thus, an authentication token might look something like:

auth-domain : auth-name : expiry-time : auth-cookie  (Kerberos, anyone? :-)

In this case,

"clubpenguin.com" : "My Cool Penguin" : "Tomorrow" : hash(expirytime +
name + some secret key)

For that, in turn, to make sense, there needs to be a separate back
channel where the Blue Mars system can contact the club penguin system
and verify that the credentials are indeed valid, and perhaps negotiate
information about the credentials (age group for content rating, e-mail
address for contact, perhaps in the future negotiated microtransactions,
etc).

I guess I think "identity" or "responsible party" is a better name for
this concept than "login," because "login" has a number of connotations
I don't think it shares.

And, yes, in some future, certain providers may deem that other
providers are un-trust-worthy, and restrict the set of available
interactions (possibly down to zero) for certain auth domains. I think
that needs to be a supported scenario.

Sincerely,

jw

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--=_alternative 000920988525755D_=-- From john.hurliman@intel.com Fri Feb 13 19:06:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C2C73A682B for ; Fri, 13 Feb 2009 19:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpYtqrBlfb3p for ; Fri, 13 Feb 2009 19:06:06 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 8063B3A6765 for ; Fri, 13 Feb 2009 19:06:06 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 13 Feb 2009 19:04:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,204,1233561600"; d="scan'208";a="430961542" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by fmsmga002.fm.intel.com with ESMTP; 13 Feb 2009 19:02:18 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Fri, 13 Feb 2009 20:06:13 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Fri, 13 Feb 2009 20:06:11 -0700 Thread-Topic: LLIDL question Thread-Index: AcmOUTCNskV+MunlRTKZJvqkpd/uJw== Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501643FF@rrsmsx506.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mmox] LLIDL question X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 03:06:07 -0000 What is the meaning of this example line in LLIDL? { $: 42 } I don't see the dollar sign explained anywhere in the draft. John From jwatte@gmail.com Fri Feb 13 20:48:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 434363A67EC; Fri, 13 Feb 2009 20:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-MmyzHYCvcB; Fri, 13 Feb 2009 20:48:43 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 75A6E3A67AA; Fri, 13 Feb 2009 20:48:43 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1712337wfd.31 for ; Fri, 13 Feb 2009 20:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hlG6/tUUi28R5UBSXQJboZhrX2wRnz8GcWrtMyFlLAc=; b=OCmz1x0crvYCUBVFaVv6dk04hS2K6M61tmdOSlDDhTKd9ihH9oPdG0lSFDHFRBeMBF 9nbEHYN81tu/tCBWPyMwvbHQN6kwJpm8cp1K0HhfISSRdIn9Y6TS5+JXD/JNhBTNpoMV lYBBDvubj3oBFrj9VFhhCHPj31DRzQLnvpdcA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=CJEiEdo77/sg5oQOLIt2xs9g0as5/C28OYrNYqZaTQ5xyGXNn4dfYU2PdXX0uqznbc Xe0HZE4JUXfMvZbrovzOZxZAgbs2SXYRE8CvEf2OEEj3VDITGuRc1p65wTe/sQEtsdvV 53prr7LURnDchxWS2ZI7kCLL5AXZQyv5DDa8g= Received: by 10.142.84.5 with SMTP id h5mr1259725wfb.81.1234586930609; Fri, 13 Feb 2009 20:48:50 -0800 (PST) Received: from ?192.168.0.11? (c-67-180-103-175.hsd1.ca.comcast.net [67.180.103.175]) by mx.google.com with ESMTPS id 22sm4407881wfd.26.2009.02.13.20.48.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 13 Feb 2009 20:48:50 -0800 (PST) Message-ID: <49964D30.5040603@gmail.com> Date: Fri, 13 Feb 2009 20:48:48 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David W Levine References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Another proposal for LLSD draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 04:48:44 -0000 David W Levine wrote: > > I think this is one way (quite possibly the predominant way) that we > will handle "cross domain" issues of identity and authentication. I > would add one non-trivial caveat here. We probably can (and should) > design things so that decisions such as "I require an explicit login > to my local service from the end user" are driven by policy, rather > than mechanism. I for one don't care Well, what good is interoperability if the user has to create an account on each system he wants to interoperate with? That's a bit like having to get a Verizon phone plan to be able to call someone who has a Verizon cell phone... Anyway, I agree that more than one identity could be carried, and perhaps requested, through the identity channel. You have to be careful that the actual identity token is issued to the user, not the the intermediary, though, to avoid impersonation attacks. Sincerely, jw From morgaine.dinova@googlemail.com Sat Feb 14 05:34:47 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03973A67EA for ; Sat, 14 Feb 2009 05:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id privMInMo3S6 for ; Sat, 14 Feb 2009 05:34:46 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 9C18D3A6895 for ; Sat, 14 Feb 2009 05:34:46 -0800 (PST) Received: by qyk4 with SMTP id 4so2189233qyk.13 for ; Sat, 14 Feb 2009 05:34:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=KfocLVslkUlQYqFdZcBEOV88I0Th+oDC7Nqq5X8TeN8=; b=lTbawkA9WHFqk/9ATeL7qIaU05h79PiH2VrHZNCaD8HObrwDTM/nZs9740Lamm3ksM SdPHKSnqDuKoaOvkCpfMRy2bBy5Yax4QpWQxy78NHeXOYFI8cww8LNee2wA/amOdBSn7 MhUOCb0x/LTwOiNNIrdxfGJyWE4XeQ7pZF5cQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=jdiN+KhQKGepOH3gVDPcHDFlavRgvoF1PVZu7uL2tOTOJvt+WqKo/gBIW6y2YWEEEw sdnPUgsTYOLhnMOgCNfVPqWiWHS7gQPLd/Y/z7N8YURRBW9K3BhnHJVWabYYDeLpyaqK Ploi47y3s415Xzxl5D+gX4yJFoDY5K5mUTSjo= MIME-Version: 1.0 Received: by 10.224.36.202 with SMTP id u10mr106850qad.124.1234618493064; Sat, 14 Feb 2009 05:34:53 -0800 (PST) Date: Sat, 14 Feb 2009 13:34:53 +0000 Message-ID: From: Morgaine Dinova To: MMOX-IETF Content-Type: multipart/alternative; boundary=0015175d6718b6554a0462e104b8 Subject: [mmox] Working towards broad applicability in virtual worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 13:34:47 -0000 --0015175d6718b6554a0462e104b8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It's excellent to see the discussion about graphics interchange formats in progress, because for the first time this takes us beyond the confines of LL+AWG's work on a protocol (OGP) that tended to reflect only those entities available in the Second Life universe. While certainly not by intent, daily contact with a single system tends to narrow one's worldview despite one's best intentions, and might have reduced the goal of broad applicability to the level of lip service. With diversity in our ranks, this is unlikely to happen even by accident, and hopefully IETF oversight will ensure that it cannot happen at all. :-) I expect the process of extension and/or abstraction to happen at many levels of MMOX work. The Agent Domain concept from OGP had already begun to embrace diversity in authentication and trust mechanisms, but needs to go much further. Other parties like realXtend have developed more advanced avatar concepts, and Opensim have pioneered decentralized forms of organization. We will have to find common ground with both of them, and with every other party that desires interoperation and is willing to work on ways to achieve it. Beyond that, achieving the goals expected of an IETF standard will require a strong focus on extensibility and flexibility even when our own systems do not immediately require it. Data interchange of many kinds will need to be considered, not just 3D graphics but also 2D and vector formats, as well as text, animation, sound and other media. World objects will need to embrace hierarchy, and not restrict object composition artificially to just a single level of primitives. World addressing will need to cater not only for human-sized environments but also for micro worlds and galactic ones. And so on. It's great to see that we have started this process already, at least in a small way. :-) Morgaine. --0015175d6718b6554a0462e104b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's excellent to see the discussion about graphics interchange formats= in progress, because for the first time this takes us beyond the confines = of LL+AWG's work on a protocol (OGP) that tended to reflect only those = entities available in the Second Life universe.  While certainly not b= y intent, daily contact with a single system tends to narrow one's worl= dview despite one's best intentions, and might have reduced the goal of= broad applicability to the level of lip service.

With diversity in our ranks, this is unlikely to happen even by acciden= t, and hopefully IETF oversight will ensure that it cannot happen at all. := -)

I expect the process of extension and/or abstraction to happen at= many levels of MMOX work.

The Agent Domain concept from OGP had already begun to embrace diversit= y in authentication and trust mechanisms, but needs to go much further.&nbs= p; Other parties like realXtend have developed more advanced avatar concept= s, and Opensim have pioneered decentralized forms of organization.  We= will have to find common ground with both of them, and with every other pa= rty that desires interoperation and is willing to work on ways to achieve i= t.

Beyond that, achieving the goals expected of an IETF standard will requ= ire a strong focus on extensibility and flexibility even when our own syste= ms do not immediately require it.  Data interchange of many kinds will= need to be considered, not just 3D graphics but also 2D and vector formats= , as well as text, animation, sound and other media.  World objects wi= ll need to embrace hierarchy, and not restrict object composition artificia= lly to just a single level of primitives.  World addressing will need = to cater not only for human-sized environments but also for micro worlds an= d galactic ones.  And so on.

It's great to see that we have started this process already, at lea= st in a small way. :-)

Morgaine.

--0015175d6718b6554a0462e104b8-- From dyerbrookme@juno.com Sat Feb 14 10:28:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A911D3A6B62 for ; Sat, 14 Feb 2009 10:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z4M1RK2MnRm for ; Sat, 14 Feb 2009 10:28:34 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id B77D23A69D0 for ; Sat, 14 Feb 2009 10:28:34 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail08.vgs.untd.com [10.181.12.148]) by smtpout06.vgs.untd.com with SMTP id AABE3QDJ9A7GV24S for (sender ); Sat, 14 Feb 2009 10:27:43 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkND6y2YGMzEDKF2AcM1m2jVg== Received: (from dyerbrookme@juno.com) by webmail08.vgs.untd.com (jqueuemail) id N9DPQUA6; Sat, 14 Feb 2009 10:27:08 PST Received: from [141.157.197.249] by webmail08.vgs.untd.com with HTTP: Sat, 14 Feb 2009 18:26:23 GMT X-Originating-IP: [141.157.197.249] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 14 Feb 2009 18:26:23 GMT To: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090214.132623.14940.0@webmail08.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:2005962647 X-UNTD-Peer-Info: 10.181.12.148|webmail08.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 33 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2009 18:28:35 -0000 Re: >So, I think it's fine to say that "any interoperability standard mu= st address content metadata, including authorship, ownership and sharing= rights," but I don't think that mandating specific technical solutions = (like specific DRM solutions) would be fruitful. Jon, those of us who are merchants and landlords supporting merchants in= Second Life get all this -- it's been explained literally thousands of = times by the technical experts of SL. We all get that if you see it -- a= nd you need to stream it to see it -- you can copy it, one way or anothe= r. That's all abundantly understood. The problem comes with a disagreeme= nt, based on that reality, of what you do next -- throw up your hands an= d say nothing can be done and cave to copyleftism, or create at least so= me deterrent or some permissions regime that at least mitigates the prob= lem. = The question is how you build in a response to the problem of theft of I= P in *3-D social software* which you cannot treat in the same way as oth= er kinds of 2-D software merely running applications in the background f= or wordprocessing and other functions *because people are literally inha= biting it in an immersive, 3-D environment*. They expect more of a versi= militude to real-life in such environments, and in fact, there are plent= y of examples of 2-D software with licensing and permissions to support = that. And just because music-sharing is removing DRM and going to other = models doesn't mean that all content production and sale in virtual worl= ds has to follow lockstep the same solutions. What that means is when you say "metadata" should be built in, the quest= ion then comes: how, and *as what*? Your invocation of the There model, = which involve having users submit all their content to be cleared -- and= then implicitly IP-secured -- by the platform provider -- hasn't been o= perational or acceptable in SL which has a free, non-clearance system fo= r content creation -- you don't have to submit to the company, you just = use the tools to make stuff. Currently, the SL system has three kinds of= permission checkoff boxes you can select on anything you make: copy/mod= /transfer. If you don't check off the boxes for "copy" or "transfer" at = least for the ordinary user, not employing hacks or exploits, your work = cannot be physically copied or transferred. It isn't some elaborate digi= tal rights management, but it is a workable one that helps the *social* = task of deterring theft because it readily conveys in embedded code form= the maker's intent. It is widely respected. That *is* the metadata. It = isn't just showing the avatar's name who created the object What's happened with some of the more extreme AWG members in SL is that = they've called for junking this metadata showing intent within objects a= s indefensible. They don't want to bother porting it into standards or o= ther worlds beyond SL. They are basically just telling people either to = tack a Creative Commons notecard on to their product or to call their la= wyers if their IP is violated -- which it often is in the opensourced re= verse-engineered worlds based on SL. But people interested in protecting= IP without making creators jump through hoops and expenses like that fa= il to see why the metadata of a created object cannot include that regim= e of the 3 permission checkoffs. It simply is immaterial if coders see t= echnically that this is crackable; they are inhabiting the 2-D world of = the coder and his concerns; what matters is in the integral 3-D world of= the user -- which you cannot hide from as a coder in a virtual world --= that at least some physical deterrent is produced against rampant theft= , so that when theft *does* take place, you have a marker, you can can d= isplay that a hack was used in defiance of the obvious permissions regim= e inworld. Prokofy Neva ____________________________________________________________ Click here to find the perfect banking opportunity! http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw3AeR5l0tqa89HGwlQyJJb5= V2kCCxU5fg1XwaioHgrJphDSV/ From wjgeorge@dceo.rutgers.edu Sun Feb 15 06:28:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13CA93A6AB2 for ; Sun, 15 Feb 2009 06:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZfOHddL6WNt for ; Sun, 15 Feb 2009 06:28:11 -0800 (PST) Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id 4D5763A6A4F for ; Sun, 15 Feb 2009 06:28:10 -0800 (PST) Received: by gxk22 with SMTP id 22so2266166gxk.13 for ; Sun, 15 Feb 2009 06:28:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.205.15 with SMTP id c15mr195557ang.132.1234708099316; Sun, 15 Feb 2009 06:28:19 -0800 (PST) Date: Sun, 15 Feb 2009 09:28:19 -0500 Message-ID: <27a487810902150628v5f94b5d6p4422623bd4e72bfe@mail.gmail.com> From: William George To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016369202cba93a800462f5e15a Subject: [mmox] IP issues and interop X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 14:28:12 -0000 --0016369202cba93a800462f5e15a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There is _no_ effective judicial system (never mind answering the question of jurisdiction). How can anyone be said to "own" these ideas? There must be some way to partition these social issues into another working group to move on with the substantial technical issues. --0016369202cba93a800462f5e15a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is _no_ effective judicial system (never mind answering the question = of jurisdiction). How can anyone be said to "own" these ideas?
There must be some way to partition these social issues into another = working group to move on with the substantial technical issues.



--0016369202cba93a800462f5e15a-- From dyerbrookme@juno.com Sun Feb 15 15:36:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4693A698D for ; Sun, 15 Feb 2009 15:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVE7sZd1rDzZ for ; Sun, 15 Feb 2009 15:36:51 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id BF0773A67F1 for ; Sun, 15 Feb 2009 15:36:51 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail07.vgs.untd.com [10.181.12.147]) by smtpout03.vgs.untd.com with SMTP id AABE3TKZ9ANPQQHS for (sender ); Sun, 15 Feb 2009 15:36:31 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNx4mBTSFGZIvhEASfTiXG9w== Received: (from dyerbrookme@juno.com) by webmail07.vgs.untd.com (jqueuemail) id N9GTTMFW; Sun, 15 Feb 2009 15:36:17 PST Received: from [162.83.144.3] by webmail07.vgs.untd.com with HTTP: Sun, 15 Feb 2009 23:36:11 GMT X-Originating-IP: [162.83.144.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sun, 15 Feb 2009 23:36:11 GMT To: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090215.183611.637.0@webmail07.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 1:1:3407774094 X-UNTD-Peer-Info: 10.181.12.147|webmail07.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 35 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 23:36:52 -0000 >There must be some way to partition these social issues into another wo= rking group to move on with the substantial technical issues. Perhaps that's a good idea, but in fact it's always troublesome that som= eone moves to "partition away social issues" to some backwater on anothe= r list, in order to get on with "substantial technical issues" which in = fact under the guise of "solving technical problems" have huge social an= d political impact (like removing permissions for intellectual property)= . ____________________________________________________________ Click to see huge collection of discounted designer watches. http://thirdpartyoffers.juno.com/TGL2141/fc/PnY6rw1zkaCpO5xKx2TSRsvZ6T7E= SYicvd4CNf9lr0CnKP7Wn23W1/ From lenglish5@cox.net Sun Feb 15 16:08:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F10943A6943 for ; Sun, 15 Feb 2009 16:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Hrv4HAIHP40 for ; Sun, 15 Feb 2009 16:08:55 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id 37AFD3A6781 for ; Sun, 15 Feb 2009 16:08:55 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090216000905.ULFI12838.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>; Sun, 15 Feb 2009 19:09:05 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id GQ941b0094N6T0Q03Q944U; Sun, 15 Feb 2009 19:09:04 -0500 X-Authority-Analysis: v=1.0 c=1 a=MthLulolaBoA:10 a=r-rcRZjYqYEA:10 a=Wajolswj7cQA:10 a=n9byYlQaxt_SwNa3WnkA:9 a=SyCVUfnmAzqsj0auMXAA:7 a=K1cPc3q7NSPM4--UXx7iaSkHDZEA:4 a=B0cvAcWxpcAA:10 a=F3I9zkEPI30A:10 X-CM-Score: 0.00 Message-ID: <4998AEA0.7060703@cox.net> Date: Sun, 15 Feb 2009 17:09:04 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090215.183611.637.0@webmail07.vgs.untd.com> In-Reply-To: <20090215.183611.637.0@webmail07.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 35 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 00:08:56 -0000 dyerbrookme@juno.com wrote: >> There must be some way to partition these social issues into another working group to move on with the substantial technical issues. >> > > Perhaps that's a good idea, but in fact it's always troublesome that someone moves to "partition away social issues" to some backwater on another list, in order to get on with "substantial technical issues" which in fact under the guise of "solving technical problems" have huge social and political impact (like removing permissions for intellectual property). > > The attitude the SL AWG has taken towards these issues is that the technology has to support a wide range of social policies without playing favorites. There are at least two examples of how players (worlds/grids) in the SL metaverse approach authorization: 1) The Agent Domain, which plays a role as the authorizing entity of an avatar regardless of which grid/world the avatar visits and 2) Hypergrid, which assumes that all avatars are equally authorized for access to all services within a given set of participating worlds/grids. There's plenty of room for interaction between these two extremes and both extremes will likely have a place depending on what policies a given world or worlds requires for interop, Intellectual Property handling, etc. Lawson From dahliatrimble@gmail.com Sun Feb 15 17:11:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 647F43A6B0C for ; Sun, 15 Feb 2009 17:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLAqaWrlqedB for ; Sun, 15 Feb 2009 17:11:35 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id B21793A6AF4 for ; Sun, 15 Feb 2009 17:11:35 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2306898wfd.31 for ; Sun, 15 Feb 2009 17:11:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=r6f7sAqGBZD6Noy0KjfRn17SuSWBMUQJOWvG1v1tL5o=; b=GA9LeAsNMb0qugdWst2xi+kOqlMVhNTH6dQfjObVCfXBQ2RJYnzcsXWAn+RjM6wM9g zm6+qTufpFbozD94daq1s+Vy/jO0rFpK43WplxHb+PVEvpQjb6DOsOUvxWfYrczmxr0d bSj1BFDJejGihSWHMcZad1SbJsDqq+VW0xpPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fvBmvZCfgqkvO9RY3iLoVZOTAoGIVw6tmtWaMYWK8nok+OYTgsYBfFQd1e6HilxF5H wJ4IWoUjxsJsdgeu6K8OBbk2ePaShmp1qtdSG11ndnEC4tm3IO72RJCwHpb1j92G9aiJ HwF11bF9hhQpRRyov+Gk2dkHlysbl+fjBDqRI= MIME-Version: 1.0 Received: by 10.142.51.4 with SMTP id y4mr2095306wfy.199.1234746704939; Sun, 15 Feb 2009 17:11:44 -0800 (PST) In-Reply-To: <4998AEA0.7060703@cox.net> References: <20090215.183611.637.0@webmail07.vgs.untd.com> <4998AEA0.7060703@cox.net> Date: Sun, 15 Feb 2009 17:11:44 -0800 Message-ID: From: Dahlia Trimble To: mmox@ietf.org Content-Type: multipart/alternative; boundary=000e0cd20d86bc4a0d0462fede8e Subject: Re: [mmox] mmox Digest, Vol 1, Issue 35 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 01:11:36 -0000 --000e0cd20d86bc4a0d0462fede8e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Feb 15, 2009 at 4:09 PM, Lawson English wrote: ... > > > 2) Hypergrid, which assumes that all avatars are equally authorized for > access to all services within a given set of participating worlds/grids. > The current prototype implementation of Hypergrid may be described in this manner but there have also been discussions about how to add access restrictions to content that might be shared between grids. --000e0cd20d86bc4a0d0462fede8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Feb 15, 2009 at 4:09 PM, Lawson = English <lenglish= 5@cox.net> wrote:
...

2) Hypergrid, which assumes that all avatars are equally authorized for acc= ess to all services within a given set of participating worlds/grids.
 

The current prototype imple= mentation of Hypergrid may be described in this manner but there have also = been discussions about how to add access restrictions to content that might= be shared between grids.
--000e0cd20d86bc4a0d0462fede8e-- From lenglish5@cox.net Sun Feb 15 23:14:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3AB328B797 for ; Sun, 15 Feb 2009 23:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.264 X-Spam-Level: X-Spam-Status: No, score=0.264 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1H01-lbF7fEK for ; Sun, 15 Feb 2009 23:14:01 -0800 (PST) Received: from fed1rmmtao105.cox.net (fed1rmmtao105.cox.net [68.230.241.41]) by core3.amsl.com (Postfix) with ESMTP id 04FD628B23E for ; Sun, 15 Feb 2009 23:14:00 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090216071408.UEWR8485.fed1rmmtao105.cox.net@fed1rmimpo02.cox.net>; Mon, 16 Feb 2009 02:14:08 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id GXE81b0024N6T0Q04XE8UT; Mon, 16 Feb 2009 02:14:08 -0500 X-Authority-Analysis: v=1.0 c=1 a=MthLulolaBoA:10 a=r-rcRZjYqYEA:10 a=Wajolswj7cQA:10 a=_Jxp2Z5NSIhfSq2imUYA:9 a=Z7xHXdNq2iCjexaANu3zDJvXix0A:4 a=4vB-4DCPJfMA:10 a=oltf0pfCdT4A:10 X-CM-Score: 0.00 Message-ID: <49991240.7060000@cox.net> Date: Mon, 16 Feb 2009 00:14:08 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Dahlia Trimble References: <20090215.183611.637.0@webmail07.vgs.untd.com> <4998AEA0.7060703@cox.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 35 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 07:14:01 -0000 Dahlia Trimble wrote: > > > On Sun, Feb 15, 2009 at 4:09 PM, Lawson English > wrote: > ... > > > 2) Hypergrid, which assumes that all avatars are equally > authorized for access to all services within a given set of > participating worlds/grids. > > > > The current prototype implementation of Hypergrid may be described in > this manner but there have also been discussions about how to add > access restrictions to content that might be shared between grids. > My hope is that this body will acknowledge the need for the two extremes, and develop protocols that will work with either extreme or compromise/combination, so that policy can be set AND made public in a wide variety of ways as world/grid hosting providers and their customers/clients require. L. From lenglish5@cox.net Tue Feb 17 01:45:53 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC523A6A99 for ; Tue, 17 Feb 2009 01:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrnsBP0SiAcY for ; Tue, 17 Feb 2009 01:45:52 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id 2E1353A6A4C for ; Tue, 17 Feb 2009 01:45:52 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090217094550.JQBO12838.fed1rmmtao103.cox.net@fed1rmimpo02.cox.net> for ; Tue, 17 Feb 2009 04:45:50 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id Gxlq1b0054N6T0Q04xlqze; Tue, 17 Feb 2009 04:45:50 -0500 X-Authority-Analysis: v=1.0 c=1 a=CE8gXzWyyuIA:10 a=w6bTH87K6gkA:10 a=Wajolswj7cQA:10 a=HEhBrlagAAAA:8 a=78VZib3qAAAA:8 a=aAJBzeK_vVQhZ1HbpFgA:9 a=6e3LqOmgP13ZQnIglHYA:7 a=q9jvUAb9hqIJnjw-Go2TpU7ilR4A:4 a=-ZQhYGXY2L8A:10 X-CM-Score: 0.00 Message-ID: <499A874E.30107@cox.net> Date: Tue, 17 Feb 2009 02:45:50 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] Weekly AWG meeting in SL. Weekly OpenSim meeting at Wright Plaza sim X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 09:45:53 -0000 For those who aren't familiar with it, the SL AWG meets every week in Second Life on Tuesday at 9:30 AM pacific time at IBM's ThornBridgeTown island. The topics will likely be IETF and specific issues concerning ongoing work with OGP protocols, such as the open source Agent Domain server meant for OpenSIm distribution. Additionally, the OpenSim developers meet the same day: Tuesdays noon SLT, at Wright Plaza sim in OSGrid at 19:00 GMT/11AM SLT Registration required to login at: http://osgrid.org/index.php?page=create&btn=4 http://osgrid.org/index.php?&page=smodul&id=7&btn=7 http://opensimulator.org/wiki/Office_Hours 19:00 GMT, 11:00 Pacific Coast (Second Life) Time Send an instant message in Second Life to Saijanai Kuhn, Tree Kyomoon or Zha Ewry in order to get the group invite to enable access to the ThornBridgeTown simulator. Registration and login procedures for the OpenSim meeting are found above. Attendance to both meetings is open to anyone. See you there. Lawson English (Saijanai Kuhn ISL) From wjgeorge@dceo.rutgers.edu Tue Feb 17 07:20:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262613A6C62 for ; Tue, 17 Feb 2009 07:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.047 X-Spam-Level: X-Spam-Status: No, score=-1.047 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5tiFywYxprx for ; Tue, 17 Feb 2009 07:20:58 -0800 (PST) Received: from mail-gx0-f222.google.com (mail-gx0-f222.google.com [209.85.217.222]) by core3.amsl.com (Postfix) with ESMTP id 2F7BB3A6A69 for ; Tue, 17 Feb 2009 07:20:58 -0800 (PST) Received: by gxk22 with SMTP id 22so4155181gxk.13 for ; Tue, 17 Feb 2009 07:21:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.144.20 with SMTP id r20mr354233and.104.1234884068658; Tue, 17 Feb 2009 07:21:08 -0800 (PST) In-Reply-To: References: Date: Tue, 17 Feb 2009 10:21:08 -0500 Message-ID: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> From: William George To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016e6434492404d0804631eda52 Subject: Re: [mmox] mmox Digest, Vol 1, Issue 36 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 15:20:59 -0000 --0016e6434492404d0804631eda52 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I didn't think my point was correctly interpreted. Imagine the early days of he automobile or railways? There were no real standards committees in those days, but one could image how they would operate. Do we worry about what happens to the blacksmiths and stable hands? I suggest a quick google for the term "Luddite" and one can see how the social aspects _must_ trail the technology. My position is that we should assume that objects _will_ be transferred between worlds/grids and that as an _owner_ of said property I will retain some kind of "rights of usage". I would also expect these objects to operate in some consistent manner across these worlds. I see this as an important part of interoperability, if not the main charter. There has to be some technical discussion concerning some form of authentication, and possibly even authorization, but lets not get mired in detail to protect the virtual blacksmith's "rights" to cobble their prim horseshoes. --0016e6434492404d0804631eda52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I didn't think my point was correctly interpreted.

Imagine the e= arly days of he automobile or railways? There were no real standards commit= tees in those days, but one could image how they would operate.

Do we worry about what happens to the blacksmiths and stable hands? I s= uggest a quick google for the term "Luddite" and one can see how = the social aspects _must_ trail the technology.

My position is that= we should assume that objects _will_ be transferred between worlds/grids a= nd that as an _owner_ of said property I will retain some kind of "rig= hts of usage". I would also expect these objects to operate in some co= nsistent manner across these worlds. I see this as an important part of int= eroperability, if not the main charter.

There has to be some technical discussion concerning some form of authe= ntication, and possibly even authorization, but lets not get mired in detai= l to protect the virtual blacksmith's "rights" to cobble thei= r prim horseshoes.

--0016e6434492404d0804631eda52-- From cfk@pacbell.net Tue Feb 17 08:21:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28A028C13D for ; Tue, 17 Feb 2009 08:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfdmW8ZDye8B for ; Tue, 17 Feb 2009 08:21:14 -0800 (PST) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id D867928C143 for ; Tue, 17 Feb 2009 08:21:13 -0800 (PST) Received: (qmail 4073 invoked by uid 60001); 17 Feb 2009 16:21:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=KN5iVb78yclI6E0KnaIaAZPENEKxiY12ibVGvN/8dpfbhhk4LbkQDRq963JdmsHo9GO2A6ihOMg7kT4Mc2rtLOufN0q+FCGvFmBlbsXZmlIkPD10EsnualqXxKhvcRkbGXvFbyPQvtEYeDGygGbtbzr/41b40BZX8hHC3uKyW8k=; X-YMail-OSG: PkMPFLEVM1mpFydAeWZRnmeZsUFO_Mw3GbJzt_UKuSAYLWX4iwZ3PplxIZRqYgmW_ctiDuKBXFnuIcz9nVCJYUG46ozQLOBVZ5mJ1eKPUPytStURaNd297p_oJtnfywQgQjtQ_f46BZdrT7VXLsFB9Dbvm4jsfcjlQlLIApMPgA_2x.ltAcjRJPXCcbCI8DL5kUgKoKkxI1t5Q-- Received: from [75.214.176.151] by web82607.mail.mud.yahoo.com via HTTP; Tue, 17 Feb 2009 08:21:24 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> Date: Tue, 17 Feb 2009 08:21:24 -0800 (PST) From: Charles Krinke To: William George , mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2018715770-1234887684=:2383" Message-ID: <548919.2383.qm@web82607.mail.mud.yahoo.com> Subject: Re: [mmox] mmox Digest, Vol 1, Issue 36 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 16:21:14 -0000 --0-2018715770-1234887684=:2383 Content-Type: text/plain; charset=us-ascii Perhaps another way to perceive of interoperability between various worlds & grids is similar to international travel between countries. There could be argued that there is a subset of items that one owns that are commonly carried through airport security which would include modest clothes, avatar attachments such as hair and some personal items. But, that would not include a 747. Also, some form of a wallet and identification documents is appropriate. So, if we were to concentrate on the smallest reasonable subset of items that can be reasonably carried between worlds and grids first, perhaps a consensus can be arrived at. Charles ________________________________ From: William George To: mmox@ietf.org Sent: Tuesday, February 17, 2009 7:21:08 AM Subject: Re: [mmox] mmox Digest, Vol 1, Issue 36 I didn't think my point was correctly interpreted. Imagine the early days of he automobile or railways? There were no real standards committees in those days, but one could image how they would operate. Do we worry about what happens to the blacksmiths and stable hands? I suggest a quick google for the term "Luddite" and one can see how the social aspects _must_ trail the technology. My position is that we should assume that objects _will_ be transferred between worlds/grids and that as an _owner_ of said property I will retain some kind of "rights of usage". I would also expect these objects to operate in some consistent manner across these worlds. I see this as an important part of interoperability, if not the main charter. There has to be some technical discussion concerning some form of authentication, and possibly even authorization, but lets not get mired in detail to protect the virtual blacksmith's "rights" to cobble their prim horseshoes. --0-2018715770-1234887684=:2383 Content-Type: text/html; charset=us-ascii
Perhaps another way to perceive of interoperability between various worlds & grids is similar to international travel between countries.

There could be argued that there is a subset of items that one owns that are commonly carried through airport security which would include modest clothes, avatar attachments such as hair and some personal items. But, that would not include a 747. Also, some form of a wallet and identification documents is appropriate.

So, if we were to concentrate on the smallest reasonable subset of items that can be reasonably carried between worlds and grids first, perhaps a consensus can be arrived at.

Charles

From: William George <wjgeorge@dceo.rutgers.edu>
To: mmox@ietf.org
Sent: Tuesday, February 17, 2009 7:21:08 AM
Subject: Re: [mmox] mmox Digest, Vol 1, Issue 36

I didn't think my point was correctly interpreted.

Imagine the early days of he automobile or railways? There were no real standards committees in those days, but one could image how they would operate.

Do we worry about what happens to the blacksmiths and stable hands? I suggest a quick google for the term "Luddite" and one can see how the social aspects _must_ trail the technology.

My position is that we should assume that objects _will_ be transferred between worlds/grids and that as an _owner_ of said property I will retain some kind of "rights of usage". I would also expect these objects to operate in some consistent manner across these worlds. I see this as an important part of interoperability, if not the main charter.

There has to be some technical discussion concerning some form of authentication, and possibly even authorization, but lets not get mired in detail to protect the virtual blacksmith's "rights" to cobble their prim horseshoes.

--0-2018715770-1234887684=:2383-- From markl@lindenlab.com Tue Feb 17 14:20:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C6A73A6A16 for ; Tue, 17 Feb 2009 14:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tX2S0y+I6Cj for ; Tue, 17 Feb 2009 14:20:51 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 3FFDA3A6812 for ; Tue, 17 Feb 2009 14:20:51 -0800 (PST) Received: from nil.lindenlab.com (nil.lindenlab.com [10.1.16.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 4EAD73DBC0A1 for ; Tue, 17 Feb 2009 14:21:02 -0800 (PST) Message-Id: <5BD97198-DA56-41B4-9307-67E5488934BB@lindenlab.com> From: Mark Lentczner To: mmox@ietf.org In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501643FF@rrsmsx506.amr.corp.intel.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2-1051507969 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 14:21:01 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D501643FF@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [mmox] LLIDL question X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:20:52 -0000 --Apple-Mail-2-1051507969 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Feb 13, 2009, at 7:06 PM, Hurliman, John wrote: > What is the meaning of this example line in LLIDL? > { $: 42 } Indeed, the "dictionary" form of maps didn't get explained. There are =20= two productions for map in LLIDL: map =3D "{" s member-list s "}" map =3D/ "{" s "$" s ":" s value s "}" The second describes the expectation that the value is map of =20 arbitrary keys, each of which has the same format. For example: { $: uri } ;a map of resource names to uris { $: { x: real, y: real }} ;a map of signage to x,y locations The first example is used when returning a list of requested =20 capabilities, where the names are the resource names. You have to be careful when using this form, since keys in maps are =20 consider distinct based on code point sequence, but strings, including =20= map keys, can be normalized en-route. Things like resource names are =20= fine, since they are invariant under the allowed normalization. So, =20 for example, If you expect the data set to have things like: "Two\r\nLines\r\nPub" or "Magasin de Th=E9" in it, then the second example above wouldn't be appropriate. Instead =20= use: [ { name: string, location: { x: real, y: real} }, ... ] Now, this construction would be odd: { $: 42 } It means the expected value is a map where every value had to be the =20 number 42. I suppose this could describe a map of Ultimate Questions =20= and their Answers! - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com --Apple-Mail-2-1051507969 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Feb 13, 2009, at = 7:06 PM, Hurliman, John wrote:
What = is the meaning of this example line in LLIDL?
{ $: 42 = }

Indeed, the "dictionary" form of = maps didn't get explained.  There are two productions for map in = LLIDL:
   map             =3D  "{" s member-list s "}"
   map             =3D/ "{" s "$" s ":" s value s "}"

 { $: uri } ;a map of resource names to = uris
{ $: = { x: real, y: real }} ;a map of signage to x,y = locations

The first example = is used when returning a list of requested capabilities, where the names = are the resource names.

You have to be careful when using this form, = since keys in maps are consider distinct based on code point sequence, = but strings, including map keys, can be normalized en-route. =  Things like resource names are fine, since they = are invariant under the allowed normalization. So, for = example, If you expect the data set to have things = like:
"Two\r\nLines\r\nPub"
or "Magasin de = Th=E9"
in it, then the = second example above wouldn't be appropriate.  Instead = use:

=  [ { name: string, location: { x: real, y: real} }, ... = ]

Now, this construction would be = odd:

=  { $: 42 }

It means the = expected value is a map where every value had to be the number 42. =  I suppose this could describe a map = of Ultimate Questions and their = Answers!

- = Mark

Mark = Lentczner
Sr. Systems = Architect
Technology Integration
Linden = Lab


Zero Linden




= --Apple-Mail-2-1051507969-- From markl@lindenlab.com Tue Feb 17 14:33:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD24228C147 for ; Tue, 17 Feb 2009 14:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1w1ZB9hTliuI for ; Tue, 17 Feb 2009 14:33:19 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id E88573A6812 for ; Tue, 17 Feb 2009 14:33:19 -0800 (PST) Received: from nil.lindenlab.com (nil.lindenlab.com [10.1.16.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id C6C793DBC0A1 for ; Tue, 17 Feb 2009 14:33:31 -0800 (PST) Message-Id: From: Mark Lentczner To: mmox@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 14:33:31 -0800 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:33:21 -0000 Friends - As if the internet weren't already full of multiple monikers for everyone, many of us have only met in virtual worlds. I suspect that I've met some of you in person, via e-mail, and in Second Life, and that I don't know that all three of you are the same! Having so many multiple personalities shakes my own sense of self, so I thought I'd start a thread of introductions. I'll go first: I'm Mark Lentczner. I'm the Sr. Systems Architect at Linden Lab. I've been working on Second Life for over three years, mostly on evolving the architecture of this growing virtual world. Many of you know me from AWG meetings and my office hours as Zero Linden. Work Identities: e-mail: markl (at) lindenlab (dot) com web: https://wiki.secondlife.com/wiki/User:Zero_Linden Second Life: Zero Linden Personal Identities: web: http://www.ozonehouse.com/mark/ Second Life: Zarf Vantongerloo - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From markl@lindenlab.com Tue Feb 17 14:37:00 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B0B83A6849 for ; Tue, 17 Feb 2009 14:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.377 X-Spam-Level: X-Spam-Status: No, score=-3.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHG9bldD1Wya for ; Tue, 17 Feb 2009 14:36:58 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id D5DE83A67A7 for ; Tue, 17 Feb 2009 14:36:58 -0800 (PST) Received: from nil.lindenlab.com (nil.lindenlab.com [10.1.16.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id ABA793DBC0A1 for ; Tue, 17 Feb 2009 14:37:10 -0800 (PST) Message-Id: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> From: Mark Lentczner To: mmox@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-3-1052476450 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 14:37:10 -0800 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:37:00 -0000 --Apple-Mail-3-1052476450 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit MMOXen - I thought that it would be good to give a recap of how we got to where we are... By mid-2007 there were at least two independent development efforts that were trying to be interoperable with Second Life, despite there being no official way to do it: LibSL and OpenSim. At Linden Lab, we saw that as healthy, and indication that there was clear interest in building toward interoperable virtual worlds. In September of 2007, Linden Lab called together a group of interested users, including the LibSL and OpenSim projects, and formed the Architecture Working Group (AWG) to help design an interoperable architecture and protocol. In the Spring of 2008, the first drafts of the Open Grid Protocol (OGP) were published. Rather than simply writing down Second Life's existing protocol, these documents took new ideas, melded with what the community learned about interfacing with Second Life, and boot- strapped a wholly new protocol. Working through the Spring and Summer of 2008, Linden Lab, first with IBM, and then later with a wider range of the community, demonstrated interoperability between Second Life and OpenSim, having avatars teleport back and forth between the worlds. At the same time, others created another implementation of the protocol, PyOGP, to be used for testing and for building other interoperable components. By the end of 2008, since there were now several OGP documents written[1], and several implementations, it seemed to us that the time was ripe to bring this work to the IETF: Some of these protocols would need things like registered MIME types, and all would benefit from more input to the work. In that context, along with the fortuitous location and timing of IETF 74, Linden Lab and IBM requested creation of this mailing list, and a BoF session for IETF 74. While we realize that OGP has a long way to go, building a working group at a standards body also takes time, and felt that we should get started now. During roughly the same span of time, two other consortia efforts got under way. One is the MPEG-V group which is looking at information exchange formats and interfaces with the physical world. Their last published documents are from May 2008 and are a set of project requirements[2]. The other group is the Virtual Worlds Roadmap SIG, started by Intel, Samsung, Electric Sheep and others to develop a broad case analysis, roadmap and timeline for adoption of virtual worlds and their applications[3]. These groups clearly have different objectives than the IETF's which is more focused on supporting protocol usage on the Internet. We felt that the required work on OGP would be best served by the IETF, whereas more general discussion and evolution would be better served by the Virtual Worlds Roadmap SIG. While there is plenty to do and discuss in order to develop OGP into a fully workable protocol, we think it represents an initial shared vision of an interoperable protocol and hope it can evolve and grow in the context of this group. - Mark Lentczner [1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol [2] http://www.chiariglione.org/mpeg/working_documents.htm#MPEG-V [3] http://www.virtualworldsroadmap.org/ Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com P.S.: I like "MMOXen". Makes me think we are bearing the hard work to furrow the ground to plant the seeds for the growth of.... okay, okay, so perhaps I'm taking that too far. But I still like "MMOXen". --Apple-Mail-3-1052476450 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable MMOXen -

I thought that = it would be good to give a recap of how we got to where we = are...

By mid-2007 there were at least two independent = development efforts that were trying to be interoperable with Second = Life, despite there being no official way to do it: LibSL and OpenSim. =  At Linden Lab, we saw that as healthy, and indication that there = was clear interest in building toward interoperable virtual worlds. In = September of 2007, Linden Lab called together a group of interested = users, including the LibSL and OpenSim projects, and formed the = Architecture Working Group (AWG) to help design an interoperable = architecture and protocol.

In the Spring of 2008, the first = drafts of the Open Grid Protocol (OGP) were published. Rather than = simply writing down Second Life's existing protocol, these documents = took new ideas, melded with what the community learned about interfacing = with Second Life, and boot-strapped a wholly new protocol.  Working = through the Spring and Summer of 2008, Linden Lab, first with IBM, and = then later with a wider range of the community, demonstrated = interoperability between Second Life and OpenSim, having avatars = teleport back and forth between the worlds. At the same time, others = created another implementation of the protocol, PyOGP, to be used for = testing and for building other interoperable components.

By the = end of 2008, since there were now several OGP documents written[1], and = several implementations, it seemed to us that the time was ripe to bring = this work to the IETF: Some of these protocols would need things like = registered MIME types, and all would benefit from more input to the = work. In that context, along with the fortuitous location and timing of = IETF 74, Linden Lab and IBM requested creation of this mailing list, and = a BoF session for IETF 74. While we realize that OGP has a long way to = go, building a working group at a standards body also takes time, and = felt that we should get started now.

During roughly the same span = of time, two other consortia efforts got under way.  One is the = MPEG-V group which is looking at information exchange formats and = interfaces with the physical world.  Their last published documents = are from May 2008 and are a set of project requirements[2]. The other = group is the Virtual Worlds Roadmap SIG, started by Intel, Samsung, = Electric Sheep and others to develop a broad case analysis, roadmap and = timeline for adoption of virtual worlds and their applications[3]. These = groups clearly have different objectives than the IETF's which is more = focused on supporting protocol usage on the Internet.  We felt that = the required work on OGP would be best served by the IETF, whereas more = general discussion and evolution would be better served by the Virtual = Worlds Roadmap SIG.

While there is plenty to do and discuss in = order to develop OGP into a fully workable protocol, we think it = represents an initial shared vision of an interoperable protocol and = hope it can evolve and grow in the context of this group.

- Mark = Lentczner

[1] http://wiki.se= condlife.com/wiki/Open_Grid_Protocol
[2] htt= p://www.chiariglione.org/mpeg/working_documents.htm#MPEG-V
[3] = ;http://www.virtualworldsroad= map.org/

Mark Lentczner
Sr. Systems = Architect
Technology Integration
Linden Lab

markl@lindenlab.com

Zero = Linden
zero.linden@secondlife.com<= br>
P.S.: I like "MMOXen".  Makes me think we are bearing the = hard work to furrow the ground to plant the seeds for the growth of.... = okay, okay, so perhaps I'm taking that too far.  But I still like = "MMOXen".


= --Apple-Mail-3-1052476450-- From cs@comlounge.net Tue Feb 17 15:05:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFE0328C1A7 for ; Tue, 17 Feb 2009 15:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcP40tM-PfE6 for ; Tue, 17 Feb 2009 15:05:35 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 507E528C167 for ; Tue, 17 Feb 2009 15:05:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 414211CE0339; Wed, 18 Feb 2009 00:05:40 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZyZWK5i0ENN; Wed, 18 Feb 2009 00:05:39 +0100 (CET) Received: from [192.168.178.40] (pD9EBEAE0.dip.t-dialin.net [217.235.234.224]) by post.comlounge.net (Postfix) with ESMTP id 3F91C1CE023D; Wed, 18 Feb 2009 00:05:38 +0100 (CET) Message-ID: <499B42C1.7060504@comlounge.net> Date: Wed, 18 Feb 2009 00:05:37 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mark Lentczner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:05:36 -0000 Hi! > Having so many multiple personalities shakes my own sense of self, so I > thought I'd start a thread of introductions. I'll go first: Sounds like a good idea :-) So here go I: I am Christian Scholz, co-founder of a python centric web development agency in Germany called COM.lounge (http://comlounge.net). I started with Second Life in February 2007, was experimenting with basically everything (did clothes, various machinima pieces, coding of course and some client projects around building and scripting), attended the first AWG meeting, many of the OGP ones, helped starting the pyogp project and created a prototype of a Python/Plone based Agent Domain implementation. I am also member of the steering commitee of the DataPortability Project where we focus on making it easy for users to share their data among internet services while retaining as much control about it as possible (see http://dataportability.org). Thus I am very much interested in connecting the web and the VW world by reusing existing standards where possible so that it's easy for users and developers to connect these worlds (it's more universes it sometimes seems ;-)) Some Info: Blog: http://mrtopf.de/blog Twitter: http://twitter.com/mrtopf english podcast: http://datawithoutborders.net german podcast: http://openweb-podcast.de Second Life avatar: Tao Takashi -- Christian -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From john.hurliman@intel.com Tue Feb 17 15:09:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673AD28C1A0 for ; Tue, 17 Feb 2009 15:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWfgQEfMMcsX for ; Tue, 17 Feb 2009 15:09:32 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 74C9128C17D for ; Tue, 17 Feb 2009 15:09:32 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 17 Feb 2009 15:08:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,225,1233561600"; d="scan'208";a="431772716" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by fmsmga002.fm.intel.com with ESMTP; 17 Feb 2009 15:05:23 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Tue, 17 Feb 2009 16:09:22 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Tue, 17 Feb 2009 16:09:17 -0700 Thread-Topic: [mmox] The Story So Far... Thread-Index: AcmRUFDbIEuMfqTTTmmcd4zdK1NIJQAAXFZg Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> In-Reply-To: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:09:33 -0000 >While there is plenty to do and discuss in order to develop OGP into a >fully workable protocol, we think it represents an initial shared vision >of an interoperable protocol and hope it can evolve and grow in the >context of this group. > >- Mark Lentczner > >[1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol It's great to see the amount of work that is being brought to the table by = Linden Lab and the Linden Lab Architecture Working Group (AWG) participants= , and I hope as much of it as possible can be used to build an MMOX standar= d. I've been working on an LLIDL implementation among other things based on= what Linden Lab has submitted as draft material. However, I have some conc= erns about the implicit merging of MMOX goals and what Linden Lab's AWG is = proposing. It's my understanding that Open Grid Protocol (OGP) is a Linden Lab project= ; part of the Linden Lab AWG which had no active contributors that were als= o active developers of libSecondLife/libOpenMetaverse or OpenSim during the= time the OGP protocols were designed. The "agent domain" concept in OGP te= rminology brings in a host of assumptions that are diametrically opposed to= the goals of libOpenMetaverse and OpenSim (supporting millions of independ= ent administrative domains and service providers). The current MMOX charter makes no reference to specific implementations suc= h as Linden Lab's OGP, which I think is the correct approach. John From gareth@litesim.com Tue Feb 17 15:30:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B413A6948 for ; Tue, 17 Feb 2009 15:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZkeSSzaxzDU for ; Tue, 17 Feb 2009 15:30:00 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 6EDDE3A68AE for ; Tue, 17 Feb 2009 15:30:00 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2155111rvb.49 for ; Tue, 17 Feb 2009 15:30:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.53.4 with SMTP id f4mr2443320rvk.155.1234913410990; Tue, 17 Feb 2009 15:30:10 -0800 (PST) In-Reply-To: References: Date: Tue, 17 Feb 2009 23:30:10 +0000 Message-ID: <61dbdd7d0902171530o52d5ff12n16402dc8cb9caf26@mail.gmail.com> From: Gareth Nelson To: Mark Lentczner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:30:01 -0000 My brief intro: I'm your generic hacker type, briefly did some virtual world hosting (with my company Litesim Ltd) based on some of the opensim codebase with heavy mods and my own particular version of interop, had full avatar, inventory and other goodies TPed from Second Life. I'm generally a purist with a lot of things (for example, I dislike OOP but tolerate it when it makes sense). On SL i'm Gareth Ellison or Gwen Hermit, everywhere else i'm just Gareth Nelson (gareth@litesim.com or gareth@garethnelson.com). Personal site - http://www.garethnelson.com On Tue, Feb 17, 2009 at 10:33 PM, Mark Lentczner wrote: > Friends - > > As if the internet weren't already full of multiple monikers for everyone, > many of us have only met in virtual worlds. I suspect that I've met some of > you in person, via e-mail, and in Second Life, and that I don't know that > all three of you are the same! > > Having so many multiple personalities shakes my own sense of self, so I > thought I'd start a thread of introductions. I'll go first: > > I'm Mark Lentczner. I'm the Sr. Systems Architect at Linden Lab. I've been > working on Second Life for over three years, mostly on evolving the > architecture of this growing virtual world. Many of you know me from AWG > meetings and my office hours as Zero Linden. > > Work Identities: > e-mail: markl (at) lindenlab (dot) com > web: > https://wiki.secondlife.com/wiki/User:Zero_Linden > Second Life: Zero Linden > > Personal Identities: > web: http://www.ozonehouse.com/mark/ > Second Life: Zarf Vantongerloo > > > - Mark > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From infinity@lindenlab.com Tue Feb 17 15:42:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328FD3A6AF9 for ; Tue, 17 Feb 2009 15:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAbHA+pBQf0O for ; Tue, 17 Feb 2009 15:41:57 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 4C64A3A6A8A for ; Tue, 17 Feb 2009 15:41:57 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 18AC7141405F; Tue, 17 Feb 2009 15:42:09 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: "Hurliman, John" In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 15:42:08 -0800 References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:42:01 -0000 On Feb 17, 2009, at 3:09 PM, Hurliman, John wrote: >> While there is plenty to do and discuss in order to develop OGP >> into a >> fully workable protocol, we think it represents an initial shared >> vision >> of an interoperable protocol and hope it can evolve and grow in the >> context of this group. >> >> - Mark Lentczner >> >> [1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol > > It's great to see the amount of work that is being brought to the > table by Linden Lab and the Linden Lab Architecture Working Group > (AWG) participants, and I hope as much of it as possible can be used > to build an MMOX standard. I've been working on an LLIDL > implementation among other things based on what Linden Lab has > submitted as draft material. awesome! > It's my understanding that Open Grid Protocol (OGP) is a Linden Lab > project; part of the Linden Lab AWG which had no active contributors > that were also active developers of libSecondLife/libOpenMetaverse > or OpenSim during the time the OGP protocols were designed. The > "agent domain" concept in OGP terminology brings in a host of > assumptions that are diametrically opposed to the goals of > libOpenMetaverse and OpenSim (supporting millions of independent > administrative domains and service providers). huh? there were a number of non-lindens who participated in the development of OGP. the AWG does not, nor did it ever disallow participation by libSL or libOMV contributors / committers. last summer we demonstrated interoperability between Linden Lab's servers and an OpenSim instance. we hope that members of the libSL and libOMV teams will participate in MMOX. the concept of an agent domain was defined explicitly to support many different independent administrative domains. that is... though the interoperability test last summer used the Linden agent domain, the specification does not mandate a single agent domain. in fact, i believe Christian Scholz (a non-linden) implemented his own Agent Domain based on code from the PyOGP project. There is also frequent mention in AWG meetings of an upcoming C# implementation of an Agent Domain, again by a non Linden-Lab employee. From john.hurliman@intel.com Tue Feb 17 15:44:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A403A6AFE for ; Tue, 17 Feb 2009 15:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AG1UoqqU-yBx for ; Tue, 17 Feb 2009 15:44:03 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 74B8A3A6AF9 for ; Tue, 17 Feb 2009 15:44:03 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 17 Feb 2009 15:39:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,225,1233561600"; d="scan'208";a="387612800" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga002.jf.intel.com with ESMTP; 17 Feb 2009 15:53:02 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Tue, 17 Feb 2009 16:44:13 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Tue, 17 Feb 2009 16:44:10 -0700 Thread-Topic: [mmox] Introductions Thread-Index: AcmRT8rPaIbDSL8lRn6MO/zh5oSjcQACCDug Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FDC79@rrsmsx506.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:44:04 -0000 I'm John Hurliman, a software engineer on Intel's Virtual Worlds Infrastruc= ture team and board member of the Open Metaverse Foundation. I started the = libsecondlife project (now libOpenMetaverse) a little over three years ago = to provide an open source implementation of the Second Life network protoco= l. I still make regular contributions to libOpenMetaverse, although my curr= ent focus is in the open source virtual world community working on the same= goals as the MMOX group. I maintain a work blog at http://software.intel.c= om/en-us/blogs/author/john-hurliman/ and a personal blog at http://www.jhur= liman.org/ John >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Mark Lentczner >Sent: Tuesday, February 17, 2009 2:34 PM >To: mmox@ietf.org >Subject: [mmox] Introductions > >Friends - > >As if the internet weren't already full of multiple monikers for >everyone, many of us have only met in virtual worlds. I suspect that >I've met some of you in person, via e-mail, and in Second Life, and >that I don't know that all three of you are the same! > >Having so many multiple personalities shakes my own sense of self, so >I thought I'd start a thread of introductions. I'll go first: > >I'm Mark Lentczner. I'm the Sr. Systems Architect at Linden Lab. I've >been working on Second Life for over three years, mostly on evolving >the architecture of this growing virtual world. Many of you know me >from AWG meetings and my office hours as Zero Linden. > >Work Identities: > e-mail: markl (at) lindenlab (dot) com > web: > https://wiki.secondlife.com/wiki/User:Zero_Linden > Second Life: Zero Linden > >Personal Identities: > web: http://www.ozonehouse.com/mark/ > Second Life: Zarf Vantongerloo > > > - Mark > >Mark Lentczner >Sr. Systems Architect >Technology Integration >Linden Lab > >markl@lindenlab.com > >Zero Linden >zero.linden@secondlife.com > > > > > >_______________________________________________ >mmox mailing list >mmox@ietf.org >https://www.ietf.org/mailman/listinfo/mmox > From gareth@litesim.com Tue Feb 17 15:47:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F6A3A6806 for ; Tue, 17 Feb 2009 15:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9fNDG3Mp9JC for ; Tue, 17 Feb 2009 15:47:35 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 692FA3A6895 for ; Tue, 17 Feb 2009 15:47:35 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2161006rvb.49 for ; Tue, 17 Feb 2009 15:47:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.50.11 with SMTP id c11mr2362654rvk.45.1234914466073; Tue, 17 Feb 2009 15:47:46 -0800 (PST) In-Reply-To: References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> Date: Tue, 17 Feb 2009 23:47:46 +0000 Message-ID: <61dbdd7d0902171547y538d9317ub6a641694e3a8db6@mail.gmail.com> From: Gareth Nelson To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:47:36 -0000 > huh? there were a number of non-lindens who participated in the development > of OGP. the AWG does not, nor did it ever disallow participation by libSL or > libOMV contributors / committers. last summer we demonstrated > interoperability between Linden Lab's servers and an OpenSim instance. we > hope that members of the libSL and libOMV teams will participate in MMOX. I believe that John was talking not so much about actual exclusion, but more the fact that the AWG did not have a large % of active opensim and libsl developers. Of course, quite a few opensim and libsl developers ahve been involved and are often seen inworld at meetings. > the concept of an agent domain was defined explicitly to support many > different independent administrative domains. that is... though the > interoperability test last summer used the Linden agent domain, the > specification does not mandate a single agent domain. in fact, i believe > Christian Scholz (a non-linden) implemented his own Agent Domain based on > code from the PyOGP project. There is also frequent mention in AWG meetings > of an upcoming C# implementation of an Agent Domain, again by a non > Linden-Lab employee. Could you tell us more about this C# implementation? I'm guessing it's under the auspices of the opensim project based on that choice of language. From cfk@pacbell.net Tue Feb 17 16:01:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65F8028C1A2 for ; Tue, 17 Feb 2009 16:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrPoAlhMjmeq for ; Tue, 17 Feb 2009 16:01:43 -0800 (PST) Received: from web82603.mail.mud.yahoo.com (web82603.mail.mud.yahoo.com [68.142.201.120]) by core3.amsl.com (Postfix) with SMTP id 689633A6B10 for ; Tue, 17 Feb 2009 16:01:42 -0800 (PST) Received: (qmail 23074 invoked by uid 60001); 18 Feb 2009 00:01:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=M80NPzQhR2254Cz76h9TThvW2kGzv3ioIFFcmXewh31mlKnhRNBfwUIY3XaiVMK2vmnEGzFR36bsM9ymQcVqVDWMTbeiYJ9G4PENtioFBrtt8ODfgCOkJ3fQsnxRzMX85JE9FresmcLq2QEvu+un4u3JzmeYFfIL2QhrwmfdlR0=; X-YMail-OSG: jWiDmPgVM1lNuTABUp_R5R.4uOcZSPl2W99XnHoqXr5cbEk.sdEwApJ45h_eg.bnPuPcBpc0Hyhqk2tm5ohMxa8Q6NLKI4w62ocm681t4qGYeyJHeQontWPiVwKyFG4kt7aCRMaKSu5n.AKRppCtHb7BjETOqKVARnRM44f.E7DtP8souc66W.q89xfvaAPS4T3PK26OU523Wk7UbEtrFUONHto- Received: from [75.214.176.151] by web82603.mail.mud.yahoo.com via HTTP; Tue, 17 Feb 2009 16:01:53 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: Date: Tue, 17 Feb 2009 16:01:53 -0800 (PST) From: Charles Krinke To: Mark Lentczner , mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-389636200-1234915313=:20311" Message-ID: <934428.20311.qm@web82603.mail.mud.yahoo.com> Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:01:44 -0000 --0-389636200-1234915313=:20311 Content-Type: text/plain; charset=us-ascii This is a good idea, Mark, thank you very much. I am Charles Krinke and my OSGrid avatar name is "Charles Krinke" and on secondlife I am known as "Charlesk Bing". I am one of the OpenSim core developers and director of OSGrid. I have been working on OpenSim for about 2 years now and have been on SecondLife for about the same time. Charles ________________________________ From: Mark Lentczner To: mmox@ietf.org Sent: Tuesday, February 17, 2009 2:33:31 PM Subject: [mmox] Introductions Friends - As if the internet weren't already full of multiple monikers for everyone, many of us have only met in virtual worlds. I suspect that I've met some of you in person, via e-mail, and in Second Life, and that I don't know that all three of you are the same! Having so many multiple personalities shakes my own sense of self, so I thought I'd start a thread of introductions. I'll go first: I'm Mark Lentczner. I'm the Sr. Systems Architect at Linden Lab. I've been working on Second Life for over three years, mostly on evolving the architecture of this growing virtual world. Many of you know me from AWG meetings and my office hours as Zero Linden. Work Identities: e-mail: markl (at) lindenlab (dot) com web: https://wiki.secondlife.com/wiki/User:Zero_Linden Second Life: Zero Linden Personal Identities: web: http://www.ozonehouse.com/mark/ Second Life: Zarf Vantongerloo - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-389636200-1234915313=:20311 Content-Type: text/html; charset=us-ascii
This is a good idea, Mark, thank you very much.

I am Charles Krinke and my OSGrid avatar name is "Charles Krinke" and on secondlife I am known as "Charlesk Bing". I am one of the OpenSim core developers and director of OSGrid. I have been working on OpenSim for about 2 years now and have been on SecondLife for about the same time.

Charles


From: Mark Lentczner <markl@lindenlab.com>
To: mmox@ietf.org
Sent: Tuesday, February 17, 2009 2:33:31 PM
Subject: [mmox] Introductions

Friends -

As if the internet weren't already full of multiple monikers for everyone, many of us have only met in virtual worlds. I suspect that I've met some of you in person, via e-mail, and in Second Life, and that I don't know that all three of you are the same!

Having so many multiple personalities shakes my own sense of self, so I thought I'd start a thread of introductions. I'll go first:

I'm Mark Lentczner. I'm the Sr. Systems Architect at Linden Lab. I've been working on Second Life for over three years, mostly on evolving the architecture of this growing virtual world. Many of you know me from AWG meetings and my office hours as Zero Linden.

Work Identities:
    e-mail:            markl (at) lindenlab (dot) com
    web:            https://wiki.secondlife.com/wiki/User:Zero_Linden
    Second Life:         Zero Linden

Personal Identities:
    web:            http://www.ozonehouse.com/mark/
    Second Life:        Zarf Vantongerloo


    - Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

markl@lindenlab.com

Zero Linden
zero.linden@secondlife.com





_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--0-389636200-1234915313=:20311-- From john.hurliman@intel.com Tue Feb 17 16:16:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7E83A69FE for ; Tue, 17 Feb 2009 16:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzKuZTF-U9Fs for ; Tue, 17 Feb 2009 16:16:23 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 894B23A67A5 for ; Tue, 17 Feb 2009 16:16:23 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 17 Feb 2009 16:10:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,225,1233561600"; d="scan'208";a="666372636" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by fmsmga001.fm.intel.com with ESMTP; 17 Feb 2009 16:20:26 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Tue, 17 Feb 2009 17:16:33 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Tue, 17 Feb 2009 17:16:30 -0700 Thread-Topic: [mmox] The Story So Far... Thread-Index: AcmRWWnen2oFhocMSlWtWUF9yiQyiAAAGEzw Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:16:25 -0000 >-----Original Message----- >From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com] >Sent: Tuesday, February 17, 2009 3:42 PM >To: Hurliman, John >Cc: mmox@ietf.org >Subject: Re: [mmox] The Story So Far... > > >On Feb 17, 2009, at 3:09 PM, Hurliman, John wrote: > >>> While there is plenty to do and discuss in order to develop OGP >>> into a >>> fully workable protocol, we think it represents an initial shared >>> vision >>> of an interoperable protocol and hope it can evolve and grow in the >>> context of this group. >>> >>> - Mark Lentczner >>> >>> [1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol >> >> It's great to see the amount of work that is being brought to the >> table by Linden Lab and the Linden Lab Architecture Working Group >> (AWG) participants, and I hope as much of it as possible can be used >> to build an MMOX standard. I've been working on an LLIDL >> implementation among other things based on what Linden Lab has >> submitted as draft material. > >awesome! > >> It's my understanding that Open Grid Protocol (OGP) is a Linden Lab >> project; part of the Linden Lab AWG which had no active contributors >> that were also active developers of libSecondLife/libOpenMetaverse >> or OpenSim during the time the OGP protocols were designed. The >> "agent domain" concept in OGP terminology brings in a host of >> assumptions that are diametrically opposed to the goals of >> libOpenMetaverse and OpenSim (supporting millions of independent >> administrative domains and service providers). > >huh? there were a number of non-lindens who participated in the >development of OGP. the AWG does not, nor did it ever disallow >participation by libSL or libOMV contributors / committers. last >summer we demonstrated interoperability between Linden Lab's servers >and an OpenSim instance. we hope that members of the libSL and libOMV >teams will participate in MMOX. > I said "AWG had no active contributors that were also active developers of = libSecondLife/libOpenMetaverse or OpenSim during the time the OGP protocols= were designed". The participation by individuals that were not Linden Lab = employees does not mean that OGP is a joint effort between Linden Lab and t= he libOpenMetaverse or OpenSim projects, or that the OGP as it is drafted h= as support from the libomv/OpenSim communities. >the concept of an agent domain was defined explicitly to support many >different independent administrative domains. that is... though the >interoperability test last summer used the Linden agent domain, the >specification does not mandate a single agent domain. in fact, i >believe Christian Scholz (a non-linden) implemented his own Agent >Domain based on code from the PyOGP project. There is also frequent >mention in AWG meetings of an upcoming C# implementation of an Agent >Domain, again by a non Linden-Lab employee. The agent domain concept takes several independent services (identity, pres= ence, inventory) and lumps them together into a single trust domain. This i= nhibits the development of a widely distributed ecosystem like we find on t= he web today, and is really only convenient for large virtual world service= providers that already have a vertical stack of services. It also drags in= the assumption that there must be a backend communication layer between se= rvices such as inventory and simulation regions. John From cfk@pacbell.net Tue Feb 17 16:23:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250423A6B29 for ; Tue, 17 Feb 2009 16:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSC0d49++rBo for ; Tue, 17 Feb 2009 16:23:37 -0800 (PST) Received: from web82603.mail.mud.yahoo.com (web82603.mail.mud.yahoo.com [68.142.201.120]) by core3.amsl.com (Postfix) with SMTP id A78813A6B10 for ; Tue, 17 Feb 2009 16:23:37 -0800 (PST) Received: (qmail 42175 invoked by uid 60001); 18 Feb 2009 00:23:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=AThaCtbi2SQw/ntdz1PAtl2B9h1XQJ5FIYxr5qmHp1OXtAKfcFdeYtnR49xxP+PU3Ig7nCsRD6nI6vRmtc1Hq2z3+nILKl0M8EfjwS+dAndWuzn9gdUu1JytTWziBZja6wDh2c9kaCSvtkX9eP5ythbp1wRm5ks3HN/UoO9Pj/A=; X-YMail-OSG: gkot0.YVM1ml.fbU_ytsyoePoYWtbLj4h6O2NWINKpcZMGsRQxKHdVrlB4BAt8M.QcCytYLiLI_9TVqPhn8TKgm3TDoyWGxriJsrD2LigfqISZ8_HWnl0NMd6f8wByvZncjd1sERqUNhPBhyjKP1AeqTCVTM4sBf_35vcDurAse1S4fnREU5Wv5XY4MjtAIvQEm_iYuGHu4B3w-- Received: from [75.214.176.151] by web82603.mail.mud.yahoo.com via HTTP; Tue, 17 Feb 2009 16:23:49 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> Date: Tue, 17 Feb 2009 16:23:49 -0800 (PST) From: Charles Krinke To: "Hurliman, John" , "mmox@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-680604697-1234916629=:42147" Message-ID: <306449.42147.qm@web82603.mail.mud.yahoo.com> Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:23:39 -0000 --0-680604697-1234916629=:42147 Content-Type: text/plain; charset=us-ascii As I think about virtual worlds and interoperability, the metaphor of independent states or nations come to mind. So, I guess in thinking about interop between virtual worlds, we can either go down the secondlife/opensim type of path and try to fit all virtual worlds into that paradigm with agentdomains or UGAIM notions or we could step back a bit and consider interop between secondlife/opensim/Wow/croquet/wonderland and others. Is is appropriate to start at a higher level and take a step back and consider the broader implications of virtual worlds beyond just our current paradigm such as WoW/croquet/wonderland and identify the minimum definition of network "plumbing" with that in mind? Charles ________________________________ From: "Hurliman, John" To: "mmox@ietf.org" Sent: Tuesday, February 17, 2009 4:16:30 PM Subject: Re: [mmox] The Story So Far... >-----Original Message----- >From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com] >Sent: Tuesday, February 17, 2009 3:42 PM >To: Hurliman, John >Cc: mmox@ietf.org >Subject: Re: [mmox] The Story So Far... > > >On Feb 17, 2009, at 3:09 PM, Hurliman, John wrote: > >>> While there is plenty to do and discuss in order to develop OGP >>> into a >>> fully workable protocol, we think it represents an initial shared >>> vision >>> of an interoperable protocol and hope it can evolve and grow in the >>> context of this group. >>> >>> - Mark Lentczner >>> >>> [1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol >> >> It's great to see the amount of work that is being brought to the >> table by Linden Lab and the Linden Lab Architecture Working Group >> (AWG) participants, and I hope as much of it as possible can be used >> to build an MMOX standard. I've been working on an LLIDL >> implementation among other things based on what Linden Lab has >> submitted as draft material. > >awesome! > >> It's my understanding that Open Grid Protocol (OGP) is a Linden Lab >> project; part of the Linden Lab AWG which had no active contributors >> that were also active developers of libSecondLife/libOpenMetaverse >> or OpenSim during the time the OGP protocols were designed. The >> "agent domain" concept in OGP terminology brings in a host of >> assumptions that are diametrically opposed to the goals of >> libOpenMetaverse and OpenSim (supporting millions of independent >> administrative domains and service providers). > >huh? there were a number of non-lindens who participated in the >development of OGP. the AWG does not, nor did it ever disallow >participation by libSL or libOMV contributors / committers. last >summer we demonstrated interoperability between Linden Lab's servers >and an OpenSim instance. we hope that members of the libSL and libOMV >teams will participate in MMOX. > I said "AWG had no active contributors that were also active developers of libSecondLife/libOpenMetaverse or OpenSim during the time the OGP protocols were designed". The participation by individuals that were not Linden Lab employees does not mean that OGP is a joint effort between Linden Lab and the libOpenMetaverse or OpenSim projects, or that the OGP as it is drafted has support from the libomv/OpenSim communities. >the concept of an agent domain was defined explicitly to support many >different independent administrative domains. that is... though the >interoperability test last summer used the Linden agent domain, the >specification does not mandate a single agent domain. in fact, i >believe Christian Scholz (a non-linden) implemented his own Agent >Domain based on code from the PyOGP project. There is also frequent >mention in AWG meetings of an upcoming C# implementation of an Agent >Domain, again by a non Linden-Lab employee. The agent domain concept takes several independent services (identity, presence, inventory) and lumps them together into a single trust domain. This inhibits the development of a widely distributed ecosystem like we find on the web today, and is really only convenient for large virtual world service providers that already have a vertical stack of services. It also drags in the assumption that there must be a backend communication layer between services such as inventory and simulation regions. John _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-680604697-1234916629=:42147 Content-Type: text/html; charset=us-ascii
As I think about virtual worlds and interoperability, the metaphor of independent states or nations come to mind. So, I guess in thinking about interop between virtual worlds, we can either go down the secondlife/opensim type of path and try to fit all virtual worlds into that paradigm with agentdomains or UGAIM notions or we could step back a bit and consider interop between secondlife/opensim/Wow/croquet/wonderland and others.

Is is appropriate to start at a higher level and take a step back and consider the broader implications of virtual worlds beyond just our current paradigm such as WoW/croquet/wonderland and identify the minimum definition of network "plumbing" with that in mind?

Charles

From: "Hurliman, John" <john.hurliman@intel.com>
To: "mmox@ietf.org" <mmox@ietf.org>
Sent: Tuesday, February 17, 2009 4:16:30 PM
Subject: Re: [mmox] The Story So Far...

>-----Original Message-----
>From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com]
>Sent: Tuesday, February 17, 2009 3:42 PM
>To: Hurliman, John
>Cc: mmox@ietf.org
>Subject: Re: [mmox] The Story So Far...
>
>
>On Feb 17, 2009, at 3:09 PM, Hurliman, John wrote:
>
>>> While there is plenty to do and discuss in order to develop OGP
>>> into a
>>> fully workable protocol, we think it represents an initial shared
>>> vision
>>> of an interoperable protocol and hope it can evolve and grow in the
>>> context of this group.
>>>
>>> - Mark Lentczner
>>>
>>> [1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol
>>
>> It's great to see the amount of work that is being brought to the
>> table by Linden Lab and the Linden Lab Architecture Working Group
>> (AWG) participants, and I hope as much of it as possible can be used
>> to build an MMOX standard. I've been working on an LLIDL
>> implementation among other things based on what Linden Lab has
>> submitted as draft material.
>
>awesome!
>
>> It's my understanding that Open Grid Protocol (OGP) is a Linden Lab
>> project; part of the Linden Lab AWG which had no active contributors
>> that were also active developers of libSecondLife/libOpenMetaverse
>> or OpenSim during the time the OGP protocols were designed. The
>> "agent domain" concept in OGP terminology brings in a host of
>> assumptions that are diametrically opposed to the goals of
>> libOpenMetaverse and OpenSim (supporting millions of independent
>> administrative domains and service providers).
>
>huh? there were a number of non-lindens who participated in the
>development of OGP. the AWG does not, nor did it ever disallow
>participation by libSL or libOMV contributors / committers. last
>summer we demonstrated interoperability between Linden Lab's servers
>and an OpenSim instance. we hope that members of the libSL and libOMV
>teams will participate in MMOX.
>

I said "AWG had no active contributors that were also active developers of libSecondLife/libOpenMetaverse or OpenSim during the time the OGP protocols were designed". The participation by individuals that were not Linden Lab employees does not mean that OGP is a joint effort between Linden Lab and the libOpenMetaverse or OpenSim projects, or that the OGP as it is drafted has support from the libomv/OpenSim communities.

>the concept of an agent domain was defined explicitly to support many
>different independent administrative domains. that is... though the
>interoperability test last summer used the Linden agent domain, the
>specification does not mandate a single agent domain. in fact, i
>believe Christian Scholz (a non-linden) implemented his own Agent
>Domain based on code from the PyOGP project. There is also frequent
>mention in AWG meetings of an upcoming C# implementation of an Agent
>Domain, again by a non Linden-Lab employee.

The agent domain concept takes several independent services (identity, presence, inventory) and lumps them together into a single trust domain. This inhibits the development of a widely distributed ecosystem like we find on the web today, and is really only convenient for large virtual world service providers that already have a vertical stack of services. It also drags in the assumption that there must be a backend communication layer between services such as inventory and simulation regions.

John
_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--0-680604697-1234916629=:42147-- From cs@comlounge.net Tue Feb 17 16:25:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7863A6982 for ; Tue, 17 Feb 2009 16:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxPse6DztqWk for ; Tue, 17 Feb 2009 16:25:28 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 4965A3A69CC for ; Tue, 17 Feb 2009 16:25:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 007481CE037A; Wed, 18 Feb 2009 01:25:34 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMv8uV4qSebs; Wed, 18 Feb 2009 01:25:33 +0100 (CET) Received: from [192.168.178.40] (pD9EBEAE0.dip.t-dialin.net [217.235.234.224]) by post.comlounge.net (Postfix) with ESMTP id E31B21CE0378; Wed, 18 Feb 2009 01:25:32 +0100 (CET) Message-ID: <499B557A.2010106@comlounge.net> Date: Wed, 18 Feb 2009 01:25:30 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Hurliman, John" References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:25:29 -0000 Hi! Hurliman, John schrieb: > > The agent domain concept takes several independent services (identity, presence, inventory) and lumps them together into a single trust domain. This inhibits the development of a widely distributed ecosystem like we find on the web today, and is really only convenient for large virtual world service providers that already have a vertical stack of services. It also drags in the assumption that there must be a backend communication layer between services such as inventory and simulation regions. Speaking of the web: There are already a lot of social networks out there which are right now going to work on interoperability regarding profile data, activity streams, authentication and general authorization (based on efforts like OAuth (now also here at IETF), OpenID, OpenSocial, PortableContacts, XRDS-Simple etc.). It would be great if these efforts can be integrated so that we don't have the problem in the end to bring web and virtual world together although both have basically the same idea of distributed services (and even partly the same services). So let me ask in the question: Is this of general interest for this group to try to bridge that web/VW gap as well? I think it would be of value because many of the protocols are already in use and thus are understood, have library support and so on. That being said IMHO the Agent Domain really could be far more separated into separate services. All you maybe need is one starting point for your identity and some service catalogue which lists where all the other services are, either your individual ones (where is my profile, where are my group memberships) or service level ones (where is the region info, which login methods do you support). -- Christian -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From gareth@litesim.com Tue Feb 17 16:29:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F15B33A69EC for ; Tue, 17 Feb 2009 16:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esf0a7M8-riB for ; Tue, 17 Feb 2009 16:29:40 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 83D843A6B7A for ; Tue, 17 Feb 2009 16:29:38 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2175727rvb.49 for ; Tue, 17 Feb 2009 16:29:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.142.11 with SMTP id p11mr636708rvd.206.1234916989362; Tue, 17 Feb 2009 16:29:49 -0800 (PST) In-Reply-To: <306449.42147.qm@web82603.mail.mud.yahoo.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> <306449.42147.qm@web82603.mail.mud.yahoo.com> Date: Wed, 18 Feb 2009 00:29:49 +0000 Message-ID: <61dbdd7d0902171629t7fd6bf4ep14d13b2852eef567@mail.gmail.com> From: Gareth Nelson To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:29:41 -0000 > Is is appropriate to start at a higher level and take a step back and > consider the broader implications of virtual worlds beyond just our current > paradigm such as WoW/croquet/wonderland and identify the minimum definition > of network "plumbing" with that in mind? Bingo! Identify a solid core, then put extensions on that solid core From robla@lindenlab.com Tue Feb 17 16:49:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673E628C1C6 for ; Tue, 17 Feb 2009 16:49:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrqI+PD+eBsw for ; Tue, 17 Feb 2009 16:49:17 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id C9B6A28C131 for ; Tue, 17 Feb 2009 16:49:17 -0800 (PST) Received: from [192.168.1.108] (c-98-232-63-20.hsd1.wa.comcast.net [98.232.63.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 05E893DBC06C for ; Tue, 17 Feb 2009 16:49:28 -0800 (PST) Message-ID: <499B5B18.6000806@lindenlab.com> Date: Tue, 17 Feb 2009 16:49:28 -0800 From: Rob Lanphier User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 CC: mmox@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:49:18 -0000 Hi all, I'm Rob Lanphier, Director of Open Source at Linden Lab. I've been here for a little over a couple of years now, working mainly on issues related to the publication of the Second Life viewer under GPL. I get wrapped up in open standards work due to my previous work in the IETF's MMUSIC working group on RTSP. I'm particularly interested in working in working groups beginning with "MM", though I sometimes care what the "MM" actually stands for. Rob From infinity@lindenlab.com Tue Feb 17 16:59:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB263A6A1A for ; Tue, 17 Feb 2009 16:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 096YxU6c26KM for ; Tue, 17 Feb 2009 16:59:12 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id C9E1B3A6A1F for ; Tue, 17 Feb 2009 16:59:12 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id B85F13DBC06C; Tue, 17 Feb 2009 16:59:24 -0800 (PST) Message-Id: <958A0461-3E36-4329-BD8E-5D0566307725@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: "Hurliman, John" In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 16:59:24 -0800 References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:59:13 -0000 since when? the current implementation does, but the protocol definition is pretty explicit that you cannot assume that just because you authenticate to "host a" that the cap that will be granted to rez in world or to access inventory won't be on "host b" or "host c". I'm happy to start the discussion about whether identity should explicitly be divorced from authentication, so identification can be deferred to an even different host. people have been talking about them being in the same administrative domain because we have no OAuth like mechanism defined to provide a non-forgeable authenticator that can be consumed by a third party. that is to say... the spec does not mandate that identity, presence and inventory be managed by the same administrative domain, it's just that doing that seems to give peeps the security heebie-jeebies. what you are asking appears to be the same as a Google service exposing a sensitive resource (maybe the right to read your gmail) to Yahoo! or Microsoft, but not REQUIRING that Yahoo! or Microsoft provide an authenticator indicating they have that right. one of the reasons we're participating in the IETF is the wealth of experience this brings us in terms of people familiar with all sorts of enabling technologies (including things like TLS, HTTP, OAuth, etc.) On Feb 17, 2009, at 4:16 PM, Hurliman, John wrote: > The agent domain concept takes several independent services > (identity, presence, inventory) and lumps them together into a > single trust domain. This inhibits the development of a widely > distributed ecosystem like we find on the web today, and is really > only convenient for large virtual world service providers that > already have a vertical stack of services. It also drags in the > assumption that there must be a backend communication layer between > services such as inventory and simulation regions. From john.hurliman@intel.com Tue Feb 17 17:01:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5099A3A6839 for ; Tue, 17 Feb 2009 17:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk2ETbyxNmHA for ; Tue, 17 Feb 2009 17:01:56 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id EA75E3A6403 for ; Tue, 17 Feb 2009 17:01:55 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 17 Feb 2009 16:55:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,225,1233561600"; d="scan'208";a="387631019" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga002.jf.intel.com with ESMTP; 17 Feb 2009 17:10:56 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Tue, 17 Feb 2009 18:02:07 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Tue, 17 Feb 2009 18:02:04 -0700 Thread-Topic: [mmox] The Story So Far... Thread-Index: AcmRX3P8/ItWynQxSPmScQnvQ99bHQABGHtQ Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FDD32@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> <499B557A.2010106@comlounge.net> In-Reply-To: <499B557A.2010106@comlounge.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:01:57 -0000 The proposal for a virtual world identity service that I've been typing awa= y at uses OpenID, OpenID Attribute Exchange, and OpenID Token Exchange to d= efine a base set of interfaces and attributes for virtual world identity. I= n my opinion, there's a balancing act between asserting that virtual worlds= add nothing new to the equation and nothing needs to be developed, and ass= erting that virtual worlds are an entirely new problem and throwing away th= e last decade or more of work. John >-----Original Message----- >From: Christian Scholz [mailto:cs@comlounge.net] >Sent: Tuesday, February 17, 2009 4:25 PM >To: Hurliman, John >Cc: mmox@ietf.org >Subject: Re: [mmox] The Story So Far... > >Hi! > >Hurliman, John schrieb: > >> >> The agent domain concept takes several independent services (identity, >presence, inventory) and lumps them together into a single trust domain. >This inhibits the development of a widely distributed ecosystem like we >find on the web today, and is really only convenient for large virtual >world service providers that already have a vertical stack of services. >It also drags in the assumption that there must be a backend >communication layer between services such as inventory and simulation >regions. > >Speaking of the web: There are already a lot of social networks out >there which are right now going to work on interoperability regarding >profile data, activity streams, authentication and general authorization >(based on efforts like OAuth (now also here at IETF), OpenID, >OpenSocial, PortableContacts, XRDS-Simple etc.). > >It would be great if these efforts can be integrated so that we don't >have the problem in the end to bring web and virtual world together >although both have basically the same idea of distributed services (and >even partly the same services). > >So let me ask in the question: Is this of general interest for this >group to try to bridge that web/VW gap as well? > >I think it would be of value because many of the protocols are already >in use and thus are understood, have library support and so on. > >That being said IMHO the Agent Domain really could be far more separated >into separate services. All you maybe need is one starting point for >your identity and some service catalogue which lists where all the other >services are, either your individual ones (where is my profile, where >are my group memberships) or service level ones (where is the region >info, which login methods do you support). > >-- Christian > > >-- >Christian Scholz >Blog: http://mrtopf.de/blog >Company: http://comlounge.net >Podcasts: http://datawithoutborders.net, http://openweb-podcast.de >=20 From belxjander@gmail.com Tue Feb 17 16:48:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1DD28C1B8 for ; Tue, 17 Feb 2009 16:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZT9m3Acd+dn for ; Tue, 17 Feb 2009 16:48:50 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 229DB28C131 for ; Tue, 17 Feb 2009 16:48:49 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so1770387rvb.5 for ; Tue, 17 Feb 2009 16:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=rMu/5x68f3UE/D2urxi2yRLY1blv52LbL3wZQFMZOFI=; b=spxrnU9O1spmEn8XaCVlAp49ohMlGb7fftDqQxIgivxNTkuZNl+zWO7szLQwJ2S3Gf n0VWWZEu0CM8cgBOAZaHEqDHelq/zuOYRJ67O35NgqGc82y+4m1IiIhlX97Fhh8ZDLY0 u/BZxqaA3N8xpyIptkUFeKkDtSxsskGtrvcio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=rea+zytgQLoqVf2ls39fJDIUHl4NzUNhTRT8YcGO3qKImAMD1ImIRzXKydzHPGoUsF d//lIFxAxcat0RK9rbyA0teBDKuwWprtFiUTu7us03Co9UMfzgyVET8f9uSw0JofNs/H rGlhl53Qw78muInZ1Qo0iccc+ukhSMEl1sDUs= Received: by 10.141.116.16 with SMTP id t16mr3566773rvm.280.1234918140335; Tue, 17 Feb 2009 16:49:00 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id f21sm15256912rvb.2.2009.02.17.16.48.58 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Feb 2009 16:48:59 -0800 (PST) From: Kajikawa Jeremy To: mmox@ietf.org In-Reply-To: <548919.2383.qm@web82607.mail.mud.yahoo.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AgU+YIJ1Q0OjpGzlyrt1" Date: Wed, 18 Feb 2009 09:43:38 +0900 Message-Id: <1234917818.6664.51.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:02:12 -0000 --=-AgU+YIJ1Q0OjpGzlyrt1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I agree, with the pre-requisite for authentication and see that as being a "User" Services Account per-grid. With regards object transfer, I personally see each "grid of regions" as being an own-domain and only items "attached" to be transferred with the character. This opens the market for having "suitcase" attachments, the only items that I see as being standalone crossing between grid regions would be automated bot programs, and these need not keep the standard "AV". And limitation of transfer based based on ownership and complexity. Some things like scripts need to be hosted seperately for transfer to happen safely, to allow the region server a mechanism of limiting any harmful effects without loss of function in transfer. Also this would limit the loss of content and state issue that is currently present. -- With regards imagining like the early automobiles or early railways... certainly... However anything external to the AV or "detached" status may be blocked or otherwise have a substitute based on the new "grid" environments theme. I can imagine an Egyptian ferry being switched for an Italian taxi from Venice, or even a really big "leaf" if changing region to somewhere of an entirely different scale. switching grids need not keep scale, but the only thing needed to be kept would be some kind of central "airport" style mechanism that allows for being a "door" between the grids. Or do we allow anyone with permissions on two or more grids to "Teleport" to any location on a target grid entirely seperate from the former. --Idea-- What about splitting the Asset&Inventory services into having "User Storage" and "Region Storage"... anything free-floating is on region storage (grid local) and anything in "User Storage" is potentially cross-grid capable. However the first thing to cross grids apart from an AV for presence is going to be messaging from what I understand there is several backend options needing some kind of standard "Message" base able to be encoded for IM & Email,=20 I would request UTF8 encoding for this style of message(address:content) delivery then we can push towards having standardized i18n/i10n support with least effort. --Idea-- I remember a description of early LL teleporting needing a "hub" location. Why not allow unrestricted p2p teleports within the same grid of regions and when needing to transfer across regions using a special region on both grids with a "door" and key setup? This would allow a basic operational setup of something akin to Airport security with regards firewalling and also provide a "safe zone" with information about grid connections. Information about other grids need not be limited here, but it would be a start for some kind of standard to develop without requiring to push untested features to all regions in any grid Sincerely, Jeremy --=-AgU+YIJ1Q0OjpGzlyrt1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJm1m6AAoJECHrKutFYVwT+6gP/1Tw6AxcAFn9a/6aOE2mBB14 xyBfXw8chh5Ii7xHEjtrXG9gMUNxcX+2YIyitgeVcu4XK0RHD3sQqa1V1ri/YRpV wevBJ3DKptsYlifp5MgfrapKfJQcUkHbj1EnNCnZF1ihEULTifvtSL3p0lqAwPHD RKPBAs//1b7sgP5rDUIp9LLlCFjvxE5pASeub8XKPu+Yk7hW9DrtY05IuWbIMqOz 0KvkIxby1zPXFwxvxivKyewZ9LmQF8veaRUieeT0mQjylZbkfNwytf5eBzlERZYP ACQUwQG3A0Zlg6wJeGvyMaL6yt2glnNhmVulFZ9/s6iUotSlCAFGFi9RM5terQSe RO5cZxoCHomydmZBQpJ1Ksk4RZESYoG3I+qtl1dlNbhySsTtSq/tagmLLeBc2s1m x5mOlqLfNCbPbiHUyBHejCa13RRs9ndmZC4qe6nf1D3Y6wHlyZJo7cGZ6r/PF64j MSWU4DDblMWnrOjAfkb3ngo9Me2kOJmflf9s/3eI5jKzn9Nya8vTsri+OcB1AJz+ +uhg/OhQJIYM7oC/J3NUtR/ntbBc6+KKhDjzBrT8QqCFBdijODtYZFsRWGxHvC2V 7n1vD6EJ96+50nGzqI8DJT/YqQq6wjvRHgk3Jqm6fSJyqmn/bXPDouHeGzVEzGML S79XcPd3lOWzwTZmTepo =cN2W -----END PGP SIGNATURE----- --=-AgU+YIJ1Q0OjpGzlyrt1-- From infinity@lindenlab.com Tue Feb 17 17:09:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E679228C16F for ; Tue, 17 Feb 2009 17:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.567 X-Spam-Level: X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3BKBkP97NUp for ; Tue, 17 Feb 2009 17:09:13 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id CCFAA28C13D for ; Tue, 17 Feb 2009 17:09:13 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id BC7A83DBC06C; Tue, 17 Feb 2009 17:09:25 -0800 (PST) Message-Id: <3E2F33BB-0648-4101-BE28-58A164D3A66F@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: "Hurliman, John" In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FDD32@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 17:09:25 -0800 References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> <499B557A.2010106@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D501FDD32@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:09:15 -0000 cool. the existing OGP protocol can be "retasked" to carry OpenID information, though it was neither designed for this nor was there any public discussion about doing it. now that there's public discussion about doing it, lemme dig up my notes about some of the issues we thought we had with it and we can move forward with putting it into the protocol. On Feb 17, 2009, at 5:02 PM, Hurliman, John wrote: > The proposal for a virtual world identity service that I've been > typing away at uses OpenID, OpenID Attribute Exchange, and OpenID > Token Exchange to define a base set of interfaces and attributes for > virtual world identity. In my opinion, there's a balancing act > between asserting that virtual worlds add nothing new to the > equation and nothing needs to be developed, and asserting that > virtual worlds are an entirely new problem and throwing away the > last decade or more of work. > > John > >> -----Original Message----- >> From: Christian Scholz [mailto:cs@comlounge.net] >> Sent: Tuesday, February 17, 2009 4:25 PM >> To: Hurliman, John >> Cc: mmox@ietf.org >> Subject: Re: [mmox] The Story So Far... >> >> Hi! >> >> Hurliman, John schrieb: >> >>> >>> The agent domain concept takes several independent services >>> (identity, >> presence, inventory) and lumps them together into a single trust >> domain. >> This inhibits the development of a widely distributed ecosystem >> like we >> find on the web today, and is really only convenient for large >> virtual >> world service providers that already have a vertical stack of >> services. >> It also drags in the assumption that there must be a backend >> communication layer between services such as inventory and simulation >> regions. >> >> Speaking of the web: There are already a lot of social networks out >> there which are right now going to work on interoperability regarding >> profile data, activity streams, authentication and general >> authorization >> (based on efforts like OAuth (now also here at IETF), OpenID, >> OpenSocial, PortableContacts, XRDS-Simple etc.). >> >> It would be great if these efforts can be integrated so that we don't >> have the problem in the end to bring web and virtual world together >> although both have basically the same idea of distributed services >> (and >> even partly the same services). >> >> So let me ask in the question: Is this of general interest for this >> group to try to bridge that web/VW gap as well? >> >> I think it would be of value because many of the protocols are >> already >> in use and thus are understood, have library support and so on. >> >> That being said IMHO the Agent Domain really could be far more >> separated >> into separate services. All you maybe need is one starting point for >> your identity and some service catalogue which lists where all the >> other >> services are, either your individual ones (where is my profile, where >> are my group memberships) or service level ones (where is the region >> info, which login methods do you support). >> >> -- Christian >> >> >> -- >> Christian Scholz >> Blog: http://mrtopf.de/blog >> Company: http://comlounge.net >> Podcasts: http://datawithoutborders.net, http://openweb-podcast.de >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From cs@comlounge.net Tue Feb 17 17:20:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC32D3A69CC for ; Tue, 17 Feb 2009 17:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al9jVqavfdb3 for ; Tue, 17 Feb 2009 17:20:21 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 047133A6800 for ; Tue, 17 Feb 2009 17:20:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 844901CE037D; Wed, 18 Feb 2009 02:20:31 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9uY+cOJF4Zd; Wed, 18 Feb 2009 02:20:28 +0100 (CET) Received: from [192.168.178.40] (pD9EBE698.dip.t-dialin.net [217.235.230.152]) by post.comlounge.net (Postfix) with ESMTP id AA4431CE0378; Wed, 18 Feb 2009 02:20:26 +0100 (CET) Message-ID: <499B6259.6080808@comlounge.net> Date: Wed, 18 Feb 2009 02:20:25 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Hurliman, John" References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> <499B557A.2010106@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D501FDD32@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FDD32@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:20:26 -0000 Hurliman, John schrieb: > The proposal for a virtual world identity service that I've been typing away at uses OpenID, OpenID Attribute Exchange, and OpenID Token Exchange to define a base set of interfaces and attributes for virtual world identity. In my opinion, there's a balancing act between asserting that virtual worlds add nothing new to the equation and nothing needs to be developed, and asserting that virtual worlds are an entirely new problem and throwing away the last decade or more of work. Sounds cool, looking forward to it. As for the balancing act: Of course there is a lot new which virtual worlds bring but there is also a lot in common with social networks, such as identity, profiles, groups, IM, assets. What's new is of course the actual 3D part of it. But you might see this "just" as an additional service to offer. Of course it's a rather big service and it might need additional ties into esp. the asset realm. And on the web as on VWs people are thinking hard about how to enable identities across networks so my hope is that both solutions are somewhat compatible :-) (as said, the keywords there are OpenID, OAuth and OpenSocial. Microformats are also used but of course those are eventually a bit out of scope for VW based systems which might not necessarily have web pages attached). But in general I think it would be cool if I could login to some virtual world with my Yahoo OpenID and use my MySpace profile information plus find contacts from e.g. MySpace as well. This actually is not really far off as Yahoo supports OpenID and MySpace supports OAuth and OpenSocial. So some parts are already in place. -- Christian PS: When I say OpenSocial I mean the REST API which allows you to read/write profile information, contacts etc. Not the gadget stuff. The only problem with it might be that the profile schema has not all the fields needed for virtual worlds, like location has a completely different semantic here. But such things can be fixed I guess. > > John > >> -----Original Message----- >> From: Christian Scholz [mailto:cs@comlounge.net] >> Sent: Tuesday, February 17, 2009 4:25 PM >> To: Hurliman, John >> Cc: mmox@ietf.org >> Subject: Re: [mmox] The Story So Far... >> >> Hi! >> >> Hurliman, John schrieb: >> >>> The agent domain concept takes several independent services (identity, >> presence, inventory) and lumps them together into a single trust domain. >> This inhibits the development of a widely distributed ecosystem like we >> find on the web today, and is really only convenient for large virtual >> world service providers that already have a vertical stack of services. >> It also drags in the assumption that there must be a backend >> communication layer between services such as inventory and simulation >> regions. >> >> Speaking of the web: There are already a lot of social networks out >> there which are right now going to work on interoperability regarding >> profile data, activity streams, authentication and general authorization >> (based on efforts like OAuth (now also here at IETF), OpenID, >> OpenSocial, PortableContacts, XRDS-Simple etc.). >> >> It would be great if these efforts can be integrated so that we don't >> have the problem in the end to bring web and virtual world together >> although both have basically the same idea of distributed services (and >> even partly the same services). >> >> So let me ask in the question: Is this of general interest for this >> group to try to bridge that web/VW gap as well? >> >> I think it would be of value because many of the protocols are already >> in use and thus are understood, have library support and so on. >> >> That being said IMHO the Agent Domain really could be far more separated >> into separate services. All you maybe need is one starting point for >> your identity and some service catalogue which lists where all the other >> services are, either your individual ones (where is my profile, where >> are my group memberships) or service level ones (where is the region >> info, which login methods do you support). >> >> -- Christian >> >> >> -- >> Christian Scholz >> Blog: http://mrtopf.de/blog >> Company: http://comlounge.net >> Podcasts: http://datawithoutborders.net, http://openweb-podcast.de >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From cs@comlounge.net Tue Feb 17 17:26:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23B23A69FF for ; Tue, 17 Feb 2009 17:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWXqFa1B1wfT for ; Tue, 17 Feb 2009 17:26:21 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 62C9F3A6941 for ; Tue, 17 Feb 2009 17:26:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id BB6541CE037D; Wed, 18 Feb 2009 02:26:32 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-a27Y7k14Ue; Wed, 18 Feb 2009 02:26:23 +0100 (CET) Received: from [192.168.178.40] (pD9EBE698.dip.t-dialin.net [217.235.230.152]) by post.comlounge.net (Postfix) with ESMTP id ACF191CE0378; Wed, 18 Feb 2009 02:26:19 +0100 (CET) Message-ID: <499B63B9.90102@comlounge.net> Date: Wed, 18 Feb 2009 02:26:17 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> <499B557A.2010106@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D501FDD32@rrsmsx506.amr.corp.intel.com> <3E2F33BB-0648-4101-BE28-58A164D3A66F@lindenlab.com> In-Reply-To: <3E2F33BB-0648-4101-BE28-58A164D3A66F@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:26:22 -0000 Meadhbh Hamrick (Infinity) schrieb: > cool. the existing OGP protocol can be "retasked" to carry OpenID > information, though it was neither designed for this nor was there any > public discussion about doing it. > > now that there's public discussion about doing it, lemme dig up my notes > about some of the issues we thought we had with it and we can move > forward with putting it into the protocol. That sounds great and I would be very interested in the issues (and maybe the openid mailing list as well). Would be great to actually also have that implemented in the client ;-) Another idea might here be though to use OAuth for the client as well. It would then basically work like the flickr uploadr works by opening a web site where you confirm access and by some token exchange in the background. This would eliminate the problem of needing a web browser for OpenID (but might have security implications as you give full access and are not asked for a password again for some amount of time). But just brainstorming here.. definitely a problem which needs to get tackled regarding OpenID in general as more and more devices might not have a web browser or maybe are too annoying to use that way. -- Christian > > On Feb 17, 2009, at 5:02 PM, Hurliman, John wrote: > >> The proposal for a virtual world identity service that I've been >> typing away at uses OpenID, OpenID Attribute Exchange, and OpenID >> Token Exchange to define a base set of interfaces and attributes for >> virtual world identity. In my opinion, there's a balancing act between >> asserting that virtual worlds add nothing new to the equation and >> nothing needs to be developed, and asserting that virtual worlds are >> an entirely new problem and throwing away the last decade or more of >> work. >> >> John >> >>> -----Original Message----- >>> From: Christian Scholz [mailto:cs@comlounge.net] >>> Sent: Tuesday, February 17, 2009 4:25 PM >>> To: Hurliman, John >>> Cc: mmox@ietf.org >>> Subject: Re: [mmox] The Story So Far... >>> >>> Hi! >>> >>> Hurliman, John schrieb: >>> >>>> >>>> The agent domain concept takes several independent services (identity, >>> presence, inventory) and lumps them together into a single trust domain. >>> This inhibits the development of a widely distributed ecosystem like we >>> find on the web today, and is really only convenient for large virtual >>> world service providers that already have a vertical stack of services. >>> It also drags in the assumption that there must be a backend >>> communication layer between services such as inventory and simulation >>> regions. >>> >>> Speaking of the web: There are already a lot of social networks out >>> there which are right now going to work on interoperability regarding >>> profile data, activity streams, authentication and general authorization >>> (based on efforts like OAuth (now also here at IETF), OpenID, >>> OpenSocial, PortableContacts, XRDS-Simple etc.). >>> >>> It would be great if these efforts can be integrated so that we don't >>> have the problem in the end to bring web and virtual world together >>> although both have basically the same idea of distributed services (and >>> even partly the same services). >>> >>> So let me ask in the question: Is this of general interest for this >>> group to try to bridge that web/VW gap as well? >>> >>> I think it would be of value because many of the protocols are already >>> in use and thus are understood, have library support and so on. >>> >>> That being said IMHO the Agent Domain really could be far more separated >>> into separate services. All you maybe need is one starting point for >>> your identity and some service catalogue which lists where all the other >>> services are, either your individual ones (where is my profile, where >>> are my group memberships) or service level ones (where is the region >>> info, which login methods do you support). >>> >>> -- Christian >>> >>> >>> -- >>> Christian Scholz >>> Blog: http://mrtopf.de/blog >>> Company: http://comlounge.net >>> Podcasts: http://datawithoutborders.net, http://openweb-podcast.de >>> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From dwl@us.ibm.com Tue Feb 17 17:43:43 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECB933A698C; Tue, 17 Feb 2009 17:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdYDPn+Wmc4c; Tue, 17 Feb 2009 17:43:43 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id E80B13A69CC; Tue, 17 Feb 2009 17:43:42 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e7.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1I1ZrSx012963; Tue, 17 Feb 2009 20:35:53 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1I1hrUV190156; Tue, 17 Feb 2009 20:43:53 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1I1gi6t003999; Tue, 17 Feb 2009 20:42:44 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1I1giOq003994; Tue, 17 Feb 2009 20:42:44 -0500 In-Reply-To: <499B5B18.6000806@lindenlab.com> To: Rob Lanphier MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Tue, 17 Feb 2009 20:43:53 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/17/2009 20:43:53, Serialize complete at 02/17/2009 20:43:53 Content-Type: multipart/alternative; boundary="=_alternative 000982A685257561_=" Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:43:44 -0000 This is a multipart message in MIME format. --=_alternative 000982A685257561_= Content-Type: text/plain; charset="US-ASCII" Greetings All: I'm David Levine, I work for IBM Research on Virtual Worlds Interoperability and Immersive Collaboration Technologies. I've spent the past 18 months working on various parts of IBM's virtual worlds research and strategy, including coding our contribution to the OpenSim implementation of the Linden OGP teleport work. My interest in the MMOX work is a direct outgrowth of IBM's work with OGP and our ongoing involvement in OpenSim and a number of other virtual world environments. If you see me on Second Life, it will most likely be as "Zha Ewry" tho, on rare occasions I can be found as "David Levine." I've done standards work with the W3C, Oasis, the Object Management Group, Sun's Java Community Process and a wonderfully obscure group known as FIPA. I am a believer that working code, and practical lessons learned from actual implementations are necessary guides toward working standards, but that simply enshrining existing code is insufficient, as it most often embodies a series of compromises which have more to do with the history of the code and ideal design. I host a weekly discussion in Second Life on topics of interest to the Interop and MMOX community, and am looking to host sessions on at least one of the public OpenSim servers as well, and would be delighted to look at hosting sessions in other worlds, as long as this can be done in an non-exclusionary fashion. Anyone interested in he Second Life discussions can find us at 9:30 AM Second Life Time on Tuesday, contact me inworld for an invite. Contact information: dwl at us dot ibm dot com and zha dot ewry at gmail dot com - David W. Levine ~ Zha Ewry (ISL) --=_alternative 000982A685257561_= Content-Type: text/html; charset="US-ASCII"
Greetings All:

I'm David Levine, I work for IBM Research on Virtual Worlds Interoperability and Immersive Collaboration Technologies.
I've spent the past 18 months working on various parts of IBM's virtual worlds research and strategy, including coding our
contribution to the OpenSim implementation of the Linden OGP teleport work. My interest in the MMOX work is a direct
outgrowth of IBM's work with OGP and our ongoing involvement in OpenSim and a number of other virtual world environments.
If you see me on Second Life, it will most likely be as "Zha Ewry" tho, on rare occasions I can be found as "David Levine."

I've done standards work with the W3C, Oasis,  the Object Management Group, Sun's Java Community Process and a
wonderfully obscure group known as FIPA. I am a believer that working code, and practical lessons learned from actual
implementations are necessary guides toward working standards, but that simply enshrining existing code is insufficient, as
it most often embodies a series of compromises which have more to do with the history of the code and ideal design.

I host a weekly discussion in Second Life on topics of interest to the Interop and MMOX community, and am looking to
host sessions on at least one of the public OpenSim servers as well, and would be delighted to look at hosting sessions
in other worlds, as long as this can be done in an non-exclusionary fashion. Anyone interested in he Second Life
discussions can find us at 9:30 AM Second Life Time on Tuesday, contact me inworld for an invite.

Contact information: dwl at us dot ibm dot com
                                and zha dot ewry at gmail dot com

- David W. Levine
~ Zha Ewry (ISL)
--=_alternative 000982A685257561_=-- From gareth@litesim.com Tue Feb 17 17:52:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661E828C1C6 for ; Tue, 17 Feb 2009 17:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6Ht4ykZvhUz for ; Tue, 17 Feb 2009 17:52:38 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 81BE928C1C5 for ; Tue, 17 Feb 2009 17:52:38 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so1795447rvb.5 for ; Tue, 17 Feb 2009 17:52:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.28.2 with SMTP id f2mr2452728rvj.170.1234921968086; Tue, 17 Feb 2009 17:52:48 -0800 (PST) In-Reply-To: <958A0461-3E36-4329-BD8E-5D0566307725@lindenlab.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> <958A0461-3E36-4329-BD8E-5D0566307725@lindenlab.com> Date: Wed, 18 Feb 2009 01:52:48 +0000 Message-ID: <61dbdd7d0902171752h6f4531e1yacef83a077028e69@mail.gmail.com> From: Gareth Nelson To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:52:39 -0000 > the current implementation does, but the protocol definition is pretty > explicit that you cannot assume that just because you authenticate to "host > a" that the cap that will be granted to rez in world or to access inventory > won't be on "host b" or "host c". I'm happy to start the discussion about > whether identity should explicitly be divorced from authentication, so > identification can be deferred to an even different host. I believe that it would be quite trivial to have separate identity provider services which merely point at other services that are hosted by the same provider or hosted somewhere else. For example, I can picture something like this in the login response: {'inventory':'https://providera.com/inv/', 'im':'https://providerb.com/im/'} > people have been talking about them being in the same administrative domain > because we have no OAuth like mechanism defined to provide a non-forgeable > authenticator that can be consumed by a third party. Is it not that people have been lumping them into one domain because for the most part we only have single domains right now? When was the last time someone realistically had any means to "mount" their inventory from say OSGrid and Second Life, with identity being hosted somewhere else and then logging into some random region domain? > what you are asking appears to be the same as a Google service exposing a > sensitive resource (maybe the right to read your gmail) to Yahoo! or > Microsoft, but not REQUIRING that Yahoo! or Microsoft provide an > authenticator indicating they have that right. The capability URL is the proof that they have the right :) I'd go so far as to say that we need a proxy-type service for generating new limited caps URLs that can be revoked by the user From gareth@litesim.com Tue Feb 17 18:01:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 539B128C1D4 for ; Tue, 17 Feb 2009 18:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQWQylA0xiyj for ; Tue, 17 Feb 2009 18:01:17 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id A8D573A6A21 for ; Tue, 17 Feb 2009 18:01:17 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2208218rvb.49 for ; Tue, 17 Feb 2009 18:01:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.33.19 with SMTP id l19mr3617088rvj.91.1234922488085; Tue, 17 Feb 2009 18:01:28 -0800 (PST) Date: Wed, 18 Feb 2009 02:01:28 +0000 Message-ID: <61dbdd7d0902171801t16617ae5n59e170d2a31235ba@mail.gmail.com> From: Gareth Nelson To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mmox] A few assumptions if I may X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 02:01:18 -0000 1 - We need an absolute basic core of identity 2 - We need a modular design where extra services (simple stuff such as chat and inventory) are bolted onto that core with mechanisms such as optional caps URLs (man I love caps) 3 - On the "intellectual property" issue, we should take the view that if a particular system is serving up an asset, it is authorised to do so - in other words, if you can do (for example) an HTTP GET on an object, it may come with permissions flags in the metadata, but we should enforce these flags only on end systems - clients, inventory servers, asset servers and simulators - this simplifies the legal issues and pushes liability to where it belongs, with the users 4 - This should be obvious, but anything intended for an actual RFC should be 100% neutral of any particular virtual world/MMO or platform, so stuff like the .NET remoting in opensim (a pet peeve of mine) is out 5 - Binary protocols should be used whenever efficiency is important, but designed in an extensible fashion such that one particular packet type once defined will always mean the same thing and systems implementing such protocols can rely on a core set of messages always being available with graceful degradation for anything outside of this core - we need not see the whole world through HTTP-tinted glasses From missannotoole@yahoo.com Tue Feb 17 18:18:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4B83A69FF for ; Tue, 17 Feb 2009 18:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JYtKnx9tciT for ; Tue, 17 Feb 2009 18:18:17 -0800 (PST) Received: from web59104.mail.re1.yahoo.com (web59104.mail.re1.yahoo.com [66.196.101.15]) by core3.amsl.com (Postfix) with SMTP id 9783C3A6941 for ; Tue, 17 Feb 2009 18:18:17 -0800 (PST) Received: (qmail 39047 invoked by uid 60001); 18 Feb 2009 02:18:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1234923509; bh=Ay3ezolb5xktwkmPcrs26hRqJXI61mp8ofStqj4QE70=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=FzC4Q7AuJCmlHMuYxApYlezE2SUhsM4d0MwtZf+ziB+eGQMebD0gh5vUWrk5HiXU0yuCOvOY6k4dTRqhR/y2vK8OuPIDIo+nrArwTRL3E3nNVog5d3fZhMch8PUS4ctkzTUg2mGvOILcFcnY8kYqFsRVWTUXGopXY9CxOFgrNxI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=q2TWoFWhP5KdCGkaFYdY8u6+oIeJBCwCGiWPAR62hB/YaqM0zc9EfB2w95Gn2PVfEzXOEp4kKAL9uX2fYM0XWHwp1WlPsBk1lqO5zQ+lWETp4juWFPVJLL3ub+Nq25X+qhRgoI3y+HDOhLZGC4JWxhX1SG2gOOZYyI3BCbQbTXc=; Message-ID: <77186.32658.qm@web59104.mail.re1.yahoo.com> X-YMail-OSG: O.d8uPgVM1m2O4AB7TuHNkeL0GFHL7yF95O_zUWEpmB3AuXInBOJrGhwtSoYm8BrLsRfuH6zDSuWrFw7vYsmRv3xTAS1O8OFZVLamzXPIueGB86INMoicYaS1sQLBEIHqJJmLAfM6M2o4vJ_J5qd0l2JdrQ66Eslf5irLwaFpBathAgkFSCsgCtM4kPV2xxqYCxWulUiEIGfx.S_wRYKm3p8YZK4S6PBitoy15NPMf_fqWI- Received: from [97.102.254.236] by web59104.mail.re1.yahoo.com via HTTP; Tue, 17 Feb 2009 18:18:28 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> Date: Tue, 17 Feb 2009 18:18:28 -0800 (PST) From: Ann Otoole To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1457113820-1234923508=:32658" Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 02:19:22 -0000 --0-1457113820-1234923508=:32658 Content-Type: text/plain; charset=us-ascii My opinion is that interop would be best served through a standard mesh and texture subsystem on all grids and teleport between grids consists of transferring the mesh and associated textures (if not already present in the target grid asset system) over followed by initialization of the avatar using the mesh and textures for baking. Leave attachments for the future (if they ever become needed at that point since most people will not look back with real meshes and textures done right). Just a thought towards making ubiquitous interop materially feasible in the next couple of years anyway. For the IP thing the license would obviously be for the avatar mesh holder to wear/use anywhere in the metaverse. ________________________________ From: Kajikawa Jeremy To: mmox@ietf.org Sent: Tuesday, February 17, 2009 7:43:38 PM Subject: [mmox] User Accounts / "Object" Transfer. I agree, with the pre-requisite for authentication and see that as being a "User" Services Account per-grid. With regards object transfer, I personally see each "grid of regions" as being an own-domain and only items "attached" to be transferred with the character. This opens the market for having "suitcase" attachments, the only items that I see as being standalone crossing between grid regions would be automated bot programs, and these need not keep the standard "AV". And limitation of transfer based based on ownership and complexity. Some things like scripts need to be hosted seperately for transfer to happen safely, to allow the region server a mechanism of limiting any harmful effects without loss of function in transfer. Also this would limit the loss of content and state issue that is currently present. -- With regards imagining like the early automobiles or early railways... certainly... However anything external to the AV or "detached" status may be blocked or otherwise have a substitute based on the new "grid" environments theme. I can imagine an Egyptian ferry being switched for an Italian taxi from Venice, or even a really big "leaf" if changing region to somewhere of an entirely different scale. switching grids need not keep scale, but the only thing needed to be kept would be some kind of central "airport" style mechanism that allows for being a "door" between the grids. Or do we allow anyone with permissions on two or more grids to "Teleport" to any location on a target grid entirely seperate from the former. --Idea-- What about splitting the Asset&Inventory services into having "User Storage" and "Region Storage"... anything free-floating is on region storage (grid local) and anything in "User Storage" is potentially cross-grid capable. However the first thing to cross grids apart from an AV for presence is going to be messaging from what I understand there is several backend options needing some kind of standard "Message" base able to be encoded for IM & Email, I would request UTF8 encoding for this style of message(address:content) delivery then we can push towards having standardized i18n/i10n support with least effort. --Idea-- I remember a description of early LL teleporting needing a "hub" location. Why not allow unrestricted p2p teleports within the same grid of regions and when needing to transfer across regions using a special region on both grids with a "door" and key setup? This would allow a basic operational setup of something akin to Airport security with regards firewalling and also provide a "safe zone" with information about grid connections. Information about other grids need not be limited here, but it would be a start for some kind of standard to develop without requiring to push untested features to all regions in any grid Sincerely, Jeremy --0-1457113820-1234923508=:32658 Content-Type: text/html; charset=us-ascii
My opinion is that interop would be best served through a standard mesh and texture subsystem on all grids and teleport between grids consists of transferring the mesh and associated textures (if not already present in the target grid asset system) over followed by initialization of the avatar using the mesh and textures for baking. Leave attachments for the future (if they ever become needed at that point since most people will not look back with real meshes and textures done right).

Just a thought towards making ubiquitous interop materially feasible in the next couple of years anyway.

For the IP thing the license would obviously be for the avatar mesh holder to wear/use anywhere in the metaverse.

From: Kajikawa Jeremy <belxjander@gmail.com>
To: mmox@ietf.org
Sent: Tuesday, February 17, 2009 7:43:38 PM
Subject: [mmox] User Accounts / "Object" Transfer.

I agree,  with the pre-requisite for authentication and see that as
being a
  "User" Services Account per-grid.

With regards object transfer,  I personally see each "grid of regions"
as being
  an own-domain and only items "attached" to be transferred with the
character.

This opens the market for having "suitcase" attachments,

the only items that I see as being standalone crossing between grid
regions would be
  automated bot programs,  and these need not keep the standard "AV".

And limitation of transfer based based on ownership and complexity.

Some things like scripts need to be hosted seperately for transfer to
happen safely,
  to allow the region server a mechanism of limiting any harmful effects
without loss
  of function in transfer.

Also this would limit the loss of content and state issue that is
currently present.

--

With regards imagining like the early automobiles or early railways...
certainly...

However anything external to the AV or "detached" status may be blocked
or
  otherwise have a substitute based on the new "grid" environments
theme.

I can imagine an Egyptian ferry being switched for an Italian taxi from
Venice,
  or even a really big "leaf" if changing region to somewhere of an
entirely different scale.

switching grids need not keep scale,  but the only thing needed to be
kept would be some
  kind of central "airport" style mechanism that allows for being a
"door" between the grids.

Or do we allow anyone with permissions on two or more grids to
"Teleport" to any location
  on a target grid entirely seperate from the former.

--Idea--
What about splitting the Asset&Inventory services into having "User
Storage" and
  "Region Storage"... anything free-floating is on region storage (grid
local) and anything
  in "User Storage" is potentially cross-grid capable.

However the first thing to cross grids apart from an AV for presence is
going to be messaging
  from what I understand there is several backend options needing some
kind of
  standard "Message" base able to be encoded for IM & Email,

I would request UTF8 encoding for this style of message(address:content)
delivery
  then we can push towards having standardized i18n/i10n support with
least effort.
--Idea--


I remember a description of early LL teleporting needing a "hub"
location.

Why not allow unrestricted p2p teleports within the same grid of
regions and when needing
  to transfer across regions using a special region on both grids with a
"door" and key setup?

This would allow a basic operational setup of something akin to Airport
security with regards
  firewalling and also provide a "safe zone" with information about grid
connections.

Information about other grids need not be limited here,  but it would be
a start for some kind
  of standard to develop without requiring to push untested features to
all regions in any grid

Sincerely,
  Jeremy

--0-1457113820-1234923508=:32658-- From infinity@lindenlab.com Tue Feb 17 18:22:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 301123A6804 for ; Tue, 17 Feb 2009 18:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo5ETtoDItq6 for ; Tue, 17 Feb 2009 18:22:11 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 33C0D3A6782 for ; Tue, 17 Feb 2009 18:22:11 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 0B3D23DBC06C; Tue, 17 Feb 2009 18:22:23 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Mark Lentczner In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 18:22:22 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 02:22:12 -0000 hola, i am meadhbh hamrick (pronounced "maeve"), a software architect at linden lab. i was involved in the lindenworld beta, left for lack of a working mac client, then came back as meadhbh oh. just under a year ago i came to work for the lab, leaving behind a couple decades of software development and engineering management work, mostly in the mobile-embedded, security and mobile-embedded security space. i have participated in the omg (object management group) and pkcs (public key cryptography standards) efforts in the past and am the co-chair (along with ibm's barry leiba) for the upcoming mmox bof meeting. along with tess and zero, i was a co-author of last summer's ogp docs and was the editor for the current llsd draft. in a previous life i maintained the cryptonomicon.net and securitytechnique.com web sites... from '98 - '04 i blogged more than anyone should have to in one lifetime; so i really have no current personal web presence. work identity: e-mail: infinity (at) lindenlab (dot) com web: http://wiki.secondlife.com/wiki/User:Infinity_Linden second life: infinity linden personal identity: e-mail: meadhbh (dot) siobhan (at) gmail (dot) com second life: meadhbh oh in my spare time i enjoy cooking, astronomy, and programming in logo and smalltalk, but most of all being a parent. -cheers -meadhbh On Feb 17, 2009, at 2:33 PM, Mark Lentczner wrote: > Friends - > > As if the internet weren't already full of multiple monikers for > everyone, many of us have only met in virtual worlds. I suspect that > I've met some of you in person, via e-mail, and in Second Life, and > that I don't know that all three of you are the same! > > Having so many multiple personalities shakes my own sense of self, > so I thought I'd start a thread of introductions. I'll go first: > > I'm Mark Lentczner. I'm the Sr. Systems Architect at Linden Lab. > I've been working on Second Life for over three years, mostly on > evolving the architecture of this growing virtual world. Many of you > know me from AWG meetings and my office hours as Zero Linden. > > Work Identities: > e-mail: markl (at) lindenlab (dot) com > web: https://wiki.secondlife.com/wiki/User:Zero_Linden > Second Life: Zero Linden > > Personal Identities: > web: http://www.ozonehouse.com/mark/ > Second Life: Zarf Vantongerloo > > > - Mark > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From cenji.neutra@gmail.com Tue Feb 17 19:53:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4F253A6A1A for ; Tue, 17 Feb 2009 19:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asEcXH-VvlIn for ; Tue, 17 Feb 2009 19:53:48 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 072D13A6B7F for ; Tue, 17 Feb 2009 19:53:48 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2245799rvb.49 for ; Tue, 17 Feb 2009 19:53:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=vm/AL/DYgfJG4zq8ngAocWTEF8dyHFBAeK2pjxLD0D8=; b=BNdObhuobDjRuP1t8c//O6qmWKrx59jdgRJUorELAMemih4NKD+8sJtF8UqscI8Vza vrLNqopLYf5qXJr+pkWetaekOAmU7sFLwJw8P7IQ3TsLuHz2Tj6eSIB9IsYn4HEU4O4D X7aD7TR78y9bgAR73aUnJ7hiB0y8ZJ+4nn+XE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=N8i+lotfuGSZnT8SLZ9wEZzqqlouPSKW4Bm7ZmoQ6qHD7GINbYahk5sWhp7UmhXlUU GNjNMXb2jT25jPqKxB5B3TKPckrvpdXQc0uOiDklkGFEADFBnwaRU6ZLDWMk0hEEv1aq a7Lcr/Cmkvgu6Opi7R8APB2thipEJ0NLKWh7s= MIME-Version: 1.0 Received: by 10.142.102.5 with SMTP id z5mr3359040wfb.146.1234929239256; Tue, 17 Feb 2009 19:53:59 -0800 (PST) Date: Tue, 17 Feb 2009 22:53:58 -0500 Message-ID: From: Cenji Neutra To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 03:53:48 -0000 Hello peoples. Quick intro: I'm David Jung (aka Cenji Neutra inSL). I've been the director of Apez Corp (apez.biz) for the last few years and am interested in all things VW. While a seasoned software engineer, I'm still waiting for the day when I can just write code *all* day :) In the past I worked at one of the big US government labs (Oak Ridge National Lab) as a research scientist on a variety of things over the years including AI/robotics/neuroscience, bioinformatics and supercomputing - all involving software in one way or another. Long term goal: immortality via upload (for L$10 of course) ;) From belxjander@gmail.com Wed Feb 18 05:30:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF5C23A6CC3 for ; Wed, 18 Feb 2009 05:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNam1tYomit3 for ; Wed, 18 Feb 2009 05:30:00 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 321A33A69CC for ; Wed, 18 Feb 2009 05:30:00 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2416345rvb.49 for ; Wed, 18 Feb 2009 05:30:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=mzFG8pfAp47pgJ/eYmKdr1JbjXz1bkZXWU+5FQcDC6E=; b=qqfORe3aIvWq9Mdu0Kng6BcTyEwslw7q64cFTm164THKPKfkOa1F5lCD5XvxSZxMYq 41F3k871g7fTUB5TGD04OQpb7sG7y1A6Ly9AHevIauGU3dDynq4poyVOd/rxP1mwFBk9 WRWtPo27Z1JQ+bpwM5/hYCcvcsvMCS2lLH2E0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=wIOJASj7Ay+fa2bzCn5WhXMRYt7DfktVlCeD0CaKl4OFwGt5JVy5mns3wDXqV/hL4m RKSGvhmImyQFPP47/Mtk6wZPmP+GA6bwAmAsqubVP/VHdF5ok5VqrwYwELtiyGZqWP3c 8997K/vlJl6mY1Z5NWZ/e/FvvJEdX/cVVF8L8= Received: by 10.141.142.15 with SMTP id u15mr3979705rvn.16.1234963811902; Wed, 18 Feb 2009 05:30:11 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id b8sm16830506rvf.8.2009.02.18.05.30.09 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 05:30:10 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <306449.42147.qm@web82603.mail.mud.yahoo.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> <306449.42147.qm@web82603.mail.mud.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6e14Q9ioceELW48XpqKE" Date: Wed, 18 Feb 2009 22:24:54 +0900 Message-Id: <1234963494.7560.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:30:05 -0000 --=-6e14Q9ioceELW48XpqKE Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Then the Minimum "plumbing" would be "User Account" and "User Presence" along with some kind of 3dspace with "object"s present that are not a "User Presence"... in SL terms this would be "grid"/"users" and "asset/inventory" functions required, in WoW terms, a "User Account", the "Game Arena" server and then the Users "Item Storage" for Items picked up in the "Game Arena". 3 parts, 1 "human" Presence and Identity, 2 some kind of "mappable area" that is shared, 3 interactable "objects" present in the "mappable area". Any client functionality would be at bare minimum that and would need to make a display representing the map and objects in it. would it not ? the "AgentDomain" and "User" Services from SL would be merged for Identity & Presence, the "Grid" & "Region" services also appear to merge, the "Assets" & "Inventory" services also appear to be merged, as for messaging, each platform has so far implimented this in some fashion as an extended feature of presence, I vote to keep this an open binding option allowing choice of backend does anyone see any problems with my simplification in the above 3 parts listing? On Tue, 2009-02-17 at 16:23 -0800, Charles Krinke wrote: > As I think about virtual worlds and interoperability, the metaphor of > independent states or nations come to mind. So, I guess in thinking > about interop between virtual worlds, we can either go down the > secondlife/opensim type of path and try to fit all virtual worlds into > that paradigm with agentdomains or UGAIM notions or we could step back > a bit and consider interop between > secondlife/opensim/Wow/croquet/wonderland and others. >=20 > Is is appropriate to start at a higher level and take a step back and > consider the broader implications of virtual worlds beyond just our > current paradigm such as WoW/croquet/wonderland and identify the > minimum definition of network "plumbing" with that in mind? >=20 > Charles >=20 >=20 >=20 > ______________________________________________________________________ > From: "Hurliman, John" > To: "mmox@ietf.org" > Sent: Tuesday, February 17, 2009 4:16:30 PM > Subject: Re: [mmox] The Story So Far... >=20 > >-----Original Message----- > >From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com] > >Sent: Tuesday, February 17, 2009 3:42 PM > >To: Hurliman, John > >Cc: mmox@ietf.org > >Subject: Re: [mmox] The Story So Far... > > > > > >On Feb 17, 2009, at 3:09 PM, Hurliman, John wrote: > > > >>> While there is plenty to do and discuss in order to develop OGP > >>> into a > >>> fully workable protocol, we think it represents an initial shared > >>> vision > >>> of an interoperable protocol and hope it can evolve and grow in > the > >>> context of this group. > >>> > >>> - Mark Lentczner > >>> > >>> [1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol > >> > >> It's great to see the amount of work that is being brought to the > >> table by Linden Lab and the Linden Lab Architecture Working Group > >> (AWG) participants, and I hope as much of it as possible can be > used > >> to build an MMOX standard. I've been working on an LLIDL > >> implementation among other things based on what Linden Lab has > >> submitted as draft material. > > > >awesome! > > > >> It's my understanding that Open Grid Protocol (OGP) is a Linden Lab > >> project; part of the Linden Lab AWG which had no active > contributors > >> that were also active developers of libSecondLife/libOpenMetaverse > >> or OpenSim during the time the OGP protocols were designed. The > >> "agent domain" concept in OGP terminology brings in a host of > >> assumptions that are diametrically opposed to the goals of > >> libOpenMetaverse and OpenSim (supporting millions of independent > >> administrative domains and service providers). > > > >huh? there were a number of non-lindens who participated in the > >development of OGP. the AWG does not, nor did it ever disallow > >participation by libSL or libOMV contributors / committers. last > >summer we demonstrated interoperability between Linden Lab's servers > >and an OpenSim instance. we hope that members of the libSL and libOMV > >teams will participate in MMOX. > > >=20 > I said "AWG had no active contributors that were also active > developers of libSecondLife/libOpenMetaverse or OpenSim during the > time the OGP protocols were designed". The participation by > individuals that were not Linden Lab employees does not mean that OGP > is a joint effort between Linden Lab and the libOpenMetaverse or > OpenSim projects, or that the OGP as it is drafted has support from > the libomv/OpenSim communities. >=20 > >the concept of an agent domain was defined explicitly to support many > >different independent administrative domains. that is... though the > >interoperability test last summer used the Linden agent domain, the > >specification does not mandate a single agent domain. in fact, i > >believe Christian Scholz (a non-linden) implemented his own Agent > >Domain based on code from the PyOGP project. There is also frequent > >mention in AWG meetings of an upcoming C# implementation of an Agent > >Domain, again by a non Linden-Lab employee. >=20 > The agent domain concept takes several independent services (identity, > presence, inventory) and lumps them together into a single trust > domain. This inhibits the development of a widely distributed > ecosystem like we find on the web today, and is really only convenient > for large virtual world service providers that already have a vertical > stack of services. It also drags in the assumption that there must be > a backend communication layer between services such as inventory and > simulation regions. >=20 > John > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox >=20 > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-6e14Q9ioceELW48XpqKE Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJnAwmAAoJECHrKutFYVwTjbcP/3X7RffD0324Q3sklnveNLH0 1JNLU5TOYCzyscJyP2d7+jnbOlaWCYwFRNYfxpBCvv1CMhyZQcACK8VWZzO5brAN pdACjcHq/H2h9UD+jfqZS3fsGr/rafbC5n1mjhGf95EmZvurY2xVM82JvFyoxwBx Cx2sVgAqpb1jbge7+XiVmi6PncUVPmsDNcsSnBV8tW9Ub1d7s+JLDsmhN7HZD+l0 2dzcx/72090BpZviIPfhheTOrXyjuT8Q+jsGnIQst4Gx1dJPOzNB/uzr0vSqE0kz FyG87j4nK0+lN+nW45rRXM5IjFcdEiVb7l3iTUEy61GEkGC98gxhtTYANPLA+KJx cjPSpXMWcUlaBT6yWEFSh5zM8yVOvxYyzi3PdRiBWt+4aeNIExOTtapXmMhDW6qT 8iLOPFtFSoWNCJBcek16u8Fat5TgFF1PQJxZCzmO2guCy4JQxgn2okEaYC4ZuKwM XFu4Izy/2R18M0vjde0Hv7QACJQhVer/pYFdjCSEHyb2xpfTkEvdB9TmjohHc9lc PBebwsVreehRdbV6Sh7s8LUAXU3C/9/HrnOEu075KSZLk9s/6oCsHGGJYl2iFBYx +uivVCVYZkRji3Qsr1oiRb/Eb7v73giFueXSDpeIyqr/SFEVRc8Xe2aS1h2TI8gw PB2fiEIT63VRQvSXewxZ =SKoU -----END PGP SIGNATURE----- --=-6e14Q9ioceELW48XpqKE-- From suzyque@gmail.com Wed Feb 18 05:43:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB4B3A69A0 for ; Wed, 18 Feb 2009 05:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQnw49tXpxhp for ; Wed, 18 Feb 2009 05:43:28 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 2B2AA3A6CC3 for ; Wed, 18 Feb 2009 05:43:28 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1318302qwe.31 for ; Wed, 18 Feb 2009 05:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=pR88Bl/19gvyZHYJ9/gVYb6h3XV4QrjgJBx85sJWSOA=; b=eaX6KpYvt50JKU9am5brtif+9bIgY76VceHFCnBk1RaNL6vDSGZjLeknMVKtO/BHE/ jkbUMBLVO1YHw59w4WLefb8gWeCOgN/O/Wh6M0V1/5wcVv6dQo4e4iJc0m5wPl4wLVge +vyO78BCVpEW4AYZjTlhelTkteHTm2H/7bYtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=uSza983RKSgmn41RBFpp3SvbFkaqtn2B4svMFqqCQu/4w1m2q8FVomlXICeBfVZkpr +aUwyz85sjP0BBRWvSNp7L0arg/9ulbQMMj0uBzl0CK/4x0UE5QVx9B9DG9AZlEl1A7X 4oplcbnxgi4p10p0nWqN+rj8sAmexTaayfzoU= MIME-Version: 1.0 Sender: suzyque@gmail.com Received: by 10.224.89.74 with SMTP id d10mr8800262qam.202.1234964619692; Wed, 18 Feb 2009 05:43:39 -0800 (PST) In-Reply-To: References: Date: Wed, 18 Feb 2009 07:43:39 -0600 X-Google-Sender-Auth: e6e06e491b421ca8 Message-ID: <2bd5b7f10902180543l6ce9b602q41df3c91df5e9f94@mail.gmail.com> From: Suzy Deffeyes To: "mmox@ietf.org" Content-Type: multipart/alternative; boundary=0015175ccfb8778bc70463319bea Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: suzyq@pobox.com List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:43:29 -0000 --0015175ccfb8778bc70463319bea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I'm Suzy Deffeyes, software engineer at IBM working on various Virtual World technologies. I've been working on Virtual Worlds as my day job for the last 18 months. I did the OGP viewer teleport code last summer. My background is in OpenGL development. Standards wise, I am currently in the COLLADA working group and also IBM's board member for the Khronos standards group. Additionally I have participated in the OpenGL ARB in the deep dark past. RL: Suzy Deffeyes SL: Pixel Gausman Twitter: http://twitter.com/pixelq --0015175ccfb8778bc70463319bea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

I'm  Suzy Deffeyes, software engineer at IBM wor= king on various Virtual World technologies. I've been working on Virtua= l Worlds as my day job for the last 18 months.   I did the OGP viewer = teleport code last summer. My background is in OpenGL development.

Standards wise, I am currently in the COLLADA working group and also IB= M's board member for the Khronos standards group. Additionally I have p= articipated in the OpenGL ARB in the deep dark past.

RL: Suzy Deffey= es
SL: Pixel Gausman
Twitter: http://= twitter.com/pixelq 
--0015175ccfb8778bc70463319bea-- From jesrad@gmail.com Wed Feb 18 05:45:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF5D3A6CB7 for ; Wed, 18 Feb 2009 05:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMkiHEnOaIAT for ; Wed, 18 Feb 2009 05:45:37 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 4F21C3A6A11 for ; Wed, 18 Feb 2009 05:45:37 -0800 (PST) Received: by bwz5 with SMTP id 5so5438408bwz.13 for ; Wed, 18 Feb 2009 05:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B1ec5HjEHyJ2rhwaaCJqtNKXZv6fm46ctpCrRFQ4NQo=; b=C4ZLidtin8WcR8XjkrktoHbizYCVksqv5t4FO9Dk6XaZkolW85CPDaNlIy6QUSeZHK PrnUZOq3o4i3XxHz3kmN3Kbo6FdLRRUqKtriIqCBCKT1jaqQlWNIX9wojANvouqrLZCZ xDZhLa2eMideZqDVNSEADgyAGTKq6BPz2IcPA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=qy731dhTG0V5elQq7yZRy5sQHNI1Gk5dFxiU/ZftGjhwx3MuhBGRN8LpD41Jz2FjGj BKk8hQJlhOIF21Nt4P9gtAP1uSKyLQ/dIe6quRhEqCDgQXdNLq/ch9edO4JbWGPykWll WR3cAhni0HDOPpGeS236gxvR4IvVr2Gf4NDvM= MIME-Version: 1.0 Received: by 10.180.246.2 with SMTP id t2mr2795120bkh.161.1234964746967; Wed, 18 Feb 2009 05:45:46 -0800 (PST) In-Reply-To: References: Date: Wed, 18 Feb 2009 14:45:46 +0100 Message-ID: <53cd6c2e0902180545o556f5d90yd5beb758b18831@mail.gmail.com> From: Jesrad To: Cenji Neutra Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:45:38 -0000 Hello everyone, I'm Jesrad Seraph and have been in Second Life since the first useable Mac viewer got out somewhere by the end of 2004. RL I'm a Network and Systems engineer with several years of experience in QA and high-level technical support, so I'm not a true programmer and try to focus on the higher level of how things work. I've participated sporadically in AWG meetings and tried to push several general redesign ideas for easing grid interconnectivity (through radical decentralization of simulator operation) and improving scalability. I also have original (=bizarre) ideas for IP issues and have been experimenting with a promising alternative rights-model to copyright. From jjustincc@googlemail.com Wed Feb 18 06:22:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE4ED3A6A71 for ; Wed, 18 Feb 2009 06:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V1PmIVIEa1J for ; Wed, 18 Feb 2009 06:22:49 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id C8A2C3A6CA0 for ; Wed, 18 Feb 2009 06:22:48 -0800 (PST) Received: by bwz5 with SMTP id 5so5486309bwz.13 for ; Wed, 18 Feb 2009 06:22:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=5V40aj3K1uo36F4WwPuj7qFIatjoYzOWRoDE58Gsg9s=; b=wSJORuC8ROJMwrpAzpZbv3O+V02pIUc4ImUNJnnBUmwwFZwYLDrIOWGqSeubYeAxYa ug1JZlTvTSv9lN7YsGu31zHNbSLNTX/67HDTnyTAmzSIAeO4aslY+wdUWMDn66pi9CXS PVPQOsBKT9CSqFeXM9rOFIDSmuU5BVmZ35lsc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=nQJ5rvn0gSgx31tCp8AbKHddQkxSJXJdHVAYNVnxi3CBVhD2IM8hFWI4Bz8W+gqUze 98QXWFVORKe4GkJ8hM98DxIjEtvk7oFZqYrvInXOXIPgf01VBVpM2hjjpj3lakRPmBPn /ozoYoa+XB2tJq439ZqM0hHbNWnvSmObCrVWA= Received: by 10.223.114.207 with SMTP id f15mr903322faq.90.1234966979189; Wed, 18 Feb 2009 06:22:59 -0800 (PST) Received: from ?192.168.1.2? ([80.175.122.121]) by mx.google.com with ESMTPS id t12sm2709850gvd.20.2009.02.18.06.22.58 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 06:22:58 -0800 (PST) Message-ID: <499C19C1.10202@googlemail.com> Date: Wed, 18 Feb 2009 14:22:57 +0000 From: Justin Clark-Casey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13pre) Gecko/20071023 Thunderbird/1.5.0.14pre Mnenhy/0.7.5.666 MIME-Version: 1.0 To: mmox@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 14:22:50 -0000 Hi, I'm Justin Clark-Casey (justincc), a core developer of OpenSimulator and lead developer at Black Dress Technology. Commonly I'm Justin Clark-Casey on OpenSim systems and Lulworth Beaumont on the Linden Lab grid. I'm interested in following along on the discussions with an eye to their eventual implementability. -- justincc Justin Clark-Casey http://justincc.wordpress.com Mark Lentczner wrote: > Friends - > > As if the internet weren't already full of multiple monikers for > everyone, many of us have only met in virtual worlds. I suspect that > I've met some of you in person, via e-mail, and in Second Life, and that > I don't know that all three of you are the same! > > Having so many multiple personalities shakes my own sense of self, so I > thought I'd start a thread of introductions. I'll go first: > > I'm Mark Lentczner. I'm the Sr. Systems Architect at Linden Lab. I've > been working on Second Life for over three years, mostly on evolving the > architecture of this growing virtual world. Many of you know me from AWG > meetings and my office hours as Zero Linden. > > Work Identities: > e-mail: markl (at) lindenlab (dot) com > web: https://wiki.secondlife.com/wiki/User:Zero_Linden > Second Life: Zero Linden > > Personal Identities: > web: http://www.ozonehouse.com/mark/ > Second Life: Zarf Vantongerloo > > > - Mark > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From belxjander@gmail.com Wed Feb 18 06:31:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86DC3A6C66 for ; Wed, 18 Feb 2009 06:31:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ybbsmTseQPu for ; Wed, 18 Feb 2009 06:31:21 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id EEF413A699A for ; Wed, 18 Feb 2009 06:31:20 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2437069rvb.49 for ; Wed, 18 Feb 2009 06:31:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=r7WC1n+jgWbgb5XLKfcqF/9Q4CoHioJZr0GBtGddag8=; b=oB/3x2/xnYxWIZWvrIP6VKAosFyKWTjAvWPOT8MCW7i1gQJXOOFsFSrulfcoYh3rbq lRqtU1DjtoRt6YLu61cm1t9XDuD2t1HW4cRDilNaMn9NlVxHkqhynhFQ3JDWKyNMXcN8 NiPgqCshzpfj3j1LepUl6ib2/kTWoUDROsPsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=NYhnr8fE33vrN47UzDsJhzO4TqX53YcHrxqlKh3pqe4yFa5qtZVRgkaPpq4Wuzy7g9 L1jpK3shVWCiIyeR9llm0SIz1rhBleVX3xt0R2IeVsFTQ3AYCz9lVPDHnRkGUkzVvWLz FR7ahYgvA9UHcRRrYcT923YiNBsRKvvo9oLII= Received: by 10.140.164.6 with SMTP id m6mr4004954rve.29.1234967492468; Wed, 18 Feb 2009 06:31:32 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g31sm16967383rvb.7.2009.02.18.06.31.31 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 06:31:31 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <61dbdd7d0902171801t16617ae5n59e170d2a31235ba@mail.gmail.com> References: <61dbdd7d0902171801t16617ae5n59e170d2a31235ba@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-C6vUEapDNy6dfwqfM09p" Date: Wed, 18 Feb 2009 23:26:15 +0900 Message-Id: <1234967175.7560.30.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] A few assumptions if I may X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 14:31:21 -0000 --=-C6vUEapDNy6dfwqfM09p Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I agree with gareth about having a required "core" and then working from that and I am also in agreement about needing *neutral* or open standards, not the limited and limiting use of stuff like .NET remoting which I am aware of has a limit with regards transfer of non-public data being non remote capable. speaking of this however also opens up the use of C# and .NET runtime as a limitation since no one outside microsoft actually has ownership of anything in the code using it. and a true server will work with one core protocol and allow for extensions, apache was built similarly and I can already expand that with existing scripting for provision of the non-region services in SL. I personally see OpenID and OAuth being usable components towards an open grid infrastructure that is easily maintained. And see dependence on the .NET runtime as sitting with a permanent hammer ready to drop at any time. (loss of msft, what happens to that runtime?, new owner?) Also Im finding myself primarily hamstrung in my own work due to non-code issues, and the real world need for paying work that actually pays on time. if anyone wants to hire me to actually get things done quicker... *please do so* Im not knowing the "Snow Crash" book(s?) that are referenced by the OpenSIM group, Ive also tried to play with the libSecondLife before the LibOpenMetaverse naming. (very unsuccessfully) and I am currently working with python which is letting me get somewhere. I get the feeling like I will be burning braincells before I actually get to be at any of the "real" discussions or get a decent handle on the vocabulary terms used by this group when meetings happen (Im in Japan and have real life keeping me out of sync with "Office hours" as it is). Sincerely, Jeremy Kajikawa (Real) (Belxjander Serechai (Internet)) ( Freija Yoshikawa (Internet@SecondLife+OpenSIM)) On Wed, 2009-02-18 at 02:01 +0000, Gareth Nelson wrote: > 1 - We need an absolute basic core of identity > 2 - We need a modular design where extra services (simple stuff such > as chat and inventory) are bolted onto that core with mechanisms such > as optional caps URLs (man I love caps) > 3 - On the "intellectual property" issue, we should take the view that > if a particular system is serving up an asset, it is authorised to do > so - in other words, if you can do (for example) an HTTP GET on an > object, it may come with permissions flags in the metadata, but we > should enforce these flags only on end systems - clients, inventory > servers, asset servers and simulators - this simplifies the legal > issues and pushes liability to where it belongs, with the users > 4 - This should be obvious, but anything intended for an actual RFC > should be 100% neutral of any particular virtual world/MMO or > platform, so stuff like the .NET remoting in opensim (a pet peeve of > mine) is out > 5 - Binary protocols should be used whenever efficiency is important, > but designed in an extensible fashion such that one particular packet > type once defined will always mean the same thing and systems > implementing such protocols can rely on a core set of messages always > being available with graceful degradation for anything outside of this > core - we need not see the whole world through HTTP-tinted glasses > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-C6vUEapDNy6dfwqfM09p Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIbBAABAgAGBQJJnBqHAAoJECHrKutFYVwT8BcP+PndpfTmbGTeopuRrZenTzzV 1S0fQeHFgQFIcUkjz3OGonkEqE320qZO5NOBhV6bulcoKKRhCStkSDSgHwEtQIFB nNAEqCP/hGUQEpyfHakUkhHccZ/39wY50mRopQPEjB9Wgbh4JeF0pYRtNlys7vlH 7oTZBsl8fTJkJ5C5xHgCMuQLIpE7m7NPi9N592FVcFWXDgR4m/XBmyXyf52rK81L sq58IehX8ZMlahbEPPWbCII93qelT+k50tF9Lj06indQ5IoCRrosxPazHofeieLY k8aM5LW+io+i+n67hgy2lh12y0Weris31rTzR/5y29RXCq5tsfK4K7HS2lh7RM5s Noyf1u1Unhd1tl2KN2W96r00Ztg/DxMw7ZpNhe0RPAhvHFiYebjc151FjqRc1UwD o//1zUb1Ky4Oecu4yEWYX2pjVg9kZRmzwL0UBTIuxleW5R3XYNsSR1bl9U6uENLZ lx+4ikHcfbp/A3EUl1LqmISHuaPVPn7mhaht7WKHGeCNxOtKByX+d91gc4DfOXne U3yy8WEnRVsXZjokas3g32E1VIuxNcWTW3GTrJ0M0Wg1c9UrV6ecyWGtrc7S1prw N7eTuQ+QIbXzzGzsgiewjZBFNA6qFBeL3+2zRzCCSGU3wYPfvnkNt4sAAg11Xcus BhG/l9nG6zZrbNEzQNs= =v5XE -----END PGP SIGNATURE----- --=-C6vUEapDNy6dfwqfM09p-- From belxjander@gmail.com Wed Feb 18 06:49:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84903A6D2E for ; Wed, 18 Feb 2009 06:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.452 X-Spam-Level: X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OooPpGG9bH88 for ; Wed, 18 Feb 2009 06:49:14 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 0F6A83A6A4F for ; Wed, 18 Feb 2009 06:49:14 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so1718357wag.5 for ; Wed, 18 Feb 2009 06:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=Qv86S2uhx4Ww8fL7l0wSMWjoI3ClA4h9kJ5WQ+m2m8s=; b=esJdr9AcRi9ySPgakYQ9YCevyTJob1iG8EaUEEB5QZdzZGB6YCapCQJuYlhEcYuD2R CdNs5lcBE4xlwC7wHab9J85uwQ8QcRqT8eZrh+AnKLbeOkMSWLmssX/j5IUm/K237xrs uQ2OdHN96Fj+3v1CMEsGt318lrVU/GmZMRYQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=Y9df/1PcsQDZPZw3nS/D2DvZlC4xQeSQ98hU8cIAFSrO62pL121oVq8YYwdVxTjHJG yrpYuHCjPmQjHDsevhEGU3Xx68KtM/WzU7tyAYjt2qYnAPSo+q6XrISZpnlRybR0R3pf T+VRMgJab1iNtKNrvvZ8SURdYSLlxU9ZC/P2M= Received: by 10.115.14.1 with SMTP id r1mr3185906wai.171.1234968565676; Wed, 18 Feb 2009 06:49:25 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id k37sm13377897rvb.1.2009.02.18.06.49.24 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 06:49:25 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <2bd5b7f10902180543l6ce9b602q41df3c91df5e9f94@mail.gmail.com> References: <2bd5b7f10902180543l6ce9b602q41df3c91df5e9f94@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-IDejgRxf1wEvJIqT4ymY" Date: Wed, 18 Feb 2009 23:44:08 +0900 Message-Id: <1234968248.7560.47.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 14:49:14 -0000 --=-IDejgRxf1wEvJIqT4ymY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello, I'm Jeremy Kajikawa (Formerly: Jeremy Sutherland, name changed by Marriage), Im an Independent System Engineer/Network Engineer/Software Engineer currently needing employment and now living in Japan, since 2003 unofficially and from 2008 officially a "General Guru" with "SourceMage Gnu/Linux". I have been tracking the SecondLife Clients and variations along with OpenSIM server and have also recently started a cloud services implimentation that is to remain seperate from being bound to any particular grid (a general AD U G A I M setup). Ive already got hosting and the access of APIs made available and am currently more ahead with getting the site functionality built than anything of the "look" and feel completed. My background is 10 years of programming with AmigaOS privately, along with= further learning into the Windows and Linux operating systems in addition to a lot of priv= ate schooling. as for work, mostly OEM system building bare machines and installing user-= purchased software. Ive never had aspirations to be the next bill gates or anyone like that (= I dont have the instincts for it) Ive not had a stable day job due to apparently being too trusting, Im not = with any current bodies or institutions and have for the most part and dont expect anything. Its nice to meet everyone and hopefully get something viable produced so I = can say I did more than just pay the bills now that Im newly married (as of Feb 2nd this year) an= d have already lost my first son, (He died 3 hours after being born after 21 weeks of pregnancy). Thanks for your time, Real: Jeremy Inet: Belxjander SecondLife/OpenSIM/etc all...: "Freija Yoshikawa" --=-IDejgRxf1wEvJIqT4ymY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJnB64AAoJECHrKutFYVwTJnEP/R04lhT5DYjbcNdzGcVnNlee tQ25WywivjPFgoONYh5RCSqTvc/KI4Vi5DQ9nySlwfs+Q1/yV0wR0kqNSI3NkEPH vTNGXlokSfoErCPIQ+A92IvjEnVzRwd9kbDPbRZtgWJccM2MSIZXTUKgEPcssm8M 0fk71qwCJMbJZt1dxrDguGT1z/aLDFbfiNEMe04Ihns8z0JOxeAUlDhTwB7C9EgK w4Qda5wsIuaeoLH6fBhHcNwMl8+ALc4R4lALXqWzHsT9X2b54Yq/T8it7MHYqKg0 yjxRlBENef0yUdd/wp+Yib9aog9cUJ5LxTPtQAvZvbiCmdpTzelVgWFkuBXPfqWG D3SYqiq+FxAJwq7DoKcfiHlMe/MFUc1TzmkrhZKdVXzQA1O6Ara81DrwBun2n0dZ j7DyxdEmksO1BpLYt8FeH6e7iKPFovqGrQqq02TCb8Yk0bqlolCtTzrrGeXBaVrJ Qa/VkYlhZTH/jbFs9dFM5JdvocoPCEvCGq4wEJdsPbAsCIcfQ4Wqvzmjdn2N35Nb GWRBp0zasTC/o6Ugh5sAYlzT+gUP6Uf6t+VuG84BIxuI783xQVkr7j6JiE20OsRn iHPfnWMRoWjwmstJGldBfx9PsXWGNxQsOZ5BC9xrlaTQ4Lg+k8sWMubNu7tlimBg YVC7JbI038rRBNjmxmyG =FuNE -----END PGP SIGNATURE----- --=-IDejgRxf1wEvJIqT4ymY-- From cfk@pacbell.net Wed Feb 18 07:06:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DCE3A6D33 for ; Wed, 18 Feb 2009 07:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ns7f7+vxpj+l for ; Wed, 18 Feb 2009 07:06:01 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id 3ED173A6D2E for ; Wed, 18 Feb 2009 07:06:01 -0800 (PST) Received: (qmail 7075 invoked by uid 60001); 18 Feb 2009 15:06:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=dAnyFGMfOLzTdqVY2GgOax3ADog9qhjgwclG3+7zu6f1z5scO/6JYuHndVsGeRx8elNzPW1TC5pmiCkaWKf6yR2RbGNsFsPjQEGNj5yOohnH8M5B5mtG91HkfFM9J6MLdLluguIdL8F+lt8ZbE33DeCL3+aLbicK72LE/kiMrqU=; X-YMail-OSG: Ox9UO5wVM1mYKoi9yaNjOVGs.IDb.wogstWk5Xb1ZKy_cnqURlDuXJKs5U5PXviwK3DbhgaoyooFq0NDGynX1Vr6fuS.Ggj4KK3A.DNhgMB3RFINSKnzuZi1fGtFTZ0yu59R3YZeKgFe8azB4EZZeCruez9dxXtXkSc.wfOX6bFmd5XBlfc78Nr0rnjgnoBoq8X0tRljXhFK7YHtiwMXV_XgTh8- Received: from [75.215.15.96] by web82602.mail.mud.yahoo.com via HTTP; Wed, 18 Feb 2009 07:06:12 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D501FDCC8@rrsmsx506.amr.corp.intel.com> <306449.42147.qm@web82603.mail.mud.yahoo.com> <1234963494.7560.8.camel@localhost> Date: Wed, 18 Feb 2009 07:06:12 -0800 (PST) From: Charles Krinke To: "mmox@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1584705060-1234969572=:4561" Message-ID: <677983.4561.qm@web82602.mail.mud.yahoo.com> Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 15:06:03 -0000 --0-1584705060-1234969572=:4561 Content-Type: text/plain; charset=us-ascii This seems a very reasonable direction and discussion. Let me toss in the current OpenSim direction as a reference. We tend to like five server processes currently and these are split into a UserServer, GridServer, AssetServer, InventoryServer and MessagingServer. As the situation evolves, and we seek and find a consensus, I see one of the necessary steps to finding a consensus that everyone be willing to describe and negotiation a common ground. So, thinking about Wow, Croquet & Wonderland interop with SecondLife and OpenSim seems to me a good direction to focus as it will probably allow us to get to the "what" and "how" of the plumbing and past the "why" perhaps more quickly. Charles ________________________________ From: Kajikawa Jeremy To: "mmox@ietf.org" Sent: Wednesday, February 18, 2009 5:24:54 AM Subject: Re: [mmox] The Story So Far... Then the Minimum "plumbing" would be "User Account" and "User Presence" along with some kind of 3dspace with "object"s present that are not a "User Presence"... in SL terms this would be "grid"/"users" and "asset/inventory" functions required, in WoW terms, a "User Account", the "Game Arena" server and then the Users "Item Storage" for Items picked up in the "Game Arena". 3 parts, 1 "human" Presence and Identity, 2 some kind of "mappable area" that is shared, 3 interactable "objects" present in the "mappable area". Any client functionality would be at bare minimum that and would need to make a display representing the map and objects in it. would it not ? the "AgentDomain" and "User" Services from SL would be merged for Identity & Presence, the "Grid" & "Region" services also appear to merge, the "Assets" & "Inventory" services also appear to be merged, as for messaging, each platform has so far implimented this in some fashion as an extended feature of presence, I vote to keep this an open binding option allowing choice of backend does anyone see any problems with my simplification in the above 3 parts listing? On Tue, 2009-02-17 at 16:23 -0800, Charles Krinke wrote: > As I think about virtual worlds and interoperability, the metaphor of > independent states or nations come to mind. So, I guess in thinking > about interop between virtual worlds, we can either go down the > secondlife/opensim type of path and try to fit all virtual worlds into > that paradigm with agentdomains or UGAIM notions or we could step back > a bit and consider interop between > secondlife/opensim/Wow/croquet/wonderland and others. > > Is is appropriate to start at a higher level and take a step back and > consider the broader implications of virtual worlds beyond just our > current paradigm such as WoW/croquet/wonderland and identify the > minimum definition of network "plumbing" with that in mind? > > Charles > > > > ______________________________________________________________________ > From: "Hurliman, John" > To: "mmox@ietf.org" > Sent: Tuesday, February 17, 2009 4:16:30 PM > Subject: Re: [mmox] The Story So Far... > > >-----Original Message----- > >From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com] > >Sent: Tuesday, February 17, 2009 3:42 PM > >To: Hurliman, John > >Cc: mmox@ietf.org > >Subject: Re: [mmox] The Story So Far... > > > > > >On Feb 17, 2009, at 3:09 PM, Hurliman, John wrote: > > > >>> While there is plenty to do and discuss in order to develop OGP > >>> into a > >>> fully workable protocol, we think it represents an initial shared > >>> vision > >>> of an interoperable protocol and hope it can evolve and grow in > the > >>> context of this group. > >>> > >>> - Mark Lentczner > >>> > >>> [1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol > >> > >> It's great to see the amount of work that is being brought to the > >> table by Linden Lab and the Linden Lab Architecture Working Group > >> (AWG) participants, and I hope as much of it as possible can be > used > >> to build an MMOX standard. I've been working on an LLIDL > >> implementation among other things based on what Linden Lab has > >> submitted as draft material. > > > >awesome! > > > >> It's my understanding that Open Grid Protocol (OGP) is a Linden Lab > >> project; part of the Linden Lab AWG which had no active > contributors > >> that were also active developers of libSecondLife/libOpenMetaverse > >> or OpenSim during the time the OGP protocols were designed. The > >> "agent domain" concept in OGP terminology brings in a host of > >> assumptions that are diametrically opposed to the goals of > >> libOpenMetaverse and OpenSim (supporting millions of independent > >> administrative domains and service providers). > > > >huh? there were a number of non-lindens who participated in the > >development of OGP. the AWG does not, nor did it ever disallow > >participation by libSL or libOMV contributors / committers. last > >summer we demonstrated interoperability between Linden Lab's servers > >and an OpenSim instance. we hope that members of the libSL and libOMV > >teams will participate in MMOX. > > > > I said "AWG had no active contributors that were also active > developers of libSecondLife/libOpenMetaverse or OpenSim during the > time the OGP protocols were designed". The participation by > individuals that were not Linden Lab employees does not mean that OGP > is a joint effort between Linden Lab and the libOpenMetaverse or > OpenSim projects, or that the OGP as it is drafted has support from > the libomv/OpenSim communities. > > >the concept of an agent domain was defined explicitly to support many > >different independent administrative domains. that is... though the > >interoperability test last summer used the Linden agent domain, the > >specification does not mandate a single agent domain. in fact, i > >believe Christian Scholz (a non-linden) implemented his own Agent > >Domain based on code from the PyOGP project. There is also frequent > >mention in AWG meetings of an upcoming C# implementation of an Agent > >Domain, again by a non Linden-Lab employee. > > The agent domain concept takes several independent services (identity, > presence, inventory) and lumps them together into a single trust > domain. This inhibits the development of a widely distributed > ecosystem like we find on the web today, and is really only convenient > for large virtual world service providers that already have a vertical > stack of services. It also drags in the assumption that there must be > a backend communication layer between services such as inventory and > simulation regions. > > John > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --0-1584705060-1234969572=:4561 Content-Type: text/html; charset=us-ascii

This seems a very reasonable direction and discussion. Let me toss in the current OpenSim direction as a reference.

We tend to like five server processes currently and these are split into a UserServer, GridServer, AssetServer, InventoryServer and MessagingServer.

As the situation evolves, and we seek and find a consensus, I see one of the necessary steps to finding a consensus that everyone be willing to describe and negotiation a common ground. So, thinking about Wow, Croquet & Wonderland interop with SecondLife and OpenSim seems to me a good direction to focus as it will probably allow us to get to the "what" and "how" of the plumbing and past the "why" perhaps more quickly.

Charles
From: Kajikawa Jeremy <belxjander@gmail.com>
To: "mmox@ietf.org" <mmox@ietf.org>
Sent: Wednesday, February 18, 2009 5:24:54 AM
Subject: Re: [mmox] The Story So Far...

Then the Minimum "plumbing" would be
"User Account" and "User Presence" along with some kind of 3dspace with
  "object"s present that are not a "User Presence"...

in SL terms this would be "grid"/"users" and "asset/inventory" functions
required,

in WoW terms,  a "User Account", the "Game Arena" server and then the
  Users "Item Storage" for Items picked up in the "Game Arena".

3 parts,
  1 "human" Presence and Identity,
  2 some kind of "mappable area" that is shared,
  3 interactable "objects" present in the "mappable area".

Any client functionality would be at bare minimum that and would need to
make a display
  representing the map and objects in it. would it not ?

the "AgentDomain" and "User" Services from SL would be merged for
Identity & Presence,
the "Grid" & "Region" services also appear to merge,
the "Assets" & "Inventory" services also appear to be merged,
as for messaging,  each platform has so far implimented this in some
fashion as an extended
  feature of presence,  I vote to keep this an open binding option
allowing choice of backend

does anyone see any problems with my simplification in the above 3 parts
listing?

On Tue, 2009-02-17 at 16:23 -0800, Charles Krinke wrote:
> As I think about virtual worlds and interoperability, the metaphor of
> independent states or nations come to mind. So, I guess in thinking
> about interop between virtual worlds, we can either go down the
> secondlife/opensim type of path and try to fit all virtual worlds into
> that paradigm with agentdomains or UGAIM notions or we could step back
> a bit and consider interop between
> secondlife/opensim/Wow/croquet/wonderland and others.
>
> Is is appropriate to start at a higher level and take a step back and
> consider the broader implications of virtual worlds beyond just our
> current paradigm such as WoW/croquet/wonderland and identify the
> minimum definition of network "plumbing" with that in mind?
>
> Charles
>
>
>
> ______________________________________________________________________
> From: "Hurliman, John" <john.hurliman@intel.com>
> To: "mmox@ietf.org" <mmox@ietf.org>
> Sent: Tuesday, February 17, 2009 4:16:30 PM
> Subject: Re: [mmox] The Story So Far...
>
> >-----Original Message-----
> >From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com]
> >Sent: Tuesday, February 17, 2009 3:42 PM
> >To: Hurliman, John
> >Cc: mmox@ietf.org
> >Subject: Re: [mmox] The Story So Far...
> >
> >
> >On Feb 17, 2009, at 3:09 PM, Hurliman, John wrote:
> >
> >>> While there is plenty to do and discuss in order to develop OGP
> >>> into a
> >>> fully workable protocol, we think it represents an initial shared
> >>> vision
> >>> of an interoperable protocol and hope it can evolve and grow in
> the
> >>> context of this group.
> >>>
> >>> - Mark Lentczner
> >>>
> >>> [1] http://wiki.secondlife.com/wiki/Open_Grid_Protocol
> >>
> >> It's great to see the amount of work that is being brought to the
> >> table by Linden Lab and the Linden Lab Architecture Working Group
> >> (AWG) participants, and I hope as much of it as possible can be
> used
> >> to build an MMOX standard. I've been working on an LLIDL
> >> implementation among other things based on what Linden Lab has
> >> submitted as draft material.
> >
> >awesome!
> >
> >> It's my understanding that Open Grid Protocol (OGP) is a Linden Lab
> >> project; part of the Linden Lab AWG which had no active
> contributors
> >> that were also active developers of libSecondLife/libOpenMetaverse
> >> or OpenSim during the time the OGP protocols were designed. The
> >> "agent domain" concept in OGP terminology brings in a host of
> >> assumptions that are diametrically opposed to the goals of
> >> libOpenMetaverse and OpenSim (supporting millions of independent
> >> administrative domains and service providers).
> >
> >huh? there were a number of non-lindens who participated in the
> >development of OGP. the AWG does not, nor did it ever disallow
> >participation by libSL or libOMV contributors / committers. last
> >summer we demonstrated interoperability between Linden Lab's servers
> >and an OpenSim instance. we hope that members of the libSL and libOMV
> >teams will participate in MMOX.
> >
>
> I said "AWG had no active contributors that were also active
> developers of libSecondLife/libOpenMetaverse or OpenSim during the
> time the OGP protocols were designed". The participation by
> individuals that were not Linden Lab employees does not mean that OGP
> is a joint effort between Linden Lab and the libOpenMetaverse or
> OpenSim projects, or that the OGP as it is drafted has support from
> the libomv/OpenSim communities.
>
> >the concept of an agent domain was defined explicitly to support many
> >different independent administrative domains. that is... though the
> >interoperability test last summer used the Linden agent domain, the
> >specification does not mandate a single agent domain. in fact, i
> >believe Christian Scholz (a non-linden) implemented his own Agent
> >Domain based on code from the PyOGP project. There is also frequent
> >mention in AWG meetings of an upcoming C# implementation of an Agent
> >Domain, again by a non Linden-Lab employee.
>
> The agent domain concept takes several independent services (identity,
> presence, inventory) and lumps them together into a single trust
> domain. This inhibits the development of a widely distributed
> ecosystem like we find on the web today, and is really only convenient
> for large virtual world service providers that already have a vertical
> stack of services. It also drags in the assumption that there must be
> a backend communication layer between services such as inventory and
> simulation regions.
>
> John
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
--0-1584705060-1234969572=:4561-- From lenglish5@cox.net Wed Feb 18 10:31:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2F2C3A6A17 for ; Wed, 18 Feb 2009 10:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[AWL=-0.677, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUJjiPwL-vRm for ; Wed, 18 Feb 2009 10:31:37 -0800 (PST) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id D63283A6917 for ; Wed, 18 Feb 2009 10:31:37 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090218183151.OYIT12540.fed1rmmtao106.cox.net@fed1rmimpo02.cox.net>; Wed, 18 Feb 2009 13:31:51 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id HWXp1b00J4N6T0Q04WXpEQ; Wed, 18 Feb 2009 13:31:49 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=_dmsfdfibn3F7oeD0HYA:9 a=t9P9sOrQOuywkGxFRHsA:7 a=gveOpVTerH9Hp_5Gf00d08IRxJIA:4 a=J3kPgAfI5rUA:10 X-CM-Score: 0.00 Message-ID: <499C5415.7060400@cox.net> Date: Wed, 18 Feb 2009 11:31:49 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Hurliman, John" References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:31:38 -0000 Hurliman, John wrote: > > It's my understanding that Open Grid Protocol (OGP) is a Linden Lab project; part of the Linden Lab AWG which had no active contributors that were also active developers of libSecondLife/libOpenMetaverse or OpenSim during the time the OGP protocols were designed. The "agent domain" concept in OGP terminology brings in a host of assumptions that are diametrically opposed to the goals of libOpenMetaverse and OpenSim (supporting millions of independent administrative domains and service providers). > > The current MMOX charter makes no reference to specific implementations such as Linden Lab's OGP, which I think is the correct approach. > > The Agent Domain vs HyperGrid models can be seen as somewhat extreme opposites in m dimensions of some n-dimensional space. There's plenty of room for cooperation/collaboration/assimilation/mishhashing in the middle. And other models might address n+1 dimensions as well. Lawson From john.hurliman@intel.com Wed Feb 18 11:41:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84D373A69EE for ; Wed, 18 Feb 2009 11:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.837 X-Spam-Level: X-Spam-Status: No, score=-5.837 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvWtZyzbfXHe for ; Wed, 18 Feb 2009 11:41:06 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id C57CE3A693F for ; Wed, 18 Feb 2009 11:41:06 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 18 Feb 2009 11:35:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,230,1233561600"; d="scan'208";a="432049665" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by fmsmga002.fm.intel.com with ESMTP; 18 Feb 2009 11:37:19 -0800 Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by rrsmsx602.amr.corp.intel.com (10.31.0.33) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 18 Feb 2009 12:41:19 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Wed, 18 Feb 2009 12:41:19 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Wed, 18 Feb 2009 12:41:14 -0700 Thread-Topic: [mmox] The Story So Far... Thread-Index: AcmR9zDofqw0Kyw9RgO5ulfZX2Q6jgACCO9Q Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> In-Reply-To: <499C5415.7060400@cox.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:41:07 -0000 The HyperGrid implementation in OpenSim today establishes a full trust link= between two separate service stacks (grids). It's a very clever way of com= bining grids, but doesn't address how untrusted administrative domains inte= ract with each other at all. I don't understand why you keep comparing Agen= t Domain and HyperGrid. My understanding of the Agent Domain model is that it maps every trust rela= tionship between grids to a policy decision. This is important for the busi= ness case of company X and company Y creating a partnership that is explici= tly configured, but glazes over the 99.999% use case of moving from untrust= ed grid A to untrusted grid B. I haven't seen any work from AWG addressing = the possibility of eliminating all grid<->grid communication (google.com do= esn't communicate with the links I click, the browser is perfectly capable = of managing its own state). John >-----Original Message----- >From: Lawson English [mailto:lenglish5@cox.net] >Sent: Wednesday, February 18, 2009 10:32 AM >To: Hurliman, John >Cc: mmox@ietf.org >Subject: Re: [mmox] The Story So Far... > >Hurliman, John wrote: >> >> It's my understanding that Open Grid Protocol (OGP) is a Linden Lab >project; part of the Linden Lab AWG which had no active contributors >that were also active developers of libSecondLife/libOpenMetaverse or >OpenSim during the time the OGP protocols were designed. The "agent >domain" concept in OGP terminology brings in a host of assumptions that >are diametrically opposed to the goals of libOpenMetaverse and OpenSim >(supporting millions of independent administrative domains and service >providers). >> >> The current MMOX charter makes no reference to specific >implementations such as Linden Lab's OGP, which I think is the correct >approach. >> >> > >The Agent Domain vs HyperGrid models can be seen as somewhat extreme >opposites in m dimensions of some n-dimensional space. There's plenty of >room for cooperation/collaboration/assimilation/mishhashing in the >middle. > >And other models might address n+1 dimensions as well. > > >Lawson > > >=20 From john.hurliman@intel.com Wed Feb 18 12:40:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B216728C1D3 for ; Wed, 18 Feb 2009 12:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCnXSQdUs3TC for ; Wed, 18 Feb 2009 12:40:01 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 124443A69F9 for ; Wed, 18 Feb 2009 12:40:01 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 18 Feb 2009 12:40:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,230,1233561600"; d="scan'208";a="112002144" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by azsmga001.ch.intel.com with ESMTP; 18 Feb 2009 12:39:50 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 18 Feb 2009 13:39:50 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Wed, 18 Feb 2009 13:39:43 -0700 Thread-Topic: More LLIDL questions Thread-Index: AcmSCQdElIdDvWmrRs66TZORxodjTQ== Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {A243B84A-EDA7-4615-8530-418CB49650A5} x-cr-hashedpuzzle: AFZp ATxL Acfu Af0B A2uo Ef/h E0LG F8rT GiWy GluN HS0v HXq4 JXtr Jhju KdmR Kifs; 1; bQBtAG8AeABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {A243B84A-EDA7-4615-8530-418CB49650A5}; agBvAGgAbgAuAGgAdQByAGwAaQBtAGEAbgBAAGkAbgB0AGUAbAAuAGMAbwBtAA==; Wed, 18 Feb 2009 20:39:43 GMT;TQBvAHIAZQAgAEwATABJAEQATAAgAHEAdQBlAHMAdABpAG8AbgBzAA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mmox] More LLIDL questions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 20:40:01 -0000 ; An LLSD value containing { member1 : true, member2 : true } comes in. Is = member3 a string or an int? &a =3D { member1 : true, member2 : false, member3 : string } &a =3D { member1 : false, member2 : true, member3 : int } ; How is a parser supposed to handle this? &b =3D { $ : &b } ; Or this? &c =3D { $ : &d } &d =3D { $ : &c } ; The first variant has the type uri. The second variant has the type strin= g? &e =3D uri &e =3D "http://www.google.com/" ; Forward-slash seems like an odd addition to 0-9+A-Z. Why this character? &f/ =3D "hello slash" John From lenglish5@cox.net Wed Feb 18 13:14:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0380028C20E for ; Wed, 18 Feb 2009 13:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.224 X-Spam-Level: * X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCQXrv6oI+9W for ; Wed, 18 Feb 2009 13:14:47 -0800 (PST) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id 6A1B628C210 for ; Wed, 18 Feb 2009 13:14:36 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090218211448.ZSHJ12540.fed1rmmtao106.cox.net@fed1rmimpo02.cox.net>; Wed, 18 Feb 2009 16:14:48 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id HZEo1b00V4N6T0Q04ZEoXj; Wed, 18 Feb 2009 16:14:49 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=m7bZuVvDW09Eo6cLl7sA:9 a=eWfBPn2v1Vba4kz0LLEA:7 a=IoULF0eJCANvl2I6tPwI_fEzwVQA:4 a=UTB_XpHje0EA:10 a=J3kPgAfI5rUA:10 X-CM-Score: 0.00 Message-ID: <499C7A48.4010108@cox.net> Date: Wed, 18 Feb 2009 14:14:48 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Hurliman, John" References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:14:48 -0000 Hurliman, John wrote: > The HyperGrid implementation in OpenSim today establishes a full trust link between two separate service stacks (grids). It's a very clever way of combining grids, but doesn't address how untrusted administrative domains interact with each other at all. I don't understand why you keep comparing Agent Domain and HyperGrid. > > My understanding of the Agent Domain model is that it maps every trust relationship between grids to a policy decision. This is important for the business case of company X and company Y creating a partnership that is explicitly configured, but glazes over the 99.999% use case of moving from untrusted grid A to untrusted grid B. I haven't seen any work from AWG addressing the possibility of eliminating all grid<->grid communication (google.com doesn't communicate with the links I click, the browser is perfectly capable of managing its own state). > > John > As I understand it, Agent Domain and HyperGrid approach many of the same issues from two directions. That's the reason for mentioning them in the same sentence. Lawson From jwatte@gmail.com Wed Feb 18 13:33:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF1528C228 for ; Wed, 18 Feb 2009 13:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82EaMsKF4a44 for ; Wed, 18 Feb 2009 13:33:51 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 100EA28C223 for ; Wed, 18 Feb 2009 13:33:49 -0800 (PST) Received: by qyk4 with SMTP id 4so190496qyk.13 for ; Wed, 18 Feb 2009 13:34:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=zoUYrON9J9wwdPHemEKtBUapGDMMRLX7j9Ij0cpAs8U=; b=SX7rEX0n89K/XCBIj9NRKiwVGlKZpsSjRUoZKGw57OKw64W0jumMNlPwworjy577np yIVRVfJDGvtpsvZ25pCH3UthfgORAEnTkmdSpyw2TuZ9kCyedJL6MHTqJCQBFqVeQYoi RBlBU/pxAD3QoLMfUvJlT6xY0pDn9MuKJc9Zc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=m8NFIUIElDrGToXZRKALzZVivreWWxC4g61gsKgg0rYkvnwsyVlliJWTAKyT0ZGy3Q FTrHr150gmp+fRhJhFgftl2pi/L8Kb9IYJYWjE9N+PtQNrNIA5LKPtDt5EPN/S1ubb8h uyMMTaLUVxWzKJ7/OzlFBUk5ji6zJ2JEjUPBw= Received: by 10.229.100.7 with SMTP id w7mr79679qcn.5.1234992841731; Wed, 18 Feb 2009 13:34:01 -0800 (PST) Received: from ?192.168.168.101? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id 9sm694071yws.55.2009.02.18.13.34.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 13:34:01 -0800 (PST) Message-ID: <499C7EC7.9070701@gmail.com> Date: Wed, 18 Feb 2009 13:33:59 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mark Lentczner References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> In-Reply-To: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:33:51 -0000 Mark Lentczner wrote: > While there is plenty to do and discuss in order to develop OGP into a > fully workable protocol, we think it represents an initial shared > vision of an interoperable protocol and hope it can evolve and grow in > the context of this group. In my opinion, OGP is too Second Life specific to serve as a useful basis for a vendor neutral interoperability standard. If that is the basis for this IETF working group, then there's no need for me, or any other virtual world vendors, to be here. Standardizing Second Life protocols might be useful for the Second Life sub-universe of virtual worlds, but I think trying to call it "generally interoperable" would be stretching the truth past bursting. There's too much content and too many players in production today using vastly different technologies for that to work. See a different message for what I think is a great use case/scenario for what "interoperability" actually looks like (which I think we need to agree on before lower-level details like what kinds of protocols we'll need can be defined). Sincerely, jw From jwatte@gmail.com Wed Feb 18 13:34:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24F328C228 for ; Wed, 18 Feb 2009 13:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoSzz7RLiLs2 for ; Wed, 18 Feb 2009 13:34:23 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id A87F028C231 for ; Wed, 18 Feb 2009 13:34:23 -0800 (PST) Received: by qyk4 with SMTP id 4so190980qyk.13 for ; Wed, 18 Feb 2009 13:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4Rdvde7PZ8IMS6VYgW8stGZknkgy7aFNRnbTyiLJW7M=; b=F7HPyo+4bHIzbRj7Lyh+3v3HM6FK/fM/U8jpT+QlL6N92PGDxHaETLG4eJOSebheoX C836w5W2avxDM0kZlabNvqiDE4DPmZZiHecxuyBuAX+Qh07ZlculZJReEs/udtkiOR9C e11XLnDMuqjmfO5PZaEslauWY3lrW9qEFJ97o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=OcoxUEYi2VA58DdNSRERBq2jtsqaCI+TY1i64TuC+3YvD6m4jtam3HsShp5z/TLHij 03gXXiQevbLkqiye6cUY/hAgautp95lTcfSkUuoqH1qTRNHkWpT9ehqJ7GlDJtKaaJZ2 IA5VlCOsfnrubJOEH3e1asY9cUNuSWXM0g5vQ= Received: by 10.229.74.79 with SMTP id t15mr3538539qcj.2.1234992875825; Wed, 18 Feb 2009 13:34:35 -0800 (PST) Received: from ?192.168.168.101? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id 7sm338871ywo.37.2009.02.18.13.34.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 13:34:35 -0800 (PST) Message-ID: <499C7EE9.9050606@gmail.com> Date: Wed, 18 Feb 2009 13:34:33 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090214.132623.14940.0@webmail08.vgs.untd.com> In-Reply-To: <20090214.132623.14940.0@webmail08.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 33 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:34:24 -0000 dyerbrookme@juno.com wrote: > What that means is when you say "metadata" should be built in, the question then comes: how, and *as what*? Your invocation of the There model, which involve having users submit all their content to be cleared -- and then implicitly IP-secured -- by the platform provider -- That's a great question, and something that needs to be answered by the standard, when it appears. My initial suggestion was that it include authorship information, sharing right information (copylefted, copyrighted, time trial, and probably other models) and finally intermediate storage information (is a server allowed to cache the data for the possibility it's used in the future? What about clients?) In general, copyright is very well understood, and is not treated differently in the eyes of US law in the digital world from the physical world. For example, the source for textures, or the source for a mesh, is generally copyrighted. However, that doesn't necessarily prevent me from building (from scratch) something that looks very similar, but it does tell me that I can't just take your stuff verbatim. Tagging digital assets with metadata, which includes licensing terms, is common sense, and is done with almost all digital media formats. I see no reason why virtual world standards would be any different. If, for some reason, the sharing of content through interoperability is against someone's wishes as a creator, then I would assume that some platforms would implement platform-specific means to prevent content from being shared over the interoperability channel, and users who cared about interoperability would choose not to purchase that content. Creators would then choose their platform, and their specific use of that platform, according to how they feel would best serve their interests. I don't think that needs to be mandated in an interoperability specification. Now, what users, and other systems, do with the metadata information is, to some extent, not controllable from the standard. The standard may say "copyright restrictions must be enforced within the user interface of a conforming implementation" -- but that doesn't mean much. An implementation may be non-conforming, or tools that rip data from hard disks can still exist, so it won't be a magic panacea. Sincerely, jw From jwatte@gmail.com Wed Feb 18 13:37:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9876D28C235 for ; Wed, 18 Feb 2009 13:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Effu11-Dc8rk for ; Wed, 18 Feb 2009 13:37:40 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id D63AE28C234 for ; Wed, 18 Feb 2009 13:37:39 -0800 (PST) Received: by qyk4 with SMTP id 4so193886qyk.13 for ; Wed, 18 Feb 2009 13:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=SFrTpXuMWykCUubbA3dNMxi6zsmz5qgZ+bnGV51KdBQ=; b=wMfkv3eyzXhw3e9emD2++oHQ0jf51ArDBrEJh8A/mkOgI6ImVSYo17OWc8kFs1DOmb ma6Ru9JGvUQGQPTdkHfc/dXhH+RNhnT3CieqMCczthAnrlmXcp+KozOVXvB0G9rQ+9SU pYcdFJdlX3Nto3vk+dhYQwsg/m3NJXBG+uZdg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Q51vbbFJOxXickTO0H4WM1rvBMqpyeRziVJ1bngZMVGaDmaRn3LdbXiCt/K7EbDB3P EYFZ3kYtN7rnIoaQMzxHBYh9fhBwBmtIXpIHoklXTSDXIe++XQHbAKRYnm0Np2GTH1Wz AYt5I6ATSqXI3garTdp5lKWmzpigQtPXZcZJw= Received: by 10.224.20.15 with SMTP id d15mr13338516qab.36.1234993072227; Wed, 18 Feb 2009 13:37:52 -0800 (PST) Received: from ?192.168.168.101? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id 8sm705562ywg.54.2009.02.18.13.37.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 13:37:51 -0800 (PST) Message-ID: <499C7FAD.4080009@gmail.com> Date: Wed, 18 Feb 2009 13:37:49 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ann Otoole References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> In-Reply-To: <77186.32658.qm@web59104.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:37:40 -0000 Ann Otoole wrote: > My opinion is that interop would be best served through a standard > mesh and texture subsystem on all grids and teleport between grids > consists of transferring the mesh and associated textures (if not > already present in the target grid asset What end-user value does "teleport between grids" solve? In my opinion, that feature is very un-interesting, as it requires lots of engineering, and gives very little value, compared to lower-hanging fruit like physical spaces shared across interoperating servers. Sincerely, jw From cfk@pacbell.net Wed Feb 18 13:55:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 016E328C0EC for ; Wed, 18 Feb 2009 13:55:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VBURLVxISSx for ; Wed, 18 Feb 2009 13:55:47 -0800 (PST) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id EC2963A695C for ; Wed, 18 Feb 2009 13:55:46 -0800 (PST) Received: (qmail 29998 invoked by uid 60001); 18 Feb 2009 21:55:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=6CPKr/rYNOumS5I0Ounl8LZTTI2Yr+QIy+eB7ztv+Tk7U+rYLg2HtL0wGLoabIzofumTZAHo1XkyGK0CEqmdLHAY9mgfmlUJ/7g+UOsTiehoiinhtbU0xGs7xzpKd0GD76FWmX7aUTIrTaazV8zdMrMR/5TGbzbRT2v1UywtOZY=; X-YMail-OSG: tZP5t.QVM1kts.lkHirf3abAKY0nKhMsn.N.GS0MQpiudo2Fq51CFCsSt1tigvYIuUryXlTRSl_NLCsDdF34JjFhPuyhuJgTjmaktkcBZSF4uRT4YJmL6OOPwp1F5difWNv5WWIDy_en6gVc3XSrBAo8spmvPCcEL9dg3AFculJ5qzxMP14QxNm8La3weiGF4niwWU5XV.0.b3tgNc9q2ywjv1Y- Received: from [75.215.15.96] by web82607.mail.mud.yahoo.com via HTTP; Wed, 18 Feb 2009 13:55:59 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> Date: Wed, 18 Feb 2009 13:55:59 -0800 (PST) From: Charles Krinke To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-801988043-1234994159=:26941" Message-ID: <659848.26941.qm@web82607.mail.mud.yahoo.com> Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:55:48 -0000 --0-801988043-1234994159=:26941 Content-Type: text/plain; charset=us-ascii Dear Jon: I tend to agree with your direction. Although my personal work has involved OpenSim and SecondLife, I too, would like to see a standard evolve that considers a consensus among many virtual worlds implementations. To to that, we first have to find the lowest common denominator between the set of virtual worlds to be considered and see if we can get a consensus on at least *one* point to start moving forward. And, no matter what happens in this group, we also have to consider that representatives from several virtual worlds are reading what we say here and evolving their logic in a way that suits their perception of where the whole industry is going. So, it behooves us to find that lowest common denominator and see if we can create a useful specification to avoid wasting any of our time. I have to believe that there exists a subset of the SecondLife OGP and HyperGrid notions that can at least form a basis to start building. If not, perhaps someone can propose such a basis. Charles ________________________________ From: Jon Watte To: Ann Otoole Cc: mmox@ietf.org Sent: Wednesday, February 18, 2009 1:37:49 PM Subject: Re: [mmox] User Accounts / "Object" Transfer. Ann Otoole wrote: > My opinion is that interop would be best served through a standard mesh and texture subsystem on all grids and teleport between grids consists of transferring the mesh and associated textures (if not already present in the target grid asset What end-user value does "teleport between grids" solve? In my opinion, that feature is very un-interesting, as it requires lots of engineering, and gives very little value, compared to lower-hanging fruit like physical spaces shared across interoperating servers. Sincerely, jw _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-801988043-1234994159=:26941 Content-Type: text/html; charset=us-ascii
Dear Jon:

I tend to agree with your direction. Although my personal work has involved OpenSim and SecondLife, I too, would like to see a standard evolve that considers a consensus among many virtual worlds implementations.

To to that, we first have to find the lowest common denominator between the set of virtual worlds to be considered and see if we can get a consensus on at least *one* point to start moving forward.

And, no matter what happens in this group, we also have to consider that representatives from several virtual worlds are reading what we say here and evolving their logic in a way that suits their perception of where the whole industry is going.

So, it behooves us to find that lowest common denominator and see if we can create a useful specification to avoid wasting any of our time. I have to believe that there exists a subset of the SecondLife OGP and HyperGrid notions that can at least form a basis to start building. If not, perhaps someone can propose such a basis.

Charles

From: Jon Watte <jwatte@gmail.com>
To: Ann Otoole <missannotoole@yahoo.com>
Cc: mmox@ietf.org
Sent: Wednesday, February 18, 2009 1:37:49 PM
Subject: Re: [mmox] User Accounts / "Object" Transfer.

Ann Otoole wrote:
> My opinion is that interop would be best served through a standard mesh and texture subsystem on all grids and teleport between grids consists of transferring the mesh and associated textures (if not already present in the target grid asset

What end-user value does "teleport between grids" solve?

In my opinion, that feature is very un-interesting, as it requires lots of engineering, and gives very little value, compared to lower-hanging fruit like physical spaces shared across interoperating servers.

Sincerely,

jw

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--0-801988043-1234994159=:26941-- From suzyque@gmail.com Wed Feb 18 13:56:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E7CF3A6AE6 for ; Wed, 18 Feb 2009 13:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHRaWZdXtMfl for ; Wed, 18 Feb 2009 13:56:18 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 6E2923A695C for ; Wed, 18 Feb 2009 13:56:18 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so53118qwe.31 for ; Wed, 18 Feb 2009 13:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=l2oKIHJwH/Kc8YyMTjaeQ76zbulddcAgFIv35YvXlNM=; b=vgQ8HpLKL6HEt5c6gjd89X7TSgMwbcdJstoMjv77KAFka4yPfSMNh63FZycSEsq1qM xgHcS0QVWojLROEy+0BX+F/24w+PqNGUol55ZU3BuCmS1OrbbOeBkeXJLye2AlLnYZC2 xWhwS+rR14YtPWBWzLNHlswi1GpEgKsERQosk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QRqxofd040gjS3MbtZV54YdaRbxfWlUd6ke+UGTO0uBlugyyIRfHDfds7vNCVtOvRt IfP8Kdt1eSDUSkqrRSFRwBW/uRRQoD+lWPxtWEXhYeP10Jjbh/vDI5UWFDgexBe61WBK Fxq+3nQ+oDxWOJAhz1cAmmklLlTB3o5K39/vw= MIME-Version: 1.0 Sender: suzyque@gmail.com Received: by 10.224.67.142 with SMTP id r14mr9085790qai.286.1234994190054; Wed, 18 Feb 2009 13:56:30 -0800 (PST) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> Date: Wed, 18 Feb 2009 15:56:29 -0600 X-Google-Sender-Auth: f9bae225b43d6438 Message-ID: <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> From: Suzy Deffeyes To: "Hurliman, John" Content-Type: multipart/alternative; boundary=0015175ca948ff77950463387d5d Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: suzyq@pobox.com List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:56:19 -0000 --0015175ca948ff77950463387d5d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 18, 2009 at 1:41 PM, Hurliman, John wrote: > The HyperGrid implementation in OpenSim today establishes a full trust link > between two separate service stacks (grids). It's a very clever way of > combining grids, but doesn't address how untrusted administrative domains > interact with each other at all. I don't understand why you keep comparing > Agent Domain and HyperGrid. > > My understanding of the Agent Domain model is that it maps every trust > relationship between grids to a policy decision. This is important for the > business case of company X and company Y creating a partnership that is > explicitly configured, but glazes over the 99.999% use case of moving from > untrusted grid A to untrusted grid B. I haven't seen any work from AWG > addressing the possibility of eliminating all grid<->grid communication ( > google.com doesn't communicate with the links I click, the browser is > perfectly capable of managing its own state). For the google 2d browsing analogy, I don't need to see a representation of other people that also happen to be visiting that same link, and I also don't have a name and 3D representation of myself that I want to remain consistent on my screen as I go from link to link. In our MMOX space, it can be desirable to have a consistent representation of self that also appears the same to others in the same region. Not always, but for a fair number of use cases that involve teleportation it does. I'm not sure how that can happen if we eliminate all grid to grid communication. Maybe Agent Domain type implementations 'squirt' too much state along with an agent that is being transferred into a region. Maybe we need to tease that apart. I think the actual OGP implementation right now just squirts your name, UUID, a few bits, and desired location into the region. Suzy Deffeyes IBM --0015175ca948ff77950463387d5d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 18, 2009 at 1:41 PM, Hurlima= n, John <jo= hn.hurliman@intel.com> wrote:
The HyperGrid implementation in OpenSim today establishes a full trust link= between two separate service stacks (grids). It's a very clever way of= combining grids, but doesn't address how untrusted administrative doma= ins interact with each other at all. I don't understand why you keep co= mparing Agent Domain and HyperGrid.

My understanding of the Agent Domain model is that it maps every trust rela= tionship between grids to a policy decision. This is important for the busi= ness case of company X and company Y creating a partnership that is explici= tly configured, but glazes over the 99.999% use case of moving from untrust= ed grid A to untrusted grid B. I haven't seen any work from AWG address= ing the possibility of eliminating all grid<->grid communication (google.com doesn't com= municate with the links I click, the browser is perfectly capable of managi= ng its own state).

For the google 2d browsing analogy, I don't need to see a repr= esentation of other people that also happen to be visiting that same link, = and I also don't have a name and 3D representation of myself that I wan= t to remain consistent on my screen as I go from link to link.

In our MMOX space, it can be desirable to have a consistent representat= ion of self that also appears the same to others in the same region. Not al= ways, but for a fair number of use cases that involve teleportation it does= . I'm not sure how that can happen if we eliminate all grid to grid com= munication.

Maybe Agent Domain type implementations 'squirt' too much state= along with an agent that is being transferred into a region. Maybe we need= to tease that apart.  I think the actual OGP implementation right now= just squirts your name, UUID, a few bits, and desired location into the re= gion.

Suzy Deffeyes
IBM

--0015175ca948ff77950463387d5d-- From cathypfeffer@gmail.com Wed Feb 18 14:00:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DCC28C0EA for ; Wed, 18 Feb 2009 14:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlRwVZZJIlYE for ; Wed, 18 Feb 2009 14:00:49 -0800 (PST) Received: from mail-ew0-f31.google.com (mail-ew0-f31.google.com [209.85.219.31]) by core3.amsl.com (Postfix) with ESMTP id E55443A6925 for ; Wed, 18 Feb 2009 14:00:48 -0800 (PST) Received: by ewy12 with SMTP id 12so49461ewy.13 for ; Wed, 18 Feb 2009 14:00:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=J5k7jIykLD76Shav21YA1BNday9O4Jzq3s0EIXQm+RA=; b=vGqCpwR3J7uGY9Qn9H28GLjGwx25QMg1KrAlG4H/VpAISL5UugWvVXrzy5cUL66dk+ YZd4cV8zCK9yfyFsSrFNOwnD9XfFlNdOFiGRKloaC+oowEAEZ7RCHJXxqTNJp6JFR4N/ 7xsOVUZEhz+NqWDmQaINXIdscABJdN8PvqH4Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZeVkUxuQcVU+yTknOJjtuEasCoOEXL5L4Dl7D343YW/dKbUS7Zcl0t0pShiGHxw1ra YHBRVSo28viIS6bCnkb4SdfdWONk1UC9nU/8NRpFHfO85IsSkvl4eGlq9Iv3K7gD7Bn1 WAOh9v7Th8AINknL8x0aWLnF3bfc7ncuUWkzs= MIME-Version: 1.0 Received: by 10.210.19.7 with SMTP id 7mr6592148ebs.169.1234994459198; Wed, 18 Feb 2009 14:00:59 -0800 (PST) Date: Wed, 18 Feb 2009 23:00:59 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c34a20a470f0463388e8c Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:00:50 -0000 --0015174c34a20a470f0463388e8c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, nice to meet you all, I am Catherine Pfeffer in Second Life. In real life, I am an engineer in computer science, and I run a small technical documentation company. My (limited) knowledge of LLSD comes from a few open source contributions to SL. I am mostly a tourist in the AWG group and on the IETF mailing list. I'm staying here because of intellectual curiosity. I hope nobody minds that ;-). Best, -- Cathy --0015174c34a20a470f0463388e8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, nice to meet you all,


I am Catherine Pfeffer in Second Life.= In real life, I am an engineer in computer science, and I run a small tech= nical documentation company.

My (limited) knowledge of LLSD comes fr= om a few open source contributions to SL. I am mostly a tourist in the AWG = group and on the IETF mailing list. I'm staying here because of intelle= ctual curiosity. I hope nobody minds that ;-).


Best,

--
Cathy
--0015174c34a20a470f0463388e8c-- From suzyque@gmail.com Wed Feb 18 14:04:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67A63A67B5 for ; Wed, 18 Feb 2009 14:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwmvXkL-Rf+k for ; Wed, 18 Feb 2009 14:04:48 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 0D0713A68EC for ; Wed, 18 Feb 2009 14:04:19 -0800 (PST) Received: by qyk4 with SMTP id 4so215964qyk.13 for ; Wed, 18 Feb 2009 14:04:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=y+2MS1BcYpu7B+zpacoqMjUAaNrx+FnyJRYSysGFfaQ=; b=bZCbDrOP34RtWBJIdN8JrgZPtIN2IkxyfG6ChJKUutm/1+kcZxaiFKSR9vc5w+t5qF zxQYnP4WJyoty/eiCnWeFYdyNDUFqMTqlnOMa8gQo4BC9wdNURtojOfO6KCaS+feQQAS 5q4O4xUJLy6dqqUSOdia0s/QQNu6zeGBhkLAs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=oit+RVxa0PGAzHOIb2vY543qOBqCtBtuQtKzetH+Xrjfb04qbk6GK5jZ7Yf/Xm7qIR +FkSV70+zJagXqYJGR7zxaZ7csaY4IfT0UUAZv/oRG5xmMfmNps+JPjO9ScF30BAqb1t OeH94TjQ71mw6IdnzEIOTiNrNtoveaOQJeylk= MIME-Version: 1.0 Sender: suzyque@gmail.com Received: by 10.224.14.197 with SMTP id h5mr13404481qaa.5.1234994671859; Wed, 18 Feb 2009 14:04:31 -0800 (PST) In-Reply-To: <499C7FAD.4080009@gmail.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> Date: Wed, 18 Feb 2009 16:04:31 -0600 X-Google-Sender-Auth: caa86ac85aaec63a Message-ID: <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> From: Suzy Deffeyes To: Jon Watte Content-Type: multipart/alternative; boundary=0015175ccf1ab737c20463389ae1 Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: suzyq@pobox.com List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:04:49 -0000 --0015175ccf1ab737c20463389ae1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 18, 2009 at 3:37 PM, Jon Watte wrote: > Ann Otoole wrote: > >> My opinion is that interop would be best served through a standard mesh >> and texture subsystem on all grids and teleport between grids consists of >> transferring the mesh and associated textures (if not already present in the >> target grid asset >> > > What end-user value does "teleport between grids" solve? > > In my opinion, that feature is very un-interesting, as it requires lots of > engineering, and gives very little value, compared to lower-hanging fruit > like physical spaces shared across interoperating servers. > > Hi Jon, Thanks for offering a perspective outside the Second Life / OpenSim bubble. Can you elaborate on " physical spaces shared across interoperating servers " and what you mean by that? Suzy Deffeyes IBM --0015175ccf1ab737c20463389ae1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 18, 2009 at 3:37 PM, Jon Wat= te <jwatte@gmail.c= om> wrote:
Ann Otoole wrote:
My opinion is that interop would be best served through a standard mesh and= texture subsystem on all grids and teleport between grids consists of tran= sferring the mesh and associated textures (if not already present in the ta= rget grid asset

What end-user value does "teleport between grids" solve?

In my opinion, that feature is very un-interesting, as it requires lots of = engineering, and gives very little value, compared to lower-hanging fruit l= ike physical spaces shared across interoperating servers.


Hi Jon,

Thanks for offering a perspective out= side the Second Life / OpenSim bubble.

Can you elaborate on " = physical spaces shared across interoperating servers " and what you me= an by that?

Suzy Deffeyes
IBM
--0015175ccf1ab737c20463389ae1-- From lenglish5@cox.net Wed Feb 18 14:08:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE9D3A6983 for ; Wed, 18 Feb 2009 14:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_BACKHAIR_27=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4t4L6fVm+roJ for ; Wed, 18 Feb 2009 14:08:44 -0800 (PST) Received: from fed1rmmtao104.cox.net (fed1rmmtao104.cox.net [68.230.241.42]) by core3.amsl.com (Postfix) with ESMTP id 8B73B3A695C for ; Wed, 18 Feb 2009 14:08:44 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090218220855.CYRG16134.fed1rmmtao104.cox.net@fed1rmimpo03.cox.net>; Wed, 18 Feb 2009 17:08:55 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id Ha8u1b00U4N6T0Q04a8vw3; Wed, 18 Feb 2009 17:08:55 -0500 X-Authority-Analysis: v=1.0 c=1 a=QKBZPeLtCf0A:10 a=tzJAS5yeDgcA:10 a=Wajolswj7cQA:10 a=Z1WmqM4zBW1FuO7M8joA:9 a=5bUpU6muO6uxzo7CiRwA:7 a=5pNoHfaww6dvJ_ZCZNrFiw79qJAA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <499C86F6.8000708@cox.net> Date: Wed, 18 Feb 2009 15:08:54 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> In-Reply-To: <499C7FAD.4080009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:08:45 -0000 Jon Watte wrote: > Ann Otoole wrote: >> My opinion is that interop would be best served through a standard >> mesh and texture subsystem on all grids and teleport between grids >> consists of transferring the mesh and associated textures (if not >> already present in the target grid asset > > What end-user value does "teleport between grids" solve? > > In my opinion, that feature is very un-interesting, as it requires > lots of engineering, and gives very little value, compared to > lower-hanging fruit like physical spaces shared across interoperating > servers. > > Sincerely, > > jw > The OGP solution, at least for SL<=>OpenSim, actually makes TP a special case of the shared physical space. In theory, at least with SL and OPenSim, if two grids shared trust for object sharing and supported the same TP protocol they could share the same visual/relative-physical space as well. It's the simplest possible scenario to implement it--sharing between two worlds where one was designed to be compatible with the other and the other is making an attempt to meet the first halfway--but it's a model that might be workable for less SL-centric worlds as well. At the least, I could see TP via Croquet and SL/Open Sim via a portal using the OGP protocol as a model. Not sure that Croquet supports shared visual borders outside the portals so the larger issue may not apply anyway. L. From cfk@pacbell.net Wed Feb 18 14:13:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0EA93A68EC for ; Wed, 18 Feb 2009 14:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_27=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nesSrzXILrTy for ; Wed, 18 Feb 2009 14:13:31 -0800 (PST) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id E06483A68D8 for ; Wed, 18 Feb 2009 14:13:30 -0800 (PST) Received: (qmail 46293 invoked by uid 60001); 18 Feb 2009 22:13:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=5ilziVJrSO1jSahfwG4muRF08rANYimKZZz8fnX9dS/cck41QwDDdj1kvt2WcwpaBu4QftlJh5TGm2Fxwpr/8MjnF3nzkGADfeFJrCCn8tROjTbcLeIBoiiL725hsrPCAwBIgpACfihGRmkypCk8nuoE0SRgRRSi1k0sibJAQgU=; X-YMail-OSG: lZGFzeoVM1nYEQGvMpohwt4z89YTOaUnaYm27Nuzqtk.Uf31_6lygzs71ahJJ8czttjjb6DJI_zkWyqw70ZkfoTTCJ1Ao7sVNsCO83JBwEhNKhkCGA2oW_7PPHoazbqb_nxckbpup8rwremMDAlG9w9xEKcQFOMRo_hwF_NQg2Rdj0g6TbFDHQ6VihCIymxlWLLaM.yh0_Hivr_uFYUZTcd4C2E- Received: from [75.215.15.96] by web82607.mail.mud.yahoo.com via HTTP; Wed, 18 Feb 2009 14:13:43 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <499C86F6.8000708@cox.net> Date: Wed, 18 Feb 2009 14:13:43 -0800 (PST) From: Charles Krinke To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1857571731-1234995223=:2238" Message-ID: <580839.2238.qm@web82607.mail.mud.yahoo.com> Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:13:32 -0000 --0-1857571731-1234995223=:2238 Content-Type: text/plain; charset=us-ascii Dear Lawson: This is starting to get really interesting. I did have a conversation with the Croquet folks about such a shared space teleport on their Java newsgroup a couple of months ago and their feeling was "Thats great, Charles, shouldnt be too difficult, how about if we assign you to write the Croquet side". So, nothing much came of the conversation. But, ... if it turned out that a small team might like to see if they can actually prototype such a gateway, whether there is visibility through the portal or not, this in itself might head the whole group in a very interesting direction. Charles ________________________________ From: Lawson English To: Jon Watte Cc: mmox@ietf.org Sent: Wednesday, February 18, 2009 2:08:54 PM Subject: Re: [mmox] User Accounts / "Object" Transfer. Jon Watte wrote: > Ann Otoole wrote: >> My opinion is that interop would be best served through a standard mesh and texture subsystem on all grids and teleport between grids consists of transferring the mesh and associated textures (if not already present in the target grid asset > > What end-user value does "teleport between grids" solve? > > In my opinion, that feature is very un-interesting, as it requires lots of engineering, and gives very little value, compared to lower-hanging fruit like physical spaces shared across interoperating servers. > > Sincerely, > > jw > The OGP solution, at least for SL<=>OpenSim, actually makes TP a special case of the shared physical space. In theory, at least with SL and OPenSim, if two grids shared trust for object sharing and supported the same TP protocol they could share the same visual/relative-physical space as well. It's the simplest possible scenario to implement it--sharing between two worlds where one was designed to be compatible with the other and the other is making an attempt to meet the first halfway--but it's a model that might be workable for less SL-centric worlds as well. At the least, I could see TP via Croquet and SL/Open Sim via a portal using the OGP protocol as a model. Not sure that Croquet supports shared visual borders outside the portals so the larger issue may not apply anyway. L. _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-1857571731-1234995223=:2238 Content-Type: text/html; charset=us-ascii
Dear Lawson:

This is starting to get really interesting. I did have a conversation with the Croquet folks about such a shared space teleport on their Java newsgroup a couple of months ago and their feeling was "Thats great, Charles, shouldnt be too difficult, how about if we assign you to write the Croquet side". So, nothing much came of the conversation.

But, ... if it turned out that a small team might like to see if they can actually prototype such a gateway, whether there is visibility through the portal or not, this in itself might head the whole group in a very interesting direction.

Charles

From: Lawson English <lenglish5@cox.net>
To: Jon Watte <jwatte@gmail.com>
Cc: mmox@ietf.org
Sent: Wednesday, February 18, 2009 2:08:54 PM
Subject: Re: [mmox] User Accounts / "Object" Transfer.

Jon Watte wrote:
> Ann Otoole wrote:
>> My opinion is that interop would be best served through a standard mesh and texture subsystem on all grids and teleport between grids consists of transferring the mesh and associated textures (if not already present in the target grid asset
>
> What end-user value does "teleport between grids" solve?
>
> In my opinion, that feature is very un-interesting, as it requires lots of engineering, and gives very little value, compared to lower-hanging fruit like physical spaces shared across interoperating servers.
>
> Sincerely,
>
> jw
>

The OGP solution, at least for SL<=>OpenSim, actually makes TP a special case of the shared physical space.

In theory, at least with SL and OPenSim, if two grids shared trust for object sharing and supported the same TP protocol they could share the same visual/relative-physical space as well.


It's the simplest possible scenario to implement it--sharing between two worlds where one was designed to be compatible with the other and the other is making an attempt to meet the first halfway--but it's a model that might be workable for less SL-centric worlds as well.

At the least, I could see TP via Croquet and SL/Open Sim via a portal using the OGP protocol as a model. Not sure that Croquet supports shared visual borders outside the portals so the larger issue may not apply anyway.


L.


_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--0-1857571731-1234995223=:2238-- From cfk@pacbell.net Wed Feb 18 14:45:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4A03A6866 for ; Wed, 18 Feb 2009 14:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etcFlchJsi61 for ; Wed, 18 Feb 2009 14:45:38 -0800 (PST) Received: from web82608.mail.mud.yahoo.com (web82608.mail.mud.yahoo.com [68.142.201.125]) by core3.amsl.com (Postfix) with SMTP id DDDBB3A685B for ; Wed, 18 Feb 2009 14:45:37 -0800 (PST) Received: (qmail 49578 invoked by uid 60001); 18 Feb 2009 22:04:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=P0iuHW8vRz0zN4LKj4HjuiTiwNOUpUlOfpTPE2LlwCYC2ok6st5b8bzgdz7pkWamfcmC/S6zYFDhYPXgR9qn0OhMOILlq/i3dg/4/RTVXbIj/L1rRL2Xnb6N5Cod4I0Xc0ShV7zbRLyuS6tnr7dNWslbFNGdRLEp416InLV1/YQ=; X-YMail-OSG: 2IXqT5EVM1lZuRnR9etcCDBxtTw7OnGG40u8s_Mv0GLs.3DM2RR3tEba2zUH.Y895wWMebdEa36StliWrVGGKWoTNJYc36i08X4m7APbq5U0hSxSwFRiSsX05aVaP5IpzVorNAzUMJ_NEtcGV95_2LJVn2w0JN9JvNvM_rpadgviaw7IbBQIwdpRT7yenP8VkWy6VHGu6eI0Og-- Received: from [75.215.15.96] by web82608.mail.mud.yahoo.com via HTTP; Wed, 18 Feb 2009 14:04:17 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> Date: Wed, 18 Feb 2009 14:04:17 -0800 (PST) From: Charles Krinke To: suzyq@pobox.com, "Hurliman, John" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-214448360-1234994657=:48955" Message-ID: <676211.48955.qm@web82608.mail.mud.yahoo.com> Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:45:39 -0000 --0-214448360-1234994657=:48955 Content-Type: text/plain; charset=us-ascii Now, I need to ask a question, as I dont know how WoW, Croquet or Wonderland work. And perhaps this really indicates we need a representative from each of those. That is, if those are the other worlds to be considered. I dont really know what their future usage will be in a 3D internet as we go away from the "flat web". In any case, "Can we define a message format for avatar presence that contains fields to allow 3D interactive browsing that is reasonable for the SecondLife and OpenSim teams and also flexible enough to be useful for other teams?" Charles ________________________________ From: Suzy Deffeyes To: "Hurliman, John" Cc: "mmox@ietf.org" Sent: Wednesday, February 18, 2009 1:56:29 PM Subject: Re: [mmox] The Story So Far... On Wed, Feb 18, 2009 at 1:41 PM, Hurliman, John wrote: The HyperGrid implementation in OpenSim today establishes a full trust link between two separate service stacks (grids). It's a very clever way of combining grids, but doesn't address how untrusted administrative domains interact with each other at all. I don't understand why you keep comparing Agent Domain and HyperGrid. My understanding of the Agent Domain model is that it maps every trust relationship between grids to a policy decision. This is important for the business case of company X and company Y creating a partnership that is explicitly configured, but glazes over the 99.999% use case of moving from untrusted grid A to untrusted grid B. I haven't seen any work from AWG addressing the possibility of eliminating all grid<->grid communication (google.com doesn't communicate with the links I click, the browser is perfectly capable of managing its own state). For the google 2d browsing analogy, I don't need to see a representation of other people that also happen to be visiting that same link, and I also don't have a name and 3D representation of myself that I want to remain consistent on my screen as I go from link to link. In our MMOX space, it can be desirable to have a consistent representation of self that also appears the same to others in the same region. Not always, but for a fair number of use cases that involve teleportation it does. I'm not sure how that can happen if we eliminate all grid to grid communication. Maybe Agent Domain type implementations 'squirt' too much state along with an agent that is being transferred into a region. Maybe we need to tease that apart. I think the actual OGP implementation right now just squirts your name, UUID, a few bits, and desired location into the region. Suzy Deffeyes IBM --0-214448360-1234994657=:48955 Content-Type: text/html; charset=us-ascii
Now, I need to ask a question, as I dont know how WoW, Croquet or Wonderland work. And perhaps this really indicates we need a representative from each of those. That is, if those are the other worlds to be considered. I dont really know what their future usage will be in a 3D internet as we go away from the "flat web".

In any case, "Can we define a message format for avatar presence that contains fields to allow 3D interactive browsing that is reasonable for the SecondLife and OpenSim teams and also flexible enough to be useful for other teams?"

Charles

From: Suzy Deffeyes <suzyq@pobox.com>
To: "Hurliman, John" <john.hurliman@intel.com>
Cc: "mmox@ietf.org" <mmox@ietf.org>
Sent: Wednesday, February 18, 2009 1:56:29 PM
Subject: Re: [mmox] The Story So Far...



On Wed, Feb 18, 2009 at 1:41 PM, Hurliman, John <john.hurliman@intel.com> wrote:
The HyperGrid implementation in OpenSim today establishes a full trust link between two separate service stacks (grids). It's a very clever way of combining grids, but doesn't address how untrusted administrative domains interact with each other at all. I don't understand why you keep comparing Agent Domain and HyperGrid.

My understanding of the Agent Domain model is that it maps every trust relationship between grids to a policy decision. This is important for the business case of company X and company Y creating a partnership that is explicitly configured, but glazes over the 99.999% use case of moving from untrusted grid A to untrusted grid B. I haven't seen any work from AWG addressing the possibility of eliminating all grid<->grid communication (google.com doesn't communicate with the links I click, the browser is perfectly capable of managing its own state).

For the google 2d browsing analogy, I don't need to see a representation of other people that also happen to be visiting that same link, and I also don't have a name and 3D representation of myself that I want to remain consistent on my screen as I go from link to link.

In our MMOX space, it can be desirable to have a consistent representation of self that also appears the same to others in the same region. Not always, but for a fair number of use cases that involve teleportation it does. I'm not sure how that can happen if we eliminate all grid to grid communication.

Maybe Agent Domain type implementations 'squirt' too much state along with an agent that is being transferred into a region. Maybe we need to tease that apart.  I think the actual OGP implementation right now just squirts your name, UUID, a few bits, and desired location into the region.

Suzy Deffeyes
IBM

--0-214448360-1234994657=:48955-- From dcolivares@gmail.com Wed Feb 18 14:53:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A8B3A689A for ; Wed, 18 Feb 2009 14:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lq49-uy+pKcn for ; Wed, 18 Feb 2009 14:53:36 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 3B5C63A687A for ; Wed, 18 Feb 2009 14:53:35 -0800 (PST) Received: by bwz5 with SMTP id 5so371795bwz.13 for ; Wed, 18 Feb 2009 14:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=r/hxKrIfEP2WlSm/ulEpIEIHAfYrIOrJvfmOJKMS/3o=; b=GAQmQTuWcNYVQz7WK5qb/d6hL17qTj0K9IcdfH4kksshAbzKaW1xwRYZkvX1+Wlcz4 Vvo8AOeXRY4PmB8d2Eu+qwnfSm1N68N80k/M5zVXU+4M0/ajVZmAw7v9K0bsS8PnfgfX Rv6d1El25cdUtbgaENxvngEz8H0lterj86a6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=cbDSvxGNzYpKW4LCXjW/q+KwKjr5IiTmxMqwYe5KHEpBZ85PFkCTsiRqspcPijKYHG VYw5NRm63mksAC+AbFUWyH67euK5hvNM36Ekr3Opajdw7o/aQrzOxrhFSorMFFX/7uTy 13ltBIpouOsJ5Tt8FMPLmYBcKJt37Zfc5WXbU= MIME-Version: 1.0 Received: by 10.103.248.17 with SMTP id a17mr3011522mus.83.1234997625216; Wed, 18 Feb 2009 14:53:45 -0800 (PST) In-Reply-To: References: Date: Wed, 18 Feb 2009 17:53:45 -0500 Message-ID: From: Dan Olivares To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:53:38 -0000 Greetings My name is Daniel Olivares, I'm one of the core developers on OpenSimulator as well as the person who worked with David Levine, Mark L, Meadhbh H, and Bill H to get the OGP drafts implemented in OpenSimulator. I'm keenly interested in integrating existing standards with OpenSimulator and developing workable new standards in the virtual world market segment. I've also worked with other open source authors to implement and test new features with OpenSimulator as the back end software application. I have intimate knowledge and experience in many software development specialties as well as intimate knowledge of most parts of OpenSimulator. I'm also one of the founders of the 'IdealistViewer' project, the New BSD Licensed viewer project. (ss: http://teravus.wmcv.com/googletester/IdealistViewer53.jpg ) I look forward to spirited, solution oriented discussions and proposals. Best Regards Daniel Olivares (LLGrid: Teravus Ousley) From jwatte@gmail.com Wed Feb 18 16:24:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A359D3A69D3 for ; Wed, 18 Feb 2009 16:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCHNZHU6qE9q for ; Wed, 18 Feb 2009 16:24:49 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id C65523A69D1 for ; Wed, 18 Feb 2009 16:24:48 -0800 (PST) Received: by qyk4 with SMTP id 4so314192qyk.13 for ; Wed, 18 Feb 2009 16:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/ytJkqzd8CizQEc8CUke1o+BacJjcBO8vMDd55ym6IQ=; b=qOpUwx1e9ELP8mAOJcxoi/A9Wbj7tTlXpwzTafyflDx2nI+S5msdvf5q/9FBg+CD8Z NYIfxJvcrSeqDIMBwgRD7uRNUfCrLtCICNu/NxtH/Hk6Fu3hboqVgT85dA5JBJDOQq6h BcLnXP/BbdgFohSZhG4Fp5F+ox2kja9ZYUgrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jytXCbM5/xi5z83CxxNqkdjwzTKnCL8ExxC1PBP3Y6nSQfoGrAmdOLJTcdTRZsmu3u 088QN39vWo9ux98xFFKY1nUdGB6sEQLb2sGoaTWb4csTdOajvz9+eJ6JU5LLAqC3Mb4b m+9jdfghuF8Agrx0mY+S27Svgns+HH4/5mYPo= Received: by 10.224.28.207 with SMTP id n15mr1756962qac.91.1235003100791; Wed, 18 Feb 2009 16:25:00 -0800 (PST) Received: from ?192.168.168.101? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id 6sm681683ywp.31.2009.02.18.16.24.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 16:25:00 -0800 (PST) Message-ID: <499CA6DA.2010003@gmail.com> Date: Wed, 18 Feb 2009 16:24:58 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <659848.26941.qm@web82607.mail.mud.yahoo.com> In-Reply-To: <659848.26941.qm@web82607.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 00:24:49 -0000 I think the lowest common denominator may be aiming too low -- we need to deliver actual value to actual end users paying for that value, or the whole effort is moot. However, that being said, I'm prepared to throw a stake in the ground: You cannot migrate behavior. If behavior is authored for system X, then system Y will not be reasonably expected to perform that behavior at full fidelity. For example, behavior could be written in Java for Wonderland, or Python for Qwaq or Panda3D, or C++ and XPath for OLIVE. There simply is no way that every virtual world will be capable of emulating the execution environment of each other virtual world (here's a case where X3D broke down -- it specified an execution environment, that didn't actually suit anyone's needs). Thus, to make an object appear in a "remote" world, that object needs to be, at a minimum, simulated in the "home" world, and information about the outcome of that simulation (animations played, movements performed, sounds generated, interactions caused, etc) should be transmitted over the interoperability channel. Sincerely, jw Charles Krinke wrote: > So, it behooves us to find that lowest common denominator and see if > we can create a useful specification to avoid wasting any of our time. > I have to believe that there exists a subset of the SecondLife OGP and > HyperGrid notions that can at least form a basis to start building. If > not, perhaps someone can propose such a basis. From jwatte@gmail.com Wed Feb 18 16:34:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A19528C1E2 for ; Wed, 18 Feb 2009 16:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gj4FxdvAJ2ta for ; Wed, 18 Feb 2009 16:34:58 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 0D6B728C1E8 for ; Wed, 18 Feb 2009 16:34:33 -0800 (PST) Received: by qyk4 with SMTP id 4so320114qyk.13 for ; Wed, 18 Feb 2009 16:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=5b0IYIqpTBwCZw3r55DDGRuO1Qx6sPKOzC/eMvVON+M=; b=kSAi+Lv8smmMi/Fw44Oxa1x1I/1m1/0m/158rPSVlaIc3mBdTxSgomgoB8jQ1QG9Yh SLF7nvTkHrTasBbMQ/2/bS/cAWMS9XIB1dLGccVv5wSPTW/02uVl6grmH5eYTanrcO9B bYsO0NiOlXp8RYhWBfOMg7XXIhGmi8Xi9/BYA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=CtjMf0t8erzLFRj11d14YNFsiTolyuKHXdNusTqVy5adAnAN3ShAeljbsR8lV/9178 sPuSlaWd3d0fKEB17LtYeoiKRtaNC7ex4lzJ7VykUl1OAgWWrHnexzrNkCsiNGV41afZ zjL2goX9PJxNLCRvhTgqxTQWkj4rqF4VswanU= Received: by 10.224.28.79 with SMTP id l15mr7408928qac.74.1235003685489; Wed, 18 Feb 2009 16:34:45 -0800 (PST) Received: from ?192.168.168.101? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id 6sm135369ywp.11.2009.02.18.16.34.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 16:34:32 -0800 (PST) Message-ID: <499CA916.1090008@gmail.com> Date: Wed, 18 Feb 2009 16:34:30 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "mmox@ietf.org" References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> In-Reply-To: <676211.48955.qm@web82608.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 00:34:59 -0000 Charles Krinke wrote: > In any case, "Can we define a message format for avatar presence that > contains fields to allow 3D interactive browsing that is reasonable > for the SecondLife and OpenSim teams and also flexible enough to be > useful for other teams?" Re-phrase that as "that is reasonable for all likely adopters of the standard" -- why special case Second Life or Open Sim? So, what is an avatar anyway? I think it has one or more meshes (that are not standard), draped over a skeleton (that is not standard), with one or more textures applied (that are not standard). Avatars also represent users, which have identity. Avatars can move (physically, with collision detection), animate (interactions, emotes), voice communicate and text chat. If you can send that information ([identity, mesh, texture, skeleton] as set-up, and [movement, animation, interactions, voice and text chat] at runtime) then do you have an interoperable avatar? And, if so, what separates an avatar from another animated, movable object? Could the same way that avatars are interoperating be used to interoperate other simulated objects? From a remote systems' point of view, there's not that much difference between a human-driven avatar, and a tumbling rock -- the remote system can't be expected to run the simulation for either one, so it needs to have that stream of behavior to represent it. As far as I know Wonderland, Qwaq, Multiverse and other possible adopters, the above representations maps fairly straightforward to their systems, although any system will have to expect to write adaption code to accept "arbitrary" external meshes as avatars. Sincerely, jw From jwatte@gmail.com Wed Feb 18 16:37:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDDC73A6A13 for ; Wed, 18 Feb 2009 16:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-OaPO3qDMLw for ; Wed, 18 Feb 2009 16:37:06 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 0C7A73A693C for ; Wed, 18 Feb 2009 16:37:05 -0800 (PST) Received: by qyk4 with SMTP id 4so321720qyk.13 for ; Wed, 18 Feb 2009 16:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=vX0g+iYy6yst9ET4p7KfuyA4D8MPOQAFsluwrP+9AwM=; b=Azw+6spZdlWObvsxOHQrEDuNmRlO1+AbIuaAiuKgi8j9Jxa6lh8/ZyeF0r4eYYIfSD 2KNawnFRX3u4scNJjd2YA4mjHNsD4vl5gsyhXn3cE6fnbkA5q9D511RGhf2vcwlI+ck6 +1tg3w6pFqbR3eb2qSMlueJRzYmealbzw/aJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=wJY8+j9TOmfoU0ye1fZ73Sm0RFj2nYKOWPxBO57oVsWlNVTa1HN8OCr3i1sd0sJXcZ 6fQEsWWoVwIYxlG7+m7JU/NBmvGBXZugiHwQbmPH9adYuqhJFRRQ2GmIm14FsHLiukYL MS2Xua9RzheMNWjdO6aAeJ8IU+Topos64w9Sk= Received: by 10.224.53.203 with SMTP id n11mr12076670qag.192.1235003837686; Wed, 18 Feb 2009 16:37:17 -0800 (PST) Received: from ?192.168.168.101? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id 5sm1285760ywl.58.2009.02.18.16.37.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 16:37:17 -0800 (PST) Message-ID: <499CA9BB.8070506@gmail.com> Date: Wed, 18 Feb 2009 16:37:15 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "mmox@ietf.org" References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> In-Reply-To: <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 00:37:07 -0000 Suzy Deffeyes wrote: > Can you elaborate on " physical spaces shared across interoperating > servers " and what you mean by that? Let's assume organization A builds a space. Let's assume organization B builds furniture. Now, they want to have a meeting, and see how the furniture works in the space. The easiest way to accomplish this is to make organization A users log into the organization A virtual world (like they always do), and organization B users log into organization B virtual world (like they always do), and make arrangements such that some room/area/island within the two organizations is shared -- whatever comes to that space from A, also shows up in B, and vice versa. This allows A to publish its space, and B to bring the furniture to that space, without either having to disconnect from their regular virtual world (buddy list, unified messaging, inter-office collaboration, etc). Sincerely, jw From eh2th-mmox@yahoo.com Wed Feb 18 17:10:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8DEB3A69C1 for ; Wed, 18 Feb 2009 17:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiSYSPhH35Uq for ; Wed, 18 Feb 2009 17:10:13 -0800 (PST) Received: from web65703.mail.ac4.yahoo.com (web65703.mail.ac4.yahoo.com [76.13.9.95]) by core3.amsl.com (Postfix) with SMTP id 180373A67E9 for ; Wed, 18 Feb 2009 17:10:13 -0800 (PST) Received: (qmail 96115 invoked by uid 60001); 19 Feb 2009 01:10:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=y59ozH04lMJRUHv1AUa5qV/mqXc/JSMkyawj/V3JDqrNBl0Ty8WUUicnJQ1IoKMsUi70b3MjxY/2abmkJkE14xP3XqSn/7k8thejp5+ETrF/++hXNHOm3jl7t9e46YWFoDDkcKw1H5jwSgNsfTa18YPjmKQpGRguJEX4pbHG5xg=; X-YMail-OSG: X7wacq8VM1nMgLXu36v5yUhJeEy970np7GRGNeun4xNzkWkVFCXtJhFE_HUMR9bdjJe6nG6Sg7iPGmX_drBA8rZnotGqeN2CBkSBfzCOcOG2sFfQ0OlmyQUMY0KYbjmFkV9gIyqBbNR.exC04kfYrmyoaxTkMLiYuel1Xy_LBiGFzZAluTp_3pm8.Tk- Received: from [72.220.236.152] by web65703.mail.ac4.yahoo.com via HTTP; Wed, 18 Feb 2009 17:10:22 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: Date: Wed, 18 Feb 2009 17:10:22 -0800 (PST) From: eh2th-mmox@yahoo.com To: mmox@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <638845.94952.qm@web65703.mail.ac4.yahoo.com> Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 01:10:13 -0000 Hello all, I'm Tom Hoff, and I am also one of the core developers of OpenSimulator and the other primary founder of the Idealist Viewer project. I am also the primary developer of "PrimMesher", an open source BSD style licensed c# library for meshing secondlife style prims and sculpted prims. My primary interest in this list is related to the ability to transfer descriptions of geometry and interpret it in a way which allows it to be displayed it in a consistent manner among a variety of viewer platforms. I have a cursory interest in group chat and other parts of associated protocols. I am a seasoned software engineer with more than 2 decades of experience in software development and new product R&D. My experiences are varied but much time has been focused on color management and reproduction in printed media, image processing and digital halftoning algorithms. I have several avatars in Second Life, but the one with the most friends and the largest inventory is a ditzy blonde who goes by the name of "Dahlia". Best Regards, --Tom Hoff From gareth@litesim.com Wed Feb 18 18:06:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4A43A69C1 for ; Wed, 18 Feb 2009 18:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfYvMWAboJn0 for ; Wed, 18 Feb 2009 18:06:31 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 29DBA3A67F1 for ; Wed, 18 Feb 2009 18:06:31 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so57130rvb.5 for ; Wed, 18 Feb 2009 18:06:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.248.15 with SMTP id v15mr135337rvh.165.1235009203309; Wed, 18 Feb 2009 18:06:43 -0800 (PST) In-Reply-To: <499CA6DA.2010003@gmail.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <659848.26941.qm@web82607.mail.mud.yahoo.com> <499CA6DA.2010003@gmail.com> Date: Thu, 19 Feb 2009 02:06:43 +0000 Message-ID: <61dbdd7d0902181806g7e98f1cpf5620fd14a7af136@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 02:06:31 -0000 > Thus, to make an object appear in a "remote" world, that object needs to be, > at a minimum, simulated in the "home" world, and information about the > outcome of that simulation (animations played, movements performed, sounds > generated, interactions caused, etc) should be transmitted over the > interoperability channel. This is a nice way of looking at the problem. So far, everyone has assumed we send whole objects together with scripts, a very SL-centric approach. Of course, one big problem is this: 1 - VW A has Cool Object X 2 - User A on VW A sends Cool Object X to user B on VW B 3 - User B on VW B rez's it (and let's assume they're both utterly different types of world) 4 - VW B's servers talk to VW A and ask VW A to simulate the object What happens in step 4 if VW A's servers are down? From john.hurliman@intel.com Wed Feb 18 18:34:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2774028C1A2 for ; Wed, 18 Feb 2009 18:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUHNGnnUCdLQ for ; Wed, 18 Feb 2009 18:34:09 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 495A428C194 for ; Wed, 18 Feb 2009 18:34:09 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 18 Feb 2009 18:32:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,231,1233561600"; d="scan'208";a="432158811" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by fmsmga002.fm.intel.com with ESMTP; 18 Feb 2009 18:30:21 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Wed, 18 Feb 2009 19:34:22 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Wed, 18 Feb 2009 19:34:19 -0700 Thread-Topic: [mmox] The Story So Far... Thread-Index: AcmSE8dpU9L/wpzPSUSRXAIwk5F8xgAJhJrw Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> In-Reply-To: <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 02:34:10 -0000 >-----Original Message----- >From: suzyque@gmail.com [mailto:suzyque@gmail.com] On Behalf Of Suzy >Deffeyes >Sent: Wednesday, February 18, 2009 1:56 PM >To: Hurliman, John >Cc: mmox@ietf.org >Subject: Re: [mmox] The Story So Far... > > > >On Wed, Feb 18, 2009 at 1:41 PM, Hurliman, John > wrote: > > > The HyperGrid implementation in OpenSim today establishes a full >trust link between two separate service stacks (grids). It's a very >clever way of combining grids, but doesn't address how untrusted >administrative domains interact with each other at all. I don't >understand why you keep comparing Agent Domain and HyperGrid. > > My understanding of the Agent Domain model is that it maps every >trust relationship between grids to a policy decision. This is important >for the business case of company X and company Y creating a partnership >that is explicitly configured, but glazes over the 99.999% use case of >moving from untrusted grid A to untrusted grid B. I haven't seen any >work from AWG addressing the possibility of eliminating all grid<->grid >communication (google.com doesn't communicate with the links I click, >the browser is perfectly capable of managing its own state). > > >For the google 2d browsing analogy, I don't need to see a representation >of other people that also happen to be visiting that same link, and I >also don't have a name and 3D representation of myself that I want to >remain consistent on my screen as I go from link to link. > >In our MMOX space, it can be desirable to have a consistent >representation of self that also appears the same to others in the same >region. Not always, but for a fair number of use cases that involve >teleportation it does. I'm not sure how that can happen if we eliminate >all grid to grid communication. > "same region" and grid<->grid are separate concepts. The idea of sharing a = scene graph across administrative domains is interesting, but the current a= gent domain work does not include anything like that. Instead, a teleport i= s done from grid A to grid B where identity and appearance are the only thi= ngs that need to persist. I don't see why grid<->grid communication is fund= amentally necessary to transfer identity and appearance. >Maybe Agent Domain type implementations 'squirt' too much state along >with an agent that is being transferred into a region. Maybe we need to >tease that apart. I think the actual OGP implementation right now just >squirts your name, UUID, a few bits, and desired location into the >region. > >Suzy Deffeyes >IBM > > From dcolivares@gmail.com Wed Feb 18 18:43:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14D093A699C for ; Wed, 18 Feb 2009 18:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rngg09kdfccO for ; Wed, 18 Feb 2009 18:43:48 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id C8CFB3A67D6 for ; Wed, 18 Feb 2009 18:43:47 -0800 (PST) Received: by bwz5 with SMTP id 5so523233bwz.13 for ; Wed, 18 Feb 2009 18:43:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=1XKEfwlt+QLOwmx4W85WMtDz6ogcUNDKvluQAxcHtGU=; b=DX6ujuLL3oJmX1E85vGkYAKi8M0Gj6bdZ0mUWOTcwj3eMV7pOXhXqB6BWjlObAU9Hx rg2eJ8suELxMgSSiGGfZX1ILuAfhCPIRZbuY5ukEUA72G+hpBpJyvGeLpd5zziNGDYo5 Pqb1YLlFX3u0ETr/1jwpNysALEGitsyerkTxs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=GhaSL28RSwWz9UA5RvjVdrFsFUYUqyWTxo20F59OOR1JG4bbA987jzcltewhQJCaEA tCAGOSOhgsvidAVE1jObyamal49mR3QXrBqPUWYd/kI8VGOshdTmSzEIUDuLDPDJMA75 mw9KvmpNeWL6zKyCT0CmIkeg7uhFkjGkmRefQ= MIME-Version: 1.0 Received: by 10.103.224.17 with SMTP id b17mr63377mur.61.1235011439006; Wed, 18 Feb 2009 18:43:59 -0800 (PST) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> Date: Wed, 18 Feb 2009 21:43:58 -0500 Message-ID: From: Dan Olivares To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 02:43:52 -0000 Chiming in here. The use case you suggested is quite interesting Jon. I've thought about it myself from time to time. The major objection that I've heard so far is that it requires a lot more work (service calls?) to develop a shared scene graph and requires a significant more amount of trust then an A-->B teleport does. Ultimately, however, I hope that we can create a solution to this issue so that 3D spaces can be shared between various implementations. Best Regards Daniel Olivares On Wed, Feb 18, 2009 at 9:34 PM, Hurliman, John w= rote: >>-----Original Message----- >>From: suzyque@gmail.com [mailto:suzyque@gmail.com] On Behalf Of Suzy >>Deffeyes >>Sent: Wednesday, February 18, 2009 1:56 PM >>To: Hurliman, John >>Cc: mmox@ietf.org >>Subject: Re: [mmox] The Story So Far... >> >> >> >>On Wed, Feb 18, 2009 at 1:41 PM, Hurliman, John >> wrote: >> >> >> The HyperGrid implementation in OpenSim today establishes a full >>trust link between two separate service stacks (grids). It's a very >>clever way of combining grids, but doesn't address how untrusted >>administrative domains interact with each other at all. I don't >>understand why you keep comparing Agent Domain and HyperGrid. >> >> My understanding of the Agent Domain model is that it maps every >>trust relationship between grids to a policy decision. This is important >>for the business case of company X and company Y creating a partnership >>that is explicitly configured, but glazes over the 99.999% use case of >>moving from untrusted grid A to untrusted grid B. I haven't seen any >>work from AWG addressing the possibility of eliminating all grid<->grid >>communication (google.com doesn't communicate with the links I click, >>the browser is perfectly capable of managing its own state). >> >> >>For the google 2d browsing analogy, I don't need to see a representation >>of other people that also happen to be visiting that same link, and I >>also don't have a name and 3D representation of myself that I want to >>remain consistent on my screen as I go from link to link. >> >>In our MMOX space, it can be desirable to have a consistent >>representation of self that also appears the same to others in the same >>region. Not always, but for a fair number of use cases that involve >>teleportation it does. I'm not sure how that can happen if we eliminate >>all grid to grid communication. >> > > "same region" and grid<->grid are separate concepts. The idea of sharing = a scene graph across administrative domains is interesting, but the current= agent domain work does not include anything like that. Instead, a teleport= is done from grid A to grid B where identity and appearance are the only t= hings that need to persist. I don't see why grid<->grid communication is fu= ndamentally necessary to transfer identity and appearance. > >>Maybe Agent Domain type implementations 'squirt' too much state along >>with an agent that is being transferred into a region. Maybe we need to >>tease that apart. I think the actual OGP implementation right now just >>squirts your name, UUID, a few bits, and desired location into the >>region. >> >>Suzy Deffeyes >>IBM >> > >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From lenglish5@cox.net Wed Feb 18 18:53:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F13053A6874 for ; Wed, 18 Feb 2009 18:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.951 X-Spam-Level: X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nKFS01E1Ip60 for ; Wed, 18 Feb 2009 18:53:05 -0800 (PST) Received: from fed1rmmtao104.cox.net (fed1rmmtao104.cox.net [68.230.241.42]) by core3.amsl.com (Postfix) with ESMTP id 4FD873A67D6 for ; Wed, 18 Feb 2009 18:53:05 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090219025319.VLZT16134.fed1rmmtao104.cox.net@fed1rmimpo01.cox.net> for ; Wed, 18 Feb 2009 21:53:19 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id HetJ1b0014N6T0Q03etJH2; Wed, 18 Feb 2009 21:53:18 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=cfHPFXhNAAAA:8 a=6NGCdaPTStCEyjRi1bAA:9 a=QdCSqnqoGEzB53mLA2R3m7Ot1WYA:4 a=oqs56FR1YJwA:10 X-CM-Score: 0.00 Message-ID: <499CC99D.8040302@cox.net> Date: Wed, 18 Feb 2009 19:53:17 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] Historic meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 02:53:06 -0000 So, an historic meeting took place today: representatives from 3 different virtual worlds met in a virtual world to hash out the details of how to bring the MMOX meeting into their respective virtual worlds and allow meeting participation from within them. Qwaq, OpenSim and SecondLife were all represented. Here's the chat log. A more readable summary is forthcoming: http://wiki.secondlife.com/wiki/MMOX/Chat_Logs/2009-2-19 Lawson (SjK ISL) From tme@multicasttech.com Wed Feb 18 19:02:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A694C3A67D6 for ; Wed, 18 Feb 2009 19:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.55 X-Spam-Level: X-Spam-Status: No, score=-103.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6alC7pMvDzL for ; Wed, 18 Feb 2009 19:02:26 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id C55A53A6909 for ; Wed, 18 Feb 2009 19:02:25 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14702145; Wed, 18 Feb 2009 22:00:58 -0500 Message-Id: <5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com> From: Marshall Eubanks To: lenglish5@cox.net In-Reply-To: <499CC99D.8040302@cox.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 22:02:37 -0500 References: <499CC99D.8040302@cox.net> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Historic meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 03:02:26 -0000 Do you plan for this to be a ongoing thing ? Marshall On Feb 18, 2009, at 9:53 PM, Lawson English wrote: > So, an historic meeting took place today: representatives from 3 > different virtual worlds met in a virtual world to hash out the > details of how to bring the MMOX meeting into their respective > virtual worlds and allow meeting participation from within them. > > > Qwaq, OpenSim and SecondLife were all represented. > > Here's the chat log. A more readable summary is forthcoming: > > > http://wiki.secondlife.com/wiki/MMOX/Chat_Logs/2009-2-19 > > > > Lawson (SjK ISL) > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Wed Feb 18 19:04:28 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04AF03A6A14 for ; Wed, 18 Feb 2009 19:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGNg0T7qNKYt for ; Wed, 18 Feb 2009 19:04:27 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 1EE1F3A695B for ; Wed, 18 Feb 2009 19:04:27 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id A39EE3DBC064; Wed, 18 Feb 2009 19:04:39 -0800 (PST) Message-Id: <83E5DBE6-1492-444C-9D4C-7DE659D8D5FA@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: lenglish5@cox.net In-Reply-To: <499CC99D.8040302@cox.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 19:04:35 -0800 References: <499CC99D.8040302@cox.net> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Historic meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 03:04:28 -0000 oh hey. i wasn't thinking about that. yer right. i don't know that peeps have done that before. anyone have contacts over at dreamland or project chainsaw? we're not haters, reasonable accomodation will be provided to other VW operators who wish to stream the MMOX meeting into their systems. -cheers -meadhbh On Feb 18, 2009, at 6:53 PM, Lawson English wrote: > So, an historic meeting took place today: representatives from 3 > different virtual worlds met in a virtual world to hash out the > details of how to bring the MMOX meeting into their respective > virtual worlds and allow meeting participation from within them. > > > Qwaq, OpenSim and SecondLife were all represented. > > Here's the chat log. A more readable summary is forthcoming: > > > http://wiki.secondlife.com/wiki/MMOX/Chat_Logs/2009-2-19 > > > > Lawson (SjK ISL) > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From lenglish5@cox.net Wed Feb 18 19:07:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86B83A6909 for ; Wed, 18 Feb 2009 19:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.878 X-Spam-Level: X-Spam-Status: No, score=0.878 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NVuXBFk81Vo for ; Wed, 18 Feb 2009 19:07:38 -0800 (PST) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id E90333A695B for ; Wed, 18 Feb 2009 19:07:37 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090219030750.ZYGG2948.fed1rmmtao101.cox.net@fed1rmimpo01.cox.net>; Wed, 18 Feb 2009 22:07:50 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id Hf7q1b00D4N6T0Q03f7qEz; Wed, 18 Feb 2009 22:07:50 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=cfHPFXhNAAAA:8 a=48vgC7mUAAAA:8 a=01iEQb3ib-aT6URgJ8QA:9 a=zhYa_krb8HaZtdteKbkA:7 a=SL-mmCTQ6QZOLg-Mtu9vDXeO99gA:4 a=lZB815dzVvQA:10 a=5FtdkfQUxfIA:10 X-CM-Score: 0.00 Message-ID: <499CCD06.20709@cox.net> Date: Wed, 18 Feb 2009 20:07:50 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Marshall Eubanks References: <499CC99D.8040302@cox.net> <5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com> In-Reply-To: <5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Historic meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 03:07:38 -0000 Well, this was just a nuts and bolts meeting to hash out technical details for the media streaming. We're hoping that this meeting plus whatever multi-media solution we can devise for the MMOX meeting itself, will the the prototypes for some rather nifty and productive regular meetings. Lawson Marshall Eubanks wrote: > Do you plan for this to be a ongoing thing ? > > Marshall > > On Feb 18, 2009, at 9:53 PM, Lawson English wrote: > >> So, an historic meeting took place today: representatives from 3 >> different virtual worlds met in a virtual world to hash out the >> details of how to bring the MMOX meeting into their respective >> virtual worlds and allow meeting participation from within them. >> >> >> Qwaq, OpenSim and SecondLife were all represented. >> >> Here's the chat log. A more readable summary is forthcoming: >> >> >> http://wiki.secondlife.com/wiki/MMOX/Chat_Logs/2009-2-19 >> >> >> >> Lawson (SjK ISL) >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From infinity@lindenlab.com Wed Feb 18 20:45:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF2C3A685B for ; Wed, 18 Feb 2009 20:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDkeIhnxQ3tL for ; Wed, 18 Feb 2009 20:45:36 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 4D27B3A6824 for ; Wed, 18 Feb 2009 20:45:36 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 94F4F3DBC064 for ; Wed, 18 Feb 2009 20:45:48 -0800 (PST) Message-Id: <6A5E83A8-A7A1-4D38-8FAC-C04E360E4777@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: mmox@ietf.org In-Reply-To: <5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 20:45:45 -0800 References: <499CC99D.8040302@cox.net> <5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com> X-Mailer: Apple Mail (2.930.3) Subject: [mmox] meeting minutes from today's ietf mmox simulcasting meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 04:45:37 -0000 the meeting today was just to review requirements and get input from peeps with experience hosting large concurrent real-world / virtual- world events. Sai / Lawton already posted the chat logs at http://wiki.secondlife.com/wiki/MMOX/Chat_Logs/19-2-2009 . i'm on the hook for boiling it down to its essential points. so.. might as well present it here as well: * there are two major issues... streaming the video out of the physical meeting space and providing for input from geographically distributed participants * streaming out... * the IETF generally doesn't do video anymore, we're told it's cause they don't want to have a camera and camera operator per room * we have at least one video camera, a firewire cable, a macbook pro running quicktime broadcaster, and a commercial partner who can replicate those streams * do we need additional audio equipment (tie mic for presenters, microphone for attendees to ask questions / make comments?) * those who want to view the stream (either within the virtual world, or without) would use an RTSP url in their favorite streaming video client to access the stream * this should work with QuickTime Player, mplayer, miro / democracy, et al * second life parcel / estate owners and open sim instance operators may set the "parcel media stream" to this RTSP url * this will allow anyone who enters the parcel to get a reference to the RTSP url and establish a stream from our commercial stream partner to the user's client host * it's important to note that for second life and open sim instances, this will consume one RTSP stream per client, not one stream per virtual world * qwaq says they can consume a single stream and rebroadcast it within their virtual world. (which is pretty darn'd awesome) * there was considerable variability in the estimates of how many streams would be required * bjornlyn loon and bevan whitfield were present, giving advice for how to judge the requirements * the low estimate was 2 streams required * the high estimate was 300 streams (eliminating the outliers of 5k and 20k) * we want to get this number pinned down by COB this Friday (20 Feb 2009) * qwaq has a strong preference / requirement for using H.264 instead of H.263 * but that's not a terrible issue, the SL clients on Mac and Windows are known to support H.264. * we would love to hear from users / developers of other viewers if H.264 support is present. * with so many moving parts, it would be nice to have a test run or two (or three) * fortunately, whump linden will be using a similar configuration to broadcast Ursala K. LeGuin's reading from the upcoming Potlatch literary event * getting questions / comments back into the face to face meeting * there is a concern that all participants volunteering information (questions, comments, etc.) have been made aware of the IETF IPR Disclosure rules * you can find information about this at http://www.ietf.org/NOTEWELL.html * this issue is the primary "business requirement" * there were several proposals for how to ensure remote participants were presented with the NOTEWELL URL and told to read it before commenting * one solution was to require people to visit a "click through" web page requiring you to acknowledge you were told to read the contents of the NOTEWELL page * another solution (for virtual worlds) was to spam users with notecards and placards telling them to read the contents of the NOTEWELL page * this won't work for people who aren't in one of the virtual worlds, assuming people come in via XMPP * assuming we resolve the technical challenges of connecting to jabber.ietf.org with mac clients * yet another solution was for the person relaying questions from the virtual world to ask everyone, "have you read and understand the IETF IPR disclosure policy as outlined on the NOTEWELL page?" * we assume there will be one person physically present at the meeting who will relay questions from geographically distributed participants to the presenters * related, but not completely the same, is the idea of having chat- bridges for people viewing the the meeting in a virtual world to talk to each other, and the people in various XMPP / IRC chatrooms * it would be great if _this_ was the mechanism that relayed questions / comments from geographically distributed participants * if we used one that only worked on second life, would this be fair to the qwaq participants or the OSGrid participants? * other issues * bjornlyn loon has a solution for accessibility, w00t! * IETF meetings are considered public, so we are assuming the video, audio, audio transcription and chat log will be archived and freely available. * so don't say anything you don't want your (grand)kids hearing you say 15 years from now * moving forward * we need to figure out how many streams we're going to purchase by close of business on friday 20 february, 2009 * we need to get guidance from the IETF with respect to what constitutes "notice" for IETF IPR disclosure policy * it would be great to test this configuration * is the use of mmox@jabber.ietf.org required? several mac users have noted difficulty in using it. -cheers -meadhbh From morgaine.dinova@googlemail.com Wed Feb 18 21:45:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758D03A69E4 for ; Wed, 18 Feb 2009 21:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9VHl3LlP0Wl for ; Wed, 18 Feb 2009 21:45:35 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id C66EC3A696C for ; Wed, 18 Feb 2009 21:45:34 -0800 (PST) Received: by bwz5 with SMTP id 5so610020bwz.13 for ; Wed, 18 Feb 2009 21:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=epFVmGNyjTis+1BgjoXCsWGBUJ1FT0wkMNiOsYBxxLE=; b=qkGX8upRKZcLVLrosZ6og6vqDu7DAamfCeU7PeHhXcvnyrK8ZDxHYKbXQsnI8uf8Y5 pmz+DtR6azQFAJp/rN1nuhD4MMh0yTQrqUZG+gatAH9VA2CDSvoN5Xxb8SAXl3XK0N9v aI+owHxbNnvjP1srHp6lku1nf6oNFaRbcEfpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=iuzKtfn5L2CkBAbDrEsuUQ4hSsBZQCwXfBv+Q73lFWosuP9PqA6ouCSY7bX8dxUrrL OOxqL2meWIZ0NUI7I4pk6qlLd+FviwpJ8OYnN4p8xfcC7OQ8mErGJ5B0z2X3QLBtwFGb genXo0ldzf58CtM7CHwKDKdwY+q4PwVUziRrQ= MIME-Version: 1.0 Received: by 10.181.192.11 with SMTP id u11mr3083184bkp.50.1235022345662; Wed, 18 Feb 2009 21:45:45 -0800 (PST) In-Reply-To: <638845.94952.qm@web65703.mail.ac4.yahoo.com> References: <638845.94952.qm@web65703.mail.ac4.yahoo.com> Date: Thu, 19 Feb 2009 05:45:45 +0000 Message-ID: From: Morgaine Dinova To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016e6d9a15a33f31704633f0c84 Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 05:45:36 -0000 --0016e6d9a15a33f31704633f0c84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit By way of introduction, I'll just paste the Background section from my user page at https://wiki.secondlife.com/wiki/User:Morgaine_Dinova -- dive in there for more information or to discuss technical matters outside of MMOX: === Chronologically, ElecEng grad/honours, PhD in EE/CompSci (concurrency and parallelism), postdoctoral research (parallel language design), and finally university lecturer in EE/CompSci for several years. Then left academia to work in industry with many clients as a freelance contractor. Very diverse roles in computing: analyst, designer, programmer, systems architect, QA, technical author, and sysadmin, in subjects including kernel, comms, drivers, defence, cryptography, engineering support applications (eg. RF power density displays), GUIs, firewall design and management, network monitoring and alerts, automating server farm operation, and multi-year ISP involvement with scalability of services from 64k to 3m users. Unix-based by preference and experience, ever since Bell Labs sent me the source tapes and I took up residence on a PDP-11/34. I think that was somewhere around the Late Jurassic period. Language agnostic, too many to care, and several created in passing. The language is not the problem anyway, just a tool with limited scope, so mix'n'match them to meet requirements. In computing, I take a strong, component-oriented engineering line: if you are language-centric and are in denial about interoperation between components from multiple parties written in different languages, then you're not part of the solution but part of the problem. Currently taking an open-ended sabbatical (I've earned it) for AWG/MMOX/etc --- it seems like a worthwhile goal. My main focus in the VW landscape is designing for scalability, open architectures, and high extensibility. Non-computing interests include many hard sciences and engineering disciplines, especially nanotechnology and its related areas, as well as astronomy and astrophysics, and climatology. Ex-member of IEE and IEEE, ex-radio amateur, ex hang glider, ex guitar player wannabe, and now enthusiastically into MIDI. I'm a long-term transhumanist, which loosely summarizes as being interested only in tomorrow, and shedding prior constraints every midnight. Virtual worlds fit in perfectly. I'm UK-based, and hate the weather. SL resident since 25th August 2004. === Morgaine. --0016e6d9a15a33f31704633f0c84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable By way of introduction, I'll just paste the Background section from my = user page at    https://wiki.secondlife.com/wiki/User:Morgaine_Dinova = -- dive in there for more information or to discuss technical matters outsi= de of MMOX:

=3D=3D=3D

Chronologically, ElecEng grad/honours, PhD in EE/CompSc= i (concurrency and parallelism), postdoctoral research (parallel language design), and finally university lecturer in EE/CompSci for several years. Then left academia to work in industry with many clients as a freelance contractor. Very diverse roles in computing: analyst, designer, programmer, systems architect, QA, technical author, and sysadmin, in subjects including kernel, comms, drivers, defence, cryptography, engineering support applications (eg. RF power density displays), GUIs, firewall design and management, network monitoring and alerts, automating server farm operation, and multi-year ISP involvement with scalability of services from 64k to 3m users.

Unix-based by preference and experience, ever since Bell Labs sent me the source tapes and I took up residence on a PDP-11/34. I think that was somewhere around the Late Jurassic period.

Language agnostic, too many to care, and several created in passing. The language is not the problem anyway, just a tool with limited scope, so mix'n'match them to meet requirements. In computi= ng, I take a strong, component-oriented engineering line: if you are language-centric and are in denial about interoperation between components from multiple parties written in different languages, then you're not part of the solution but part of the problem.

Current= ly taking an open-ended sabbatical (I've earned it) for AWG/MMOX/etc --= - it seems like a worthwhile goal.

My main focus in the VW landscape is designing for scalability, open= architectures, and high extensibility.

Non-computing interests include many hard sciences and engineering disciplines, especially nanotechnology and its related areas, as well as astronomy and astrophysics, and climatology. Ex-member of IEE and IEEE, ex-radio amateur, ex hang glider, ex guitar player wannabe, and now enthusiastically into MIDI. I'm a long-term transhumanist, which loosely summarizes as being interested only in tomorrow, and shedding prior constraints every midnight. Virtual worlds fit in perfectly.

I'm UK-based, and hate the weather.

SL resident since 25th August 2004.

=3D=3D=3D

Morgaine.
--0016e6d9a15a33f31704633f0c84-- From jwatte@gmail.com Wed Feb 18 21:45:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F903A696C for ; Wed, 18 Feb 2009 21:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBnpSTEvxeuV for ; Wed, 18 Feb 2009 21:45:38 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id A747C3A6A36 for ; Wed, 18 Feb 2009 21:45:38 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so246012rvb.49 for ; Wed, 18 Feb 2009 21:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yIR+8/82fyieSNhiEPWyeu6sC+jKmkow1zJOzYbRVss=; b=FTwetzCNTHdGP3MfLtDdRl6ssWOYfHzW7PC+yiOiGjW0+RxwvhRpOEK8KKlEmIc/dh Gh5tVTYgGRltTYbXJcE0gsFx7gUzI/zuLtF1Et25Ci1k/E2opSpT6koHWSAm/Yf+qNxQ IyyMf7vrSJ4y7wXP5rK1/pZQ96XuEYwKmubUc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MbpuL2wLcbuUByJ27c6VB4fjTcur/phETcDldWh2/IkWr6iDi5KTQe3WgcV2SJ/CyQ QwQUKokHLaAZYlnHAGvgcVhfMHzJl0bZq8Gk1ryaGMO858PhLs1RDUu0m68b152/uC6f a7TZfCGmduc+lbcyKjZ3f43rIZleX8n0FrNOk= Received: by 10.141.211.5 with SMTP id n5mr3476870rvq.106.1235022351710; Wed, 18 Feb 2009 21:45:51 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k2sm1720244rvb.4.2009.02.18.21.45.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 21:45:51 -0800 (PST) Message-ID: <499CF20E.4010104@gmail.com> Date: Wed, 18 Feb 2009 21:45:50 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <659848.26941.qm@web82607.mail.mud.yahoo.com> <499CA6DA.2010003@gmail.com> <61dbdd7d0902181806g7e98f1cpf5620fd14a7af136@mail.gmail.com> In-Reply-To: <61dbdd7d0902181806g7e98f1cpf5620fd14a7af136@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 05:45:39 -0000 Gareth Nelson wrote: > This is a nice way of looking at the problem. So far, everyone has > assumed we send whole objects together with scripts, a very SL-centric > approach. Of course, one big problem is this: > 1 - VW A has Cool Object X > 2 - User A on VW A sends Cool Object X to user B on VW B > 3 - User B on VW B rez's it (and let's assume they're both utterly > different types of world) > 4 - VW B's servers talk to VW A and ask VW A to simulate the object > > What happens in step 4 if VW A's servers are down? > How can the user even be available to interoperate if VW A server is down? Think of it like cell phones. If I call you, and you don't have your cell phone on (not "logged in" to "your system"), or your cell phone operator has an outage ("server down"), then how can I call you? I can't. Sincerely, jw From jwatte@gmail.com Wed Feb 18 21:53:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008253A68EC for ; Wed, 18 Feb 2009 21:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_44=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id di5fn9EhYE-H for ; Wed, 18 Feb 2009 21:53:48 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id E0EE13A682D for ; Wed, 18 Feb 2009 21:53:47 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so248495rvb.49 for ; Wed, 18 Feb 2009 21:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pFxA6WE9bDc9OaBXt6hV6e+YydDISakd+lf6kmuPmF4=; b=h0SgAA7GaWUlj1LQpihEAf0cgOXa73PMl2koPl52tmvakN3q2evQs/5Ud0rMvUchil tiyIjKIqjD3t85HePRhtIDm4mykBRFiydbJ3miPJaboCTJvN95EZ9f4dHnwSOhEpWYVC +tTwzD2NYRJPDESsnV2BGUxNvgdHf5Mq5ZmB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pZ4E8l3K4brEpJvAYtOTzsSx8Y5vXVkVXIOSqy1Z48c4FYL1bKSqI8t5//Nuw6/KGw 2INYhPKnuqdk/tY9SV5gygCYXnKbZvZo1T2wIYh8TT1FMptY2t/0+kag+JXI628kuSfG l0Cyzf8Lnbkt4C0N4NqOcMsZXFS+te11RC/jo= Received: by 10.141.4.20 with SMTP id g20mr3625874rvi.173.1235022841060; Wed, 18 Feb 2009 21:54:01 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id f42sm901493rvb.3.2009.02.18.21.54.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 21:54:00 -0800 (PST) Message-ID: <499CF3F7.1010304@gmail.com> Date: Wed, 18 Feb 2009 21:53:59 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Hurliman, John" References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 05:53:49 -0000 Hurliman, John wrote: > include anything like that. Instead, a teleport is done from grid A to grid B where identity and appearance are the only things that need to persist. I don't see why grid<->grid communication is fundamentally necessary to transfer identity and appearance. > At least three reasons: 1) When I am logged into a virtual world, it's usually for a reason. For me, it's work -- my virtual world allows me to cooperate with remote workers, visualize 3D data, and have meetings that are more effective and cheaper than conference calls. (Customers love "cheaper" :-) If I were to log off my "home" virtual world, then I would lose some or all of those capabilities while I "went elsewhere." For example, if my company has a policy of recording all interactions in the world, for regulatory compliance, if I suddenly disconnected and connected to another grid, that function would not be present. 2) Object behavior is not portable. One system may use SecondLife Script version 2.3 for its objects. Another may use Java Runtime 1.5.6. A third may use Visual C++ 9.0 linkable libraries. 3) If you "grid hop" to another location, you have to have a client that can connect to whatever server protocol that location is using. Writing a "universal client" has proven to be quite quixotic for two reasons: a) Any real system will have to have a "home protocol" anyway to provide functionality not provided for in the standard, and b) re-implementing virtual world presence for a client as a separate channel only to use for interoperability isn't a good idea. If I "grid hop," I might as well just have two clients installed (one that uses ClosedGardenWorld protocol 1.3, and one which uses WalledSpacesWorld protocol 2.7), and launch the right client for where I want to go -- the "benefit" of interoperability would be quite marginal; basically just not having to fill out a registration form for each world. No business will do a lot of engineering work to enable a scenario like that, because it delivers very little added value. Sincerely, jw From jwatte@gmail.com Wed Feb 18 21:55:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEDF3A6987 for ; Wed, 18 Feb 2009 21:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN4COxi1S21g for ; Wed, 18 Feb 2009 21:55:05 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.152]) by core3.amsl.com (Postfix) with ESMTP id 87B583A6951 for ; Wed, 18 Feb 2009 21:55:05 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so706260poe.4 for ; Wed, 18 Feb 2009 21:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=gCqshA03WZCw+nIc3vwE7DOWb0rrB5AWvq+mzT/t08Q=; b=LFnnKm7TfRc4iSQ8G1X8mbkTZtZy6wzL3BhxYlzy2PyeKDF4y5sn8IW24r0sXNXYnL deDlB0+Ol7FzcUycsX4wHk8c37ILbc8NQKtkpBiAEqymF4mtyE0gh5VluzXFu09GooWZ 1d1+ZB1UYpTfMqWS628YS1WXXJWtKYRm2Wrio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=i4v1QG1la4WhQ4CLAzTWnkAmZMNOBhMVNXi8At1Zt0r3pqFsAHcuQQcYwpHKQjuDZo QRJTqD1v2rN9XM/ZRqEgMODEwIfBAyUOhIwenGZA3T4fe2UwBBja7ojxScmez0x0WxSh grsFh7xvOSmJxSp92pfxjbeoREzdGVNt/oNJQ= Received: by 10.141.99.2 with SMTP id b2mr744595rvm.182.1235022918448; Wed, 18 Feb 2009 21:55:18 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id g14sm522444rvb.0.2009.02.18.21.55.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 21:55:17 -0800 (PST) Message-ID: <499CF445.1000705@gmail.com> Date: Wed, 18 Feb 2009 21:55:17 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dan Olivares References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 05:55:06 -0000 Dan Olivares wrote: > objection that I've heard so far is that it requires a lot more work > (service calls?) to develop a shared scene graph and requires a > significant more amount of trust then an A-->B teleport does. > There is no shared scene graph. Each server simulates "its" objects, and translates from the "interop" protocol to its internal system at the gateway. Think of it like a more modern version of IEEE 1278 (which has been a great success as far as interoperable distributed simulation goes). Sincerely, jw From dcolivares@gmail.com Wed Feb 18 22:09:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F103628C0EA for ; Wed, 18 Feb 2009 22:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULLoayTNbeYj for ; Wed, 18 Feb 2009 22:09:02 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 2F2B63A69FB for ; Wed, 18 Feb 2009 22:09:02 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so314671wfd.31 for ; Wed, 18 Feb 2009 22:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=w/lhOubYQ19fBCLf/9YM87hhr8qFD5HLGOCad8xOykQ=; b=Xlz56S+71Xbqnx/fJCeLtg4W8QYCRqE6Jhjcj/tQdngqw0VpMrVNn3p11y+tXxM93k 8I6plTvWL2IMkjNGq4qa/8lcESyxxhO6AY9i1S9Z7r+EF5F3kzDnlyv64MpI5mJ66m0u +Vq6SC/qruMwupGcCM6O9v8D3ouyWD3/gCHGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=OT+VBGhiF+qnHUmCovO/NkQLxaLVAm/rdSWP2NKI7d4Y5AuGHZiUjtV7BkMc7lG9+1 cTPkbpfHOIGBXuFAMepCnLQjjy+LlYnYvZaKz4QRQoPn/lIGCrQMGfpfSODAjsSzjVdT BYYW0gda10UbJtIq4v3TfLCbDzFmzxDQSVZck= MIME-Version: 1.0 Received: by 10.142.254.6 with SMTP id b6mr2990952wfi.157.1235023755378; Wed, 18 Feb 2009 22:09:15 -0800 (PST) In-Reply-To: References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> <499CF445.1000705@gmail.com> Date: Thu, 19 Feb 2009 01:09:15 -0500 Message-ID: From: Dan Olivares To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 06:09:03 -0000 >From the technical perspective, agreed. From a user perspective, it's all part of the same visible world. It doesn't matter that the user is actually connected to 5 different servers each with it's own scene that it's simulating in it's delegated space in the contiguous world. Best Regards Daniel Olivares On Thu, Feb 19, 2009 at 12:55 AM, Jon Watte wrote: > There is no shared scene graph. Each server simulates "its" objects, and > translates from the "interop" protocol to its internal system at the > gateway. Think of it like a more modern version of IEEE 1278 (which has been > a great success as far as interoperable distributed simulation goes). > > Sincerely, > > jw > > From dyerbrookme@juno.com Wed Feb 18 22:19:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727A53A68C3 for ; Wed, 18 Feb 2009 22:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTOrDSzamNci for ; Wed, 18 Feb 2009 22:19:01 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id A67D53A696C for ; Wed, 18 Feb 2009 22:19:01 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail19.vgs.untd.com [10.181.12.159]) by smtpout02.vgs.untd.com with SMTP id AABE338QBAX9W3DS for (sender ); Wed, 18 Feb 2009 22:18:41 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNySGw8paJ9A37RmL4u28D8g== Received: (from dyerbrookme@juno.com) by webmail19.vgs.untd.com (jqueuemail) id N9Q9ZG75; Wed, 18 Feb 2009 22:18:05 PST Received: from [68.161.222.166] by webmail19.vgs.untd.com with HTTP: Thu, 19 Feb 2009 06:17:15 GMT X-Originating-IP: [68.161.222.166] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Thu, 19 Feb 2009 06:17:15 GMT To: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090219.011715.22395.1@webmail19.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:1:2829313987 X-UNTD-Peer-Info: 10.181.12.159|webmail19.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 48 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 06:19:02 -0000 X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C1B3A6A18 for ; Wed, 18 Feb 2009 22:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkyvkBgCMVhp for ; Wed, 18 Feb 2009 22:49:14 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 10A713A6984 for ; Wed, 18 Feb 2009 22:49:14 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail04.vgs.untd.com [10.181.12.144]) by smtpout05.vgs.untd.com with SMTP id AABE34AGZA59J5XS for (sender ); Wed, 18 Feb 2009 22:48:55 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNQRGcstB/kx2B4BP6d7WeEA== Received: (from dyerbrookme@juno.com) by webmail04.vgs.untd.com (jqueuemail) id N9RBQH3F; Wed, 18 Feb 2009 22:48:08 PST Received: from [10.181.11.34] by webmail04.vgs.untd.com with HTTP: Thu, 19 Feb 2009 06:47:58 GMT X-Originating-IP: [10.181.11.34] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Thu, 19 Feb 2009 06:47:58 GMT To: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090219.014758.23973.0@webmail04.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 3:5:2244444052 X-MAIL-INFO: 5d83ba77ba3fcfcf87ef0777ef2aaa277b7bbfd7131f0a7b4e4e6f4e8f2b2bda2b3be3fa0ecf877e772e733787beba938b17a31e9a0b5f575fae0f0f8e6eeb576efe0a13dede73abb36a3ade93936393c3b7b702b71ec70e5b0f8e7a5717fb278ee75f3b87cf077e8f7733f7339fbebe7e2aaaf72adf3ab32b2bfb671ababf2b3b3b4e3b2ea7a78aa7ef375be3be7ed3f7cfea137e97331eae270fee X-UNTD-Peer-Info: 10.181.12.144|webmail04.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 06:49:15 -0000 >If, for some reason, the sharing of content through interoperability is= against someone's wishes as a creator, then I would assume that some pl= atforms would implement platform-specific means to prevent content from = being shared over the interoperability channel, and users who cared abou= t interoperability would choose not to purchase that content. Creators w= ould then choose their platform, and their specific use of that platform= , according to how they feel would best serve their interests. I don't t= hink that needs to be mandated in an = interoperability specification. Jon, let's start with the fact that "interoperability" is not a goal bei= ng driven by the actual masses of users of SL and other virtual worlds, = broadly speaking, who are not even informed of the IP and social/politic= al issues involved. Nor, narrowly speaking, is it a goal of the content-= creators of Second Life. They haven't gotten to decide whether they want= "interoperability" (which has its extreme points of view already articu= lated here on this last) or not. They haven't gotten to have an opt-out = or an opt-in. It is a matter being decided by a handful of people at Lin= den Lab, IBM, OpenSim, and various members of the "Architectural Working= Group" who have shown up to take over the topic. There is no broad user= demand for interoperability; it is a concoction. So in that forced-march context, you have to look at what you are saying= here. What platform-specific means to prevent content from being shared= would be implemented in OpenSim, which has no intention of implementing= the copy/mod/transfer regime of Second Life? It seems a contradiction i= n terms to expect that a platform eagerly seeking interoperability with = another platform is then going to introduce "platform-specific means to = prevent content from being shared. At one point, some AWG members introduced a JIRA (feature proposal wiki)= motion to have a check-off box on SL-made objects offering consent or n= on-consent for an object to travel to other grids. There was a heated di= scussion about this and the author withdrew the proposal, regrettably: http://jira.secondlife.com/browse/MISC-1272 There then followed a recasting of the matter as a call for policy clari= fication that in fact we've never gotten: http://jira.secondlife.com/browse/MISC-1277 therefore prompting my JIRA asking that interoperability not be taken to= the IETF where it will not face a democratic vote of stakeholders: http://jira.secondlife.com/browse/MISC-2313 You're also suggesting that users who "care about interoperability" shou= ld "choose not to purchase that content" -- i.e. you're essentially dema= nding that creators share their content into grids that do not protect t= heir IP, or face boycotts if they don't go along with this forced march.= What's that all about? By *not* mandating the terms of copy/mod/transfer (or not) into the obje= ct transferring across grids, you have in fact copylefted the object by = default. *Not* mandating is in fact mandating. You've also set up a soci= al dynamic whereby you've created a false paradigm: if a creator refuses= to go along with the interoperability mandate and refuses to free his c= ontent for endless copying, he is seen as "not progressive" or "not coop= erative" or "not evolving into the future" (Creative Commons follows muc= h the same logic, making it possible to opt for a license to offer your = creations to be copied for credit, but not opt for a license to copy for= cash, and urging everyone to give away content for free, and not making= a mechanism to get paid for content, i.e. integrating micropayments wit= h content distribution as SL does). I fail to see why you can't add the checkoff boxes copy/mod/transfer whe= n implementing interoperability. Why do you oppose it? We all get that h= ackers can get around such regimes. So what? It's a serviceable deterren= t and an eminently simple and effective marker of intent. A trusted grid= *is* a grid that can uphold copy/mod/transfer both as a marker and as a= coded implementation that at least deters theft. No one expects a 100 p= ercent implementation. I'd also like the Lindens on this list to speak up about why they would = not uphold copy/mod/transfer as an inherent, coded, non-negotiable imple= mented feature of interoperability with other worlds. If they fail to do= that, then they need to explain why they continue to uphold it in their= own world. If it is good enough for Second Life, why is it not good eno= ugh for the Metaverse? If it is no good for the Metaverse, why is it bei= ng upheld in Second Life? Prokofy Neva ____________________________________________________________ Receive quick, concrete numbers on your VA mortgage benefits. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIqrtYcr4kM3HgKIvVna5g= T7JKRNrVjPD6pKVML0pUCN3LvLlSvkb/ From lenglish5@cox.net Wed Feb 18 23:23:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089263A6975 for ; Wed, 18 Feb 2009 23:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.323 X-Spam-Level: X-Spam-Status: No, score=-0.323 tagged_above=-999 required=5 tests=[AWL=1.146, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWaPHvxCpqAi for ; Wed, 18 Feb 2009 23:23:49 -0800 (PST) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id 5E82F3A6783 for ; Wed, 18 Feb 2009 23:23:49 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090219072402.PBQI2948.fed1rmmtao101.cox.net@fed1rmimpo03.cox.net>; Thu, 19 Feb 2009 02:24:02 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id HjQ21b0064N6T0Q04jQ2ub; Thu, 19 Feb 2009 02:24:02 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=48vgC7mUAAAA:8 a=s4YSZaoa6flBVnABWRQA:9 a=Rcv4X2vGewHmaQATi8UJTebM4-0A:4 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=MInBT2ynV54A:10 X-CM-Score: 0.00 Message-ID: <499D0912.8090404@cox.net> Date: Thu, 19 Feb 2009 00:24:02 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Dan Olivares References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> <499CF445.1000705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 07:23:50 -0000 With OpenSim/Second Life, it could, in theory, be quite a few more neighboring sims if your draw distance is set high enough since a sim only covers 256 meters while draw distrance can be set as high as 512: n = neighbor p = "parent" nnnnn nnnnn nnpnn nnnnn nnnnn And this assumes a single sim-size for all sims, and only a Cartesian 2D coordinate system (hence "grid") with no fun stuff like space station simulators or ring worlds or Dyson spheres (or MC Escher-esque worlds for that matter). Dan Olivares wrote: > >From the technical perspective, agreed. From a user perspective, > it's all part of the same visible world. It doesn't matter that the > user is actually connected to 5 different servers each with it's own > scene that it's simulating in it's delegated space in the contiguous > world. > > Best Regards > > Daniel Olivares > > On Thu, Feb 19, 2009 at 12:55 AM, Jon Watte wrote: > >> There is no shared scene graph. Each server simulates "its" objects, and >> translates from the "interop" protocol to its internal system at the >> gateway. Think of it like a more modern version of IEEE 1278 (which has been >> a great success as far as interoperable distributed simulation goes). >> >> Sincerely, >> >> jw >> >> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From morgaine.dinova@googlemail.com Wed Feb 18 23:39:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F180A28C1B0 for ; Wed, 18 Feb 2009 23:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.814 X-Spam-Level: X-Spam-Status: No, score=-1.814 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hexaQEwmWt94 for ; Wed, 18 Feb 2009 23:39:05 -0800 (PST) Received: from mail-bw0-f167.google.com (mail-bw0-f167.google.com [209.85.218.167]) by core3.amsl.com (Postfix) with ESMTP id 98BE928C18F for ; Wed, 18 Feb 2009 23:39:04 -0800 (PST) Received: by bwz11 with SMTP id 11so341295bwz.13 for ; Wed, 18 Feb 2009 23:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YoejAeJ8ClT9x7dc3eyw7gGtGV0tNTzHToNfHopo2SA=; b=bIhs9bNyFTgn+LkbpmDskNvGwu0Tw+Hwv2AO1zfuz23Nq1laY+FJ9aPS7fac/A8tFl KJP27f413JKBYh5Q1n4dQmqTP1/ZqQvzwLlX1QZ886h2/rIfgcuu/9Pol9SIHSyfBOcF 5hJjoMwzGxwq21IWRilZFs+8cBdMBUdoSRXTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I5DTvMtkZPFEkCkSfQZKq+O/I6zZryrnFjNNpc78eqt0z1c6TJbHs2IXVTjrI9noRM 1l77THmnLakiZ6xMd42xRh+rdjpZBcFy/AAchvlhePYONygKC57HpB32PmIIjZqT7hjT ZNEWDiRITQvIqqM5zJu+yQO3ut7p0lSKgozoU= MIME-Version: 1.0 Received: by 10.181.208.8 with SMTP id k8mr3109401bkq.128.1235029156426; Wed, 18 Feb 2009 23:39:16 -0800 (PST) In-Reply-To: <499C7FAD.4080009@gmail.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> Date: Thu, 19 Feb 2009 07:39:16 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=001636c5a48427f65d046340a222 Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 07:39:06 -0000 --001636c5a48427f65d046340a222 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 18, 2009 at 9:37 PM, Jon Watte wrote: > What end-user value does "teleport between grids" solve? > > In my opinion, that feature is very un-interesting, as it requires lots of > engineering, and gives very little value, compared to lower-hanging fruit > like physical spaces shared across interoperating servers. > > After perception of the world around you, travel is the next most important form of interaction with the world. Teleport is simply instantaneous travel, and teleport between grids is simply instantaneous travel between worlds in different organizational domains. How can it possibly be uninteresting and give little value to travel to distant places in virtual space? ;-) I expect that you meant something *completely* different to the above. :-) Are we hitting an ambiguity in terminology of some kind here? Morgaine. --001636c5a48427f65d046340a222 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 18, 2009 at 9:37 PM, Jon Wat= te <jwatte@gmail.c= om> wrote:
What end-user value does "teleport between grids" solve?

In my opinion, that feature is very un-interesting, as it requires lots of = engineering, and gives very little value, compared to lower-hanging fruit l= ike physical spaces shared across interoperating servers.

After perception of the world around you, travel is = the next most important form of interaction with the world.  Teleport = is simply instantaneous travel, and teleport between grids is simply instan= taneous travel between worlds in different organizational domains.  Ho= w can it possibly be uninteresting and give little value to travel to dista= nt places in virtual space?  ;-)

I expect that you meant something completely different to the ab= ove.  :-)   Are we hitting an ambiguity in terminology of some ki= nd here?

Morgaine.
--001636c5a48427f65d046340a222-- From gareth@litesim.com Thu Feb 19 00:17:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A90ED28C1CC for ; Thu, 19 Feb 2009 00:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACEgVNVUAMSo for ; Thu, 19 Feb 2009 00:17:15 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.155]) by core3.amsl.com (Postfix) with ESMTP id 0479828C18F for ; Thu, 19 Feb 2009 00:17:14 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so835408poe.4 for ; Thu, 19 Feb 2009 00:17:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.63.20 with SMTP id q20mr4472688rvk.58.1235031446495; Thu, 19 Feb 2009 00:17:26 -0800 (PST) In-Reply-To: <499CF20E.4010104@gmail.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <659848.26941.qm@web82607.mail.mud.yahoo.com> <499CA6DA.2010003@gmail.com> <61dbdd7d0902181806g7e98f1cpf5620fd14a7af136@mail.gmail.com> <499CF20E.4010104@gmail.com> Date: Thu, 19 Feb 2009 08:17:26 +0000 Message-ID: <61dbdd7d0902190017w739e817ey91da290ba9aa74c3@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 08:17:15 -0000 I think a better analogy is, if I have a phone and send a picture to you using the builtin camera, then I turn my phone off. Suddenly your phone can't access the picture (of course in reality we send the whole picture to you). On Thu, Feb 19, 2009 at 5:45 AM, Jon Watte wrote: > Gareth Nelson wrote: >> >> This is a nice way of looking at the problem. So far, everyone has >> assumed we send whole objects together with scripts, a very SL-centric >> approach. Of course, one big problem is this: >> 1 - VW A has Cool Object X >> 2 - User A on VW A sends Cool Object X to user B on VW B >> 3 - User B on VW B rez's it (and let's assume they're both utterly >> different types of world) >> 4 - VW B's servers talk to VW A and ask VW A to simulate the object >> >> What happens in step 4 if VW A's servers are down? >> > > > How can the user even be available to interoperate if VW A server is down? > > Think of it like cell phones. If I call you, and you don't have your cell > phone on (not "logged in" to "your system"), or your cell phone operator has > an outage ("server down"), then how can I call you? I can't. > > Sincerely, > > jw > > From jesrad@gmail.com Thu Feb 19 01:28:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6945428C17D for ; Thu, 19 Feb 2009 01:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54fAPLRP9XDb for ; Thu, 19 Feb 2009 01:28:26 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 2777028C0DE for ; Thu, 19 Feb 2009 01:28:25 -0800 (PST) Received: by bwz5 with SMTP id 5so789752bwz.13 for ; Thu, 19 Feb 2009 01:28:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7ZfcPyqC0jZnsQ8XcxcTeLHL0DDh/0I0wRJ2zc33Zp0=; b=ltXaQLfG6oWyI5Z53Io5Cw2ol5RowP1jhmY/m1PF0ZoUvk8TL6KC5UXdi8kZ2IHPAP FkCCWzvjJxBViYLccR0tqADdZgxSMhIaqCWGlk/jjEbqN4hP5RDZm1u5CMv2WC68PD0b wteFsgkx9ArySPZf19dhUKIbOcQMyce+s3lgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=tQKvnB8KrUIGjE+j1LImK1cvHf4QllpxMvN28ylrBzpd8P7xEZFs825AKLEdGofwcc T7NFBlkSItWrIV3zqCjHTSYqaFvaJvMR6ez5axNt8QvW2DyczqSG6gE0J2f2vIk/H5IA Ne2k9IiQVkvFpBKuJ+1DA+oVKPUB0lAlomYuE= MIME-Version: 1.0 Received: by 10.181.139.10 with SMTP id r10mr761375bkn.64.1235035716704; Thu, 19 Feb 2009 01:28:36 -0800 (PST) In-Reply-To: <499CF445.1000705@gmail.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> <499CF445.1000705@gmail.com> Date: Thu, 19 Feb 2009 10:28:36 +0100 Message-ID: <53cd6c2e0902190128t2c1df992safb425d3e43550a5@mail.gmail.com> From: Jesrad To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 09:28:27 -0000 The approach used in IEEE 1278 seems to differ radically from the function OGP is assumed to permit, from a glance: as you said it lets otherwise incompatible domains of simulation (call them grids) exchange just the amount and type of information needed to remain consistent between themselves. Transposed to a VW, this would mean you can use the SL client to connect to an SL grid, then your current simulator connects you through to other environments (WoW, Solipsis, etc.) and does the "translation". If the "foreign" domain/grid does not support some Agent Domain services or something else, then the "local" domain can then provide its own as a substitute, while the client is tasked with interpreting any native data that rides through (like 3D representation and sound format). Is it right ? Maybe detailing a specific example would help pointing out what should be and shouldn't be in such a protocol. (We're trying to minimize the amount or complexity of translation required both at the gateway and the client, aren't we ?) On Thu, Feb 19, 2009 at 6:55 AM, Jon Watte wrote: > Dan Olivares wrote: >> >> objection that I've heard so far is that it requires a lot more work >> (service calls?) to develop a shared scene graph and requires a >> significant more amount of trust then an A-->B teleport does. >> > > There is no shared scene graph. Each server simulates "its" objects, and > translates from the "interop" protocol to its internal system at the > gateway. Think of it like a more modern version of IEEE 1278 (which has been > a great success as far as interoperable distributed simulation goes). > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From jesrad@gmail.com Thu Feb 19 02:57:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49BCC28C210 for ; Thu, 19 Feb 2009 02:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W999S32NHwY0 for ; Thu, 19 Feb 2009 02:57:37 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id A4EDC28C20C for ; Thu, 19 Feb 2009 02:57:36 -0800 (PST) Received: by bwz5 with SMTP id 5so912259bwz.13 for ; Thu, 19 Feb 2009 02:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=xSfoGxXOT2iQP0vUGMnuL+5ObkhJBTC0G1BHi5AAj58=; b=pVuhhaLgn/wHS9N9UmvWYfi9Ca+xCTg/4Zva6XButnXfPygov4heh8UcFaYGvQQcNb B/BaBSmEw03NvKV3TGiwMKy0XW98zq/qhumUUr3ZwhFD8oGrzzznkd21e+FmGIRkoeFB toZBwd88nb5ImCKf5eiVxBb5o1dJWbITGogPM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=RjqMcntjot0K3e1WhS8iZUPtELpdiZmJJLmNFhf5c4tLA+aPBe71R+nNq7MB7bDa8l NswlvYamAsou2yWUW+czGuMEcAv5Ku0iMMCIZQcWbPOjMocSXT0PhcwmsPQUu3bZP59s DxGwxdQou+O2FxS9lj6xv/J1C5hNp2Q856zJw= MIME-Version: 1.0 Received: by 10.181.201.18 with SMTP id d18mr160689bkq.125.1235041067969; Thu, 19 Feb 2009 02:57:47 -0800 (PST) In-Reply-To: <20090219.014758.23973.0@webmail04.vgs.untd.com> References: <20090219.014758.23973.0@webmail04.vgs.untd.com> Date: Thu, 19 Feb 2009 11:57:47 +0100 Message-ID: <53cd6c2e0902190257u37e957e7se4f208975dfadd64@mail.gmail.com> From: Jesrad To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 10:57:38 -0000 Just a few remarks: On Thu, Feb 19, 2009 at 7:47 AM, dyerbrookme@juno.com wrote: > At one point, some AWG members introduced a JIRA (feature proposal wiki) = motion to have a check-off box on SL-made objects offering consent or non-c= onsent for an object to travel to other grids. There was a heated discussio= n about this and the author withdrew the proposal, regrettably: > http://jira.secondlife.com/browse/MISC-1272 I expect that interoperability/conversion of content from one grid to the other will be limited by technical constraints so it won't apply broadly and suddenly, but the point remains that some way to prevent that conversion on behalf of the owner of it should exist. Though here we disagree philosophically on exactly who this owner is and how, that's something I can fully get behind. I certainly wouldn't like it if my newest model of airship was disclosed with full-permissions and copied over to a third-party sim simply because someone from the OpenGrid TPed to my sim and had a look (that includes looking through a sim border) while I was working on it. > You're also suggesting that users who "care about interoperability" shoul= d "choose not to purchase that content" -- i.e. you're essentially demandin= g that creators share their content into grids that do not protect their IP= , or face boycotts if they don't go along with this forced march. What's th= at all about? I think this was more a statement of fact than one of ideological position, really. The resident chooses what client software runs on his/her machine and how, it cannot be trusted to respect legal/contractual bounds by technique, and that's got nothing to do with how the server software works - and the point here I think is that the same applies to server operation with regards to interoperability protocol. This is akin to international agreements between sovereign states: neither side has the authority to reasonably enforce them over the other. And merely stating that they should ideally limit themselves to bounds they are eager to respect is not the same as saying that all international agreements are to be considered void from the get-go. That said, yes, welcoming visitors from third-party grids and selling them things, that should be and remain the resident's ultimate choice. But that's an implementation detail for LL to build into their code, so it's probably out of the scope of this discussion list. > (Creative Commons follows much the same logic, making it possible to opt = for a license to offer your creations to be copied for credit, but not opt = for a license to copy for cash, and urging everyone to give away content fo= r free, and not making a mechanism to get paid for content, i.e. integratin= g micropayments with content distribution as SL does). I'm not sure what you mean here by "mechanism to get paid for content". For months already I've been getting paid as an independant content provider in SL for creating full-perm works. I have the exact opposite claim to yours: my CC-like license cannot be enforced correctly due to the permissions system in SL, and that's disrupting my trade to a fortunately small extent, whenever someone buys stuff from me then slaps restrictions on it that are illegitimate. To me the permissions system is hampering the rights-model that I'm becoming reliant on for earning a living (fortunately the model is robust enough to severly limit this hampering), and I wish I could "opt-out" my works from the permissions system to fix that. From jesrad@gmail.com Thu Feb 19 03:38:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCE5C28C116 for ; Thu, 19 Feb 2009 03:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOZOkFWru2IV for ; Thu, 19 Feb 2009 03:38:04 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id 76A543A67E4 for ; Thu, 19 Feb 2009 03:38:04 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so312950fkf.5 for ; Thu, 19 Feb 2009 03:38:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gTKI56VsD1FRJctWUi25/D8+CA6gOtWFAmOAIXhhSQo=; b=a74n1M29br9U7LLA8sXzfNHltCIT63etbEs7yUpd8p0ilqmDEaN+DC8yO+uQeOOo5o 3XVecw/ZNcDaP732Uxx3cjTVyAVnaThBtKaWpqs46UcOW7wQGDSEkxLzW1QdVQz0qXGm 1WAoBjU4iGSziNClD/cjcTv2bIfZ6/fOqsJhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pJUS2E9E/OJcidbpIK2uz3j6ocsbXGHfJz6pvU7IFXcZFqykmARG/RsBiN7KD/zVpi X9WbSYtsVIcVs4G156NLDaP45qdoEAqhk4FOyRZyl5wlxHoCU58/zfASFVgTgmO7rqC2 PvuTKrLg+tYlMjrxqRGOWRObCHqD1pg4Eu1g0= MIME-Version: 1.0 Received: by 10.181.158.2 with SMTP id k2mr1172111bko.145.1235043496620; Thu, 19 Feb 2009 03:38:16 -0800 (PST) In-Reply-To: <499CA6DA.2010003@gmail.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <659848.26941.qm@web82607.mail.mud.yahoo.com> <499CA6DA.2010003@gmail.com> Date: Thu, 19 Feb 2009 12:38:16 +0100 Message-ID: <53cd6c2e0902190338m5aad4ed2ia624e7826c17fb15@mail.gmail.com> From: Jesrad To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 11:38:05 -0000 I'd say the same can be said of anything related to any object but not being the object itself: just as the "script" of an object should be communicated between grids as an external reference, so should the 2D or 3D representation, the sound/stream, the text stream, etc. E.g. I drive my virtual car through a portal to another grid: the information exchanged is just a stack of references: a ref to its 3D representation (CAPS ?), a ref to the running script, a ref to the Agent Domain (for ownership, controls, access rights, whatever), a ref to the source grid, etc... all of those to be accessed by the destination grid. That stack of references, at the MetaGrid level and in itself, "is" this virtual car owned by me at this place and time and is interoperable to the extent that the VWs can handle these types of references (and their respective clients can display them, but that's something else). A translation table can be established at the object level for supplying different refs to different grids (I have 3D models in mind here), maybe that makes one more reference in the stack. In this view the only interoperability that needs to be coordinated between the VWs, is that of uniformity of access, like with a standardized API. The problem I see here is that in this model, internal scripts for objects need to be accessed uniformly, too. When my car bumps into something and is scripted for that event, both grids need to be capable of calling the right event handler. On Thu, Feb 19, 2009 at 1:24 AM, Jon Watte wrote: > > I think the lowest common denominator may be aiming too low -- we need to > deliver actual value to actual end users paying for that value, or the whole > effort is moot. > > However, that being said, I'm prepared to throw a stake in the ground: You > cannot migrate behavior. > If behavior is authored for system X, then system Y will not be reasonably > expected to perform that behavior at full fidelity. For example, behavior > could be written in Java for Wonderland, or Python for Qwaq or Panda3D, or > C++ and XPath for OLIVE. There simply is no way that every virtual world > will be capable of emulating the execution environment of each other virtual > world (here's a case where X3D broke down -- it specified an execution > environment, that didn't actually suit anyone's needs). > > Thus, to make an object appear in a "remote" world, that object needs to be, > at a minimum, simulated in the "home" world, and information about the > outcome of that simulation (animations played, movements performed, sounds > generated, interactions caused, etc) should be transmitted over the > interoperability channel. > > Sincerely, > > jw > > > Charles Krinke wrote: >> >> So, it behooves us to find that lowest common denominator and see if we >> can create a useful specification to avoid wasting any of our time. I have >> to believe that there exists a subset of the SecondLife OGP and HyperGrid >> notions that can at least form a basis to start building. If not, perhaps >> someone can propose such a basis. > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From belxjander@gmail.com Thu Feb 19 04:28:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C683A67E3 for ; Thu, 19 Feb 2009 04:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ilXgcUZPivHy for ; Thu, 19 Feb 2009 04:28:55 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id D9DEC3A6AF4 for ; Thu, 19 Feb 2009 04:28:55 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so361871rvb.49 for ; Thu, 19 Feb 2009 04:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=PCfuPFdBEwg5xn6wr5JiDIp7ZRFAgArNz6TN5H0de+c=; b=Ta5Va5Sr2RJ+lUw7ChwQ3JHiuwsj1NEapj7DGVUQGDt86HWSLrehuikzZPVvuyBN1q Q34mB76grCOQJPMustb92di9KQL0QopMSAxdQSscOAX4Yv5vPVs7a81tUYlmi9WR7vWn G4X8LUuuDcZV5RpL8XJB2rysaE3rrkFRzjZLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=lGkrbyZbThHFGIQil2FZuM6UnV9MOcuZUzHIhI25bynedG5NCaPNFtwlz2oyJR8f6b fK0e3hTcTpRc4vNY/BMUmXGYQ8A6wEhlaQbR4NmXS5wUaY+fMM3Q4i9GnWWgyaX0IA5O nBrKa+Wk1RW4Lh1Yg2xGVfhWpNsvXZeXWRVis= Received: by 10.141.171.3 with SMTP id y3mr4583204rvo.263.1235046548547; Thu, 19 Feb 2009 04:29:08 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id b8sm2687410rvf.8.2009.02.19.04.29.05 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 04:29:07 -0800 (PST) From: Kajikawa Jeremy To: Jesrad In-Reply-To: <53cd6c2e0902190338m5aad4ed2ia624e7826c17fb15@mail.gmail.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <659848.26941.qm@web82607.mail.mud.yahoo.com> <499CA6DA.2010003@gmail.com> <53cd6c2e0902190338m5aad4ed2ia624e7826c17fb15@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oFup+EhoarjimWfBgcgs" Date: Thu, 19 Feb 2009 21:23:46 +0900 Message-Id: <1235046226.7560.65.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mmox@ietf.org, Jon Watte Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 12:28:56 -0000 --=-oFup+EhoarjimWfBgcgs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable But any transfer of objects outside being part of the AV itself I would consider to be either subject to breakage or likely to come across with dataloss in function. this also reads to me as requiring the following... Each "System" is developed independently and a common library is developed (akin Java) for a write-once run-anywhere specification where the backends use each systems local implimentation of any given functionality, and also the requirement of specific support. How many developers actually use Java/Python/... as cross-platform development, currently WoW has LUA for scripting the client, SL has LSL and this is scripting independent of the client and running on the server as well as "attachment" scripts for extending the AV functionality with client-side UI presence. Therefore I suggest a middle-path... allow each system to select its own scripting language, and only require a "common library" of functionality presence with cross-binding option. That way anyone who impliments anything can rely on the functionality at scripted level remaining stable on the originating grid, (LSL already has C# and C language editions) I see the interoperability needing support from those systems making it available. I do see one point of contention that will break this occuring, what to support first? How about presence alone and simply do not provide any mechanism for import/export of materials across worlds that are containing any "script" or executable content. disconnect that into an own server and make the functions required follow the KISS rule, the more that is applied the more successfully available interop will become.=20 For now scripting will have to be "future"...basic shapes and "look" on objects need to follow getting AV transfer occuring without the entire legal mess considering... Guild Wars and some other games dont licence the engine but instead the content, and this content would need to have downgraded editions available for non-licensed viewing so some kind of system<->system remapping WILL occur somewhere. On Thu, 2009-02-19 at 12:38 +0100, Jesrad wrote: > I'd say the same can be said of anything related to any object but not > being the object itself: just as the "script" of an object should be > communicated between grids as an external reference, so should the 2D > or 3D representation, the sound/stream, the text stream, etc. >=20 > E.g. I drive my virtual car through a portal to another grid: the > information exchanged is just a stack of references: a ref to its 3D > representation (CAPS ?), a ref to the running script, a ref to the > Agent Domain (for ownership, controls, access rights, whatever), a ref > to the source grid, etc... all of those to be accessed by the > destination grid. >=20 > That stack of references, at the MetaGrid level and in itself, "is" > this virtual car owned by me at this place and time and is > interoperable to the extent that the VWs can handle these types of > references (and their respective clients can display them, but that's > something else). A translation table can be established at the object > level for supplying different refs to different grids (I have 3D > models in mind here), maybe that makes one more reference in the > stack. >=20 > In this view the only interoperability that needs to be coordinated > between the VWs, is that of uniformity of access, like with a > standardized API. >=20 > The problem I see here is that in this model, internal scripts for > objects need to be accessed uniformly, too. When my car bumps into > something and is scripted for that event, both grids need to be > capable of calling the right event handler. >=20 > On Thu, Feb 19, 2009 at 1:24 AM, Jon Watte wrote: > > > > I think the lowest common denominator may be aiming too low -- we need = to > > deliver actual value to actual end users paying for that value, or the = whole > > effort is moot. > > > > However, that being said, I'm prepared to throw a stake in the ground: = You > > cannot migrate behavior. > > If behavior is authored for system X, then system Y will not be reasona= bly > > expected to perform that behavior at full fidelity. For example, behavi= or > > could be written in Java for Wonderland, or Python for Qwaq or Panda3D,= or > > C++ and XPath for OLIVE. There simply is no way that every virtual worl= d > > will be capable of emulating the execution environment of each other vi= rtual > > world (here's a case where X3D broke down -- it specified an execution > > environment, that didn't actually suit anyone's needs). > > > > Thus, to make an object appear in a "remote" world, that object needs t= o be, > > at a minimum, simulated in the "home" world, and information about the > > outcome of that simulation (animations played, movements performed, sou= nds > > generated, interactions caused, etc) should be transmitted over the > > interoperability channel. > > > > Sincerely, > > > > jw > > > > > > Charles Krinke wrote: > >> > >> So, it behooves us to find that lowest common denominator and see if w= e > >> can create a useful specification to avoid wasting any of our time. I = have > >> to believe that there exists a subset of the SecondLife OGP and HyperG= rid > >> notions that can at least form a basis to start building. If not, perh= aps > >> someone can propose such a basis. > > > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-oFup+EhoarjimWfBgcgs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJnU9SAAoJECHrKutFYVwTLO8P/1XPs0MIyGnsoAHjcVOhKR4c 5QKKntr4G24pDGwjHNqowTkqetQtjhzTIX89Aqxjakz5MvxLtoWfU6BH5jKoylnk E6NNd/0RZAiWBT4tVDJx5d3N4j7U1U0QNp30OJp/dyQKB9BsJP9/X7gwnsNIb2Ww jdpX9+QZgOdBvF9QbWT6QzkICyowbBKUuXV0WL/efmqdDgO2AuYYIWx9XOUf6l0w zEzML9rQR/u+4TlMvIZjR7LVpp3bTxPy6dveWMih7j8L8rlhGOGmMHTcNaqkl0sU EP3JdwksuEX4/+1OCw92XDoza3jcKoXm0h1E4RVUGnXSLW0uvvVVEm0+XaqKvtRD Vsf+6govCoc8vIyGncQo8PTrwscjR7VYWj7ebWTpnpCsgHU45vmccwKX85qM8rRU BavAm4dS/4SqFtmGFyWNtIbd5i1TpgvLJxPMqw+3Fdy8K4nUCO1UgR10q8ow6Tse zeYo8QIz6PuTh/PpjtjKQcCMafSIV3n+57hz6Apo4Gx9cgJF5EVxMhLiXNd2n06c 2ELd5RdYsGCAXAPjv67SPuazozs3iWWQBQIxaMX5xGFpgpfuj4unrJ5t3wRNUziW j9iyz2liuBgRJsetdhPfaUI8Hl+FjfGx8xknZojfbugxncaDxd9vj0sxCNK0jN2I 6HctstLAwaP2znG0TmHd =VG7y -----END PGP SIGNATURE----- --=-oFup+EhoarjimWfBgcgs-- From belxjander@gmail.com Thu Feb 19 04:37:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AC443A6B08 for ; Thu, 19 Feb 2009 04:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzRCrDe5BCcy for ; Thu, 19 Feb 2009 04:37:24 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 836EE3A6AE2 for ; Thu, 19 Feb 2009 04:37:24 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so364521rvb.49 for ; Thu, 19 Feb 2009 04:37:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=zuAPVuLfKEZZ8xHy+8USiKPEuVAbF25GQGXqggHyajQ=; b=CL7w1tpXmmK+GX4c7Lor21B+F6Cx7JkPKficdA0AEEFxt+P2lUiS9rFR2WPcGiREdM UkTpIA3HxZ0GSAJUd8IF/pL8vILkzhVx3OTq4s0Tb1yf5qOh7SOdcdKGtEBvaP9Yfy2s MZntHYPz7erFTnoVTsBTYwDckpGxwZoPlvUg8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=AJcD5Au0Eyg80/CUbwx9n+LF/1+cikIgpREyxGXitzfAazoZBflQ9WneD1/00DVL8H m95lFhBO1PAyaZlgUM9/QXvIVPSdO0kEXICU+AlnY/ML1c67qGWNH9QA93UaZ8xhyftC vAcEP5yHNlUjnY1LAyz5KUgTy18vgJ+O76j8U= Received: by 10.140.171.18 with SMTP id t18mr4593916rve.95.1235047057209; Thu, 19 Feb 2009 04:37:37 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id f21sm2728756rvb.2.2009.02.19.04.37.28 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 04:37:30 -0800 (PST) From: Kajikawa Jeremy To: Jesrad In-Reply-To: <53cd6c2e0902190128t2c1df992safb425d3e43550a5@mail.gmail.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> <499CF445.1000705@gmail.com> <53cd6c2e0902190128t2c1df992safb425d3e43550a5@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zZ0IwsrtHehYlSoPnJYz" Date: Thu, 19 Feb 2009 21:32:08 +0900 Message-Id: <1235046728.7560.68.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mmox@ietf.org Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 12:37:26 -0000 --=-zZ0IwsrtHehYlSoPnJYz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Is this approach where each system can provide "own proxy" for the non-native clients that can enter ? This would allow the commercial systems to remain closed while also supporting the "open" clients as well. But then there is the whole "mind share war" between closed and open systems as it is, and I think the open systems are going to breach and break the closed systems eventually. but thats just my own reading of the following... How accurate is my reading? On Thu, 2009-02-19 at 10:28 +0100, Jesrad wrote: > The approach used in IEEE 1278 seems to differ radically from the > function OGP is assumed to permit, from a glance: as you said it lets > otherwise incompatible domains of simulation (call them grids) > exchange just the amount and type of information needed to remain > consistent between themselves. >=20 > Transposed to a VW, this would mean you can use the SL client to > connect to an SL grid, then your current simulator connects you > through to other environments (WoW, Solipsis, etc.) and does the > "translation". If the "foreign" domain/grid does not support some > Agent Domain services or something else, then the "local" domain can > then provide its own as a substitute, while the client is tasked with > interpreting any native data that rides through (like 3D > representation and sound format). >=20 > Is it right ? Maybe detailing a specific example would help pointing > out what should be and shouldn't be in such a protocol. (We're trying > to minimize the amount or complexity of translation required both at > the gateway and the client, aren't we ?) >=20 > On Thu, Feb 19, 2009 at 6:55 AM, Jon Watte wrote: > > Dan Olivares wrote: > >> > >> objection that I've heard so far is that it requires a lot more work > >> (service calls?) to develop a shared scene graph and requires a > >> significant more amount of trust then an A-->B teleport does. > >> > > > > There is no shared scene graph. Each server simulates "its" objects, an= d > > translates from the "interop" protocol to its internal system at the > > gateway. Think of it like a more modern version of IEEE 1278 (which has= been > > a great success as far as interoperable distributed simulation goes). > > > > Sincerely, > > > > jw > > > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-zZ0IwsrtHehYlSoPnJYz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJnVFIAAoJECHrKutFYVwTyFkP+wc4bqjRzmducGgxCZEOqVag V8ATnfcXVxIOAkHTjj+Y1qhKegh5Ot94fbRIFnmSXRhNm+MMJPnxHqY9hN5fLgQM K+yhfa/msI0Hz44VdwA3lLvxFiGauRl3WRG0buxx1Q//fHjlHwW6iqQWHddpdShV lHJU4EAivyLx5P2GioLdt4nv7onKNwoeot56zabVS/XmbgHb8zIvHqP2Ln+32Nsg HVeESLk/1iIu9GUUgH0ZCbFRlep/7dx1qLi5KBqIq2FNRzX5AXuBq4iIctqNTj1t i6keNOVbc1SXj+uzTrsvKD2YUENc9MyhSZ4Zi8gRzshmjI8AZ7+jZJcYVuv0ie0b N1LPNanPYX0uNgZ1GnL9XXITgiixFxZTCxwLbl4NlBRFyq5oK7lLH8gBRnOCUrWV HWN0H98drob5FKRmEJO0dCF5kgrWSal2EUqSifzQR1koXgErA/XKI/sYuNbuX8Fu YTX+Jayb2uVxHkOpepKdCBKygXXCvyilf4AHfbZeD3bRp56ug6mC3cmisy4s9jjd ehJZVwysJLhPaUM571pAiaC/7/SBz/pR+Pk0bE8XHqgNnrJh1FrfDhr80gEgzP0Z MjcvpCFeqWfwigRX0MjulymUaTSZsbbb+1NQAXeqE0jR4L9iASO0Eg4+xT2p8jBU 6s59lV1XgQ40AmgMyZCx =VKeD -----END PGP SIGNATURE----- --=-zZ0IwsrtHehYlSoPnJYz-- From coyle+mmox@knifejaw.com Thu Feb 19 04:56:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100FE3A6AE2 for ; Thu, 19 Feb 2009 04:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8v3s0pvPvXz for ; Thu, 19 Feb 2009 04:56:14 -0800 (PST) Received: from frog.knifejaw.com (frog.knifejaw.com [72.14.184.50]) by core3.amsl.com (Postfix) with ESMTP id 633E03A6975 for ; Thu, 19 Feb 2009 04:56:14 -0800 (PST) Received: by frog.knifejaw.com (Postfix, from userid 1000) id B30DD12084; Thu, 19 Feb 2009 07:56:26 -0500 (EST) Date: Thu, 19 Feb 2009 07:56:26 -0500 From: Dave Coyle To: mmox@ietf.org Message-ID: <20090219125626.GB1721@frog.knifejaw.com> References: <499CC99D.8040302@cox.net> <5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com> <6A5E83A8-A7A1-4D38-8FAC-C04E360E4777@lindenlab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A5E83A8-A7A1-4D38-8FAC-C04E360E4777@lindenlab.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Subject: Re: [mmox] meeting minutes from today's ietf mmox simulcasting meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 12:56:15 -0000 On 2009-02-18 23:45:45 -0500, infinity@lindenlab.com wrote: > * is the use of mmox@jabber.ietf.org required? several mac users > have noted difficulty in using it. That's because the room hasn't been created yet. :) Try test@jabber.ietf.org ... that works, mmox doesn't. -Coyle From jesrad@gmail.com Thu Feb 19 05:04:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4898C3A6B3E for ; Thu, 19 Feb 2009 05:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_51=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nces5VvMQzA9 for ; Thu, 19 Feb 2009 05:04:06 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 726213A6B2B for ; Thu, 19 Feb 2009 05:04:05 -0800 (PST) Received: by bwz5 with SMTP id 5so1085127bwz.13 for ; Thu, 19 Feb 2009 05:04:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HQSZCObHAda4yDZqwbN0I0u1+kjIppacOUPtWFoF3Ys=; b=JVjFXkXQ1gVR/df5iXDrGAxqOYHzDTvZEu0gXlvkITGdOf75hY+bpJyA6AU2ZRNUm9 aazA9YB9eELTIxy+CYvccuCELdLAEdZyqKaFqIgxL1Pk32TusGy9DnGTkT2fGVNvtNq+ Ac6CWEQS2Fd/VuER+y5R5LMr7BKrafTkASgCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rvhXOGkHW76YFjr/D/iC/uRm3EkTWMFeeJkSo4xZiS4sZr1hYu3Wl1cXPFY+VeL7qh 7T9TZ15iEgJmNieELaeere94NPOqNA0UbFeMlxLcsJbeb59NNUvnTSz8oEd0D4ddwtwL 48OaD9oEFjFWWyst0a5/x4WMeYV7hAsO6CUwc= MIME-Version: 1.0 Received: by 10.181.50.1 with SMTP id c1mr1560603bkk.3.1235048656551; Thu, 19 Feb 2009 05:04:16 -0800 (PST) In-Reply-To: <1235046226.7560.65.camel@localhost> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <659848.26941.qm@web82607.mail.mud.yahoo.com> <499CA6DA.2010003@gmail.com> <53cd6c2e0902190338m5aad4ed2ia624e7826c17fb15@mail.gmail.com> <1235046226.7560.65.camel@localhost> Date: Thu, 19 Feb 2009 14:04:16 +0100 Message-ID: <53cd6c2e0902190504s503c8a56g60badcb378157729@mail.gmail.com> From: Jesrad To: Kajikawa Jeremy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, Jon Watte Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 13:04:07 -0000 > Therefore I suggest a middle-path... allow each system to select its own > scripting language, > and only require a "common library" of functionality presence with > cross-binding option. > > That way anyone who impliments anything can rely on the functionality at > scripted level > remaining stable on the originating grid, (LSL already has C# and C > language editions) > > I see the interoperability needing support from those systems making it > available. Yes, that's what I was talking about: the common protocol is really a standard remote-API that VWs should conform to when communicating with clients - a conveyor of relevant information but not the information itself. By making an object a pure stack of references (one reference per Grid service to be used) then the format of these references and the external object they point at can be expanded upon very easily afterwards. Furthering this view, a VW then does just one minimal function: connecting the dots. A Grid becomes little more than a router for the relevant references/info, in this model. Some Grids may internally host the objects refered to (the 3D data, the sound files ,etc...) and apply access control, while some others might depend entirely on external hosting (we could have clients that fetch textures through plain HTTP, references could even point to local files for games that have static content) and let the client end handle authentication, but in the bigger picture then it's only the end clients and the hosts/sources that are being connected together through the grids, while these underlaying grids affect the content very little: they'd be acting on the connection only. The bare minimum a VW does, then, is transmitting just the presence signal between congruent entities, so each of them knows "who's there" depending on this "there". Additional functions and signals can be internally hosted and/or signalled on a per-grid basis, like with MIME codes for the Web. That makes the interoperability protocol into some sort of service location and discovery protocol, I think. > How many developers actually use Java/Python/... as cross-platform > development, Javascript ? Flash ? I think they owe their heavily cross-platform usage more to the market they're used in, than to any special characteristic they may have as languages. And that this market resembles VWs more than the general professional software industry does, so I don't see why we shouldn't expect the same for VW scripting. On Thu, Feb 19, 2009 at 1:23 PM, Kajikawa Jeremy wrote: > But any transfer of objects outside being part of the AV itself I would > consider to be > either subject to breakage or likely to come across with dataloss in > function. > > this also reads to me as requiring the following... > > Each "System" is developed independently and a common library is > developed (akin Java) > for a write-once run-anywhere specification where the backends use each > systems local > implimentation of any given functionality, and also the requirement of > specific support. > > How many developers actually use Java/Python/... as cross-platform > development, > > currently WoW has LUA for scripting the client, SL has LSL and this is > scripting independent > of the client and running on the server as well as "attachment" scripts > for extending the AV > functionality with client-side UI presence. > > Therefore I suggest a middle-path... allow each system to select its own > scripting language, > and only require a "common library" of functionality presence with > cross-binding option. > > That way anyone who impliments anything can rely on the functionality at > scripted level > remaining stable on the originating grid, (LSL already has C# and C > language editions) > > I see the interoperability needing support from those systems making it > available. > > I do see one point of contention that will break this occuring, what to > support first? > > How about presence alone and simply do not provide any mechanism for > import/export > of materials across worlds that are containing any "script" or > executable content. > > disconnect that into an own server and make the functions required > follow the KISS rule, > the more that is applied the more successfully available interop will > become. > > For now scripting will have to be "future"...basic shapes and "look" on > objects need to > follow getting AV transfer occuring without the entire legal mess > considering... > > Guild Wars and some other games dont licence the engine but instead the > content, > and this content would need to have downgraded editions available for > non-licensed > viewing so some kind of system<->system remapping WILL occur > somewhere. > > > On Thu, 2009-02-19 at 12:38 +0100, Jesrad wrote: >> I'd say the same can be said of anything related to any object but not >> being the object itself: just as the "script" of an object should be >> communicated between grids as an external reference, so should the 2D >> or 3D representation, the sound/stream, the text stream, etc. >> >> E.g. I drive my virtual car through a portal to another grid: the >> information exchanged is just a stack of references: a ref to its 3D >> representation (CAPS ?), a ref to the running script, a ref to the >> Agent Domain (for ownership, controls, access rights, whatever), a ref >> to the source grid, etc... all of those to be accessed by the >> destination grid. >> >> That stack of references, at the MetaGrid level and in itself, "is" >> this virtual car owned by me at this place and time and is >> interoperable to the extent that the VWs can handle these types of >> references (and their respective clients can display them, but that's >> something else). A translation table can be established at the object >> level for supplying different refs to different grids (I have 3D >> models in mind here), maybe that makes one more reference in the >> stack. >> >> In this view the only interoperability that needs to be coordinated >> between the VWs, is that of uniformity of access, like with a >> standardized API. >> >> The problem I see here is that in this model, internal scripts for >> objects need to be accessed uniformly, too. When my car bumps into >> something and is scripted for that event, both grids need to be >> capable of calling the right event handler. >> >> On Thu, Feb 19, 2009 at 1:24 AM, Jon Watte wrote: >> > >> > I think the lowest common denominator may be aiming too low -- we need to >> > deliver actual value to actual end users paying for that value, or the whole >> > effort is moot. >> > >> > However, that being said, I'm prepared to throw a stake in the ground: You >> > cannot migrate behavior. >> > If behavior is authored for system X, then system Y will not be reasonably >> > expected to perform that behavior at full fidelity. For example, behavior >> > could be written in Java for Wonderland, or Python for Qwaq or Panda3D, or >> > C++ and XPath for OLIVE. There simply is no way that every virtual world >> > will be capable of emulating the execution environment of each other virtual >> > world (here's a case where X3D broke down -- it specified an execution >> > environment, that didn't actually suit anyone's needs). >> > >> > Thus, to make an object appear in a "remote" world, that object needs to be, >> > at a minimum, simulated in the "home" world, and information about the >> > outcome of that simulation (animations played, movements performed, sounds >> > generated, interactions caused, etc) should be transmitted over the >> > interoperability channel. >> > >> > Sincerely, >> > >> > jw >> > >> > >> > Charles Krinke wrote: >> >> >> >> So, it behooves us to find that lowest common denominator and see if we >> >> can create a useful specification to avoid wasting any of our time. I have >> >> to believe that there exists a subset of the SecondLife OGP and HyperGrid >> >> notions that can at least form a basis to start building. If not, perhaps >> >> someone can propose such a basis. >> > >> > _______________________________________________ >> > mmox mailing list >> > mmox@ietf.org >> > https://www.ietf.org/mailman/listinfo/mmox >> > >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > From jesrad@gmail.com Thu Feb 19 05:19:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC9F53A6AD8 for ; Thu, 19 Feb 2009 05:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdGpMyT0BqlG for ; Thu, 19 Feb 2009 05:19:21 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 7318E3A6912 for ; Thu, 19 Feb 2009 05:19:21 -0800 (PST) Received: by bwz5 with SMTP id 5so1106623bwz.13 for ; Thu, 19 Feb 2009 05:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V0btCuqUlOyKneKGdTKOCA0HgPq2iglUmica/wCk2eQ=; b=IJzgG8f1O3aaQ+5cr21SKLGwncr1gakNan9MiQ9ypRrawn893eXv9OqX+aEe1fnmfJ U0otpgvmBDD0QimDuWqjWk078jsvCneuFctnhSAVmeJnCfZtBkpkPg8dEtz6AgGfnFJC 7iMzm7SXvpQrbJgO3kDZckNLRUUezTixuUY/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s5uCzPe4xjxl6uqS/6EOF/mwoySyKIK1AVuIIpAfvQhXKhEMe411m4JngXHMblyuAj YOk9IK3FB4Vwlb1a6PULjJT5VkM1LMFEfFUYT/+cui0DJGzgrxV25ikqCsq+Jg3oeNcy i/eUu6nLxBQlG20WMkfr6NrHfBlaLcSr/BauY= MIME-Version: 1.0 Received: by 10.181.36.9 with SMTP id o9mr2104765bkj.148.1235049573141; Thu, 19 Feb 2009 05:19:33 -0800 (PST) In-Reply-To: <1235046728.7560.68.camel@localhost> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> <499CF445.1000705@gmail.com> <53cd6c2e0902190128t2c1df992safb425d3e43550a5@mail.gmail.com> <1235046728.7560.68.camel@localhost> Date: Thu, 19 Feb 2009 14:19:33 +0100 Message-ID: <53cd6c2e0902190519m3adad91cyed621c71f7e8b426@mail.gmail.com> From: Jesrad To: Kajikawa Jeremy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 13:19:22 -0000 Well, I can imagine a closed VW proxying alternate/degraded models in lieu of the actual 3D models for its internally-hosted objects and avatars, and distorting inworld sound/video streams, so as to prevent copyright infringement in visiting non-trusted VWs, but then the entire point of interoperability would be lost. I cannot find much appeal in driving a gray sphere with an hovertext reading "This would look like a sports car if you subscribed" in lieu of the actual car model. Ceci n'est pas une pipe. On Thu, Feb 19, 2009 at 1:32 PM, Kajikawa Jeremy wrote: > Is this approach where each system can provide "own proxy" for > the non-native clients that can enter ? > > This would allow the commercial systems to remain closed while > also supporting the "open" clients as well. > > But then there is the whole "mind share war" between closed and > open systems as it is, and I think the open systems are going to > breach and break the closed systems eventually. > > but thats just my own reading of the following... > > How accurate is my reading? > > On Thu, 2009-02-19 at 10:28 +0100, Jesrad wrote: >> The approach used in IEEE 1278 seems to differ radically from the >> function OGP is assumed to permit, from a glance: as you said it lets >> otherwise incompatible domains of simulation (call them grids) >> exchange just the amount and type of information needed to remain >> consistent between themselves. >> >> Transposed to a VW, this would mean you can use the SL client to >> connect to an SL grid, then your current simulator connects you >> through to other environments (WoW, Solipsis, etc.) and does the >> "translation". If the "foreign" domain/grid does not support some >> Agent Domain services or something else, then the "local" domain can >> then provide its own as a substitute, while the client is tasked with >> interpreting any native data that rides through (like 3D >> representation and sound format). >> >> Is it right ? Maybe detailing a specific example would help pointing >> out what should be and shouldn't be in such a protocol. (We're trying >> to minimize the amount or complexity of translation required both at >> the gateway and the client, aren't we ?) >> >> On Thu, Feb 19, 2009 at 6:55 AM, Jon Watte wrote: >> > Dan Olivares wrote: >> >> >> >> objection that I've heard so far is that it requires a lot more work >> >> (service calls?) to develop a shared scene graph and requires a >> >> significant more amount of trust then an A-->B teleport does. >> >> >> > >> > There is no shared scene graph. Each server simulates "its" objects, and >> > translates from the "interop" protocol to its internal system at the >> > gateway. Think of it like a more modern version of IEEE 1278 (which has been >> > a great success as far as interoperable distributed simulation goes). >> > >> > Sincerely, >> > >> > jw >> > >> > _______________________________________________ >> > mmox mailing list >> > mmox@ietf.org >> > https://www.ietf.org/mailman/listinfo/mmox >> > >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > From morgaine.dinova@googlemail.com Thu Feb 19 05:38:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7244F3A6B41 for ; Thu, 19 Feb 2009 05:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F4dpPtwpKn3 for ; Thu, 19 Feb 2009 05:38:36 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 1A3503A6B02 for ; Thu, 19 Feb 2009 05:38:35 -0800 (PST) Received: by bwz5 with SMTP id 5so1133720bwz.13 for ; Thu, 19 Feb 2009 05:38:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=5F7fW/PjdOXpC9a0MEPOe5TSa14KrDDjiray0tyD9qE=; b=wvi5GuRBECoRCRv9g8rghSP45z2UJkNywyqpDCXcp+bCUim71cd0Il+O32osCHEN65 CirMn364/h38kfJHvNyfRfM4wZV9vEugBTLJULtYZsDHNYcpUz2UdILpz/jT1ioETI/c JvKPDLzo7XO2FGlizhNRCIjra0xpwKx+SCPTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=en6UTmuSaq4RhrT2R8fnxIbFKwy3lUa2RvQGmMM9zz4SUc7BGqEJuS2zyUHvzxU2ms dPDNarflk4QMKoco43JkGfoMucjidmneBwbzYa6J0x2ASunpnyKzKhgZQdPhDGAm5NVF kCHedDdbQUwTKPMiPZJv1Ggs1a0TWXUl9Qo2Q= MIME-Version: 1.0 Received: by 10.181.145.6 with SMTP id x6mr1142574bkn.94.1235050727432; Thu, 19 Feb 2009 05:38:47 -0800 (PST) In-Reply-To: <6A5E83A8-A7A1-4D38-8FAC-C04E360E4777@lindenlab.com> References: <499CC99D.8040302@cox.net> <5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com> <6A5E83A8-A7A1-4D38-8FAC-C04E360E4777@lindenlab.com> Date: Thu, 19 Feb 2009 13:38:47 +0000 Message-ID: From: Morgaine To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001485f0a01ee36278046345a743 Subject: Re: [mmox] meeting minutes from today's ietf mmox simulcasting meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 13:38:37 -0000 --001485f0a01ee36278046345a743 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Excellent summary of a complex meeting, thanks Infinity. :-) On Thu, Feb 19, 2009 at 4:45 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > > * is the use of mmox@jabber.ietf.org required? several mac users have > noted difficulty in using it. > I'll echo Dave's reply that jabber.ietf.org is working fine. Some of us were in there together last night for tests in the "test" room. The "mmox" room hasn't yet been set up or enabled, but no doubt our AD can fix that. Looking at the Jabber room logs at http://jabber.ietf.org/logs/, it's worth noting that this facility is in use by many workgroups, well over a dozen since the start of the year. I think that it would serve MMOX well too, both during the forthcoming special meetings and subsequently when more interactive discussion is needed than email allows. Morgaine. --001485f0a01ee36278046345a743 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Excellent summary of a complex meeting, thanks Infinity. :-)

On Thu, Feb 19, 2009 at 4:45 AM, Meadhbh Hamrick (Infin= ity) <infini= ty@lindenlab.com> wrote:
 
  * is the use of mmox@jabber.ietf.org required? several mac users have noted diff= iculty in using it.

I'll echo Dave's reply that jabber.ietf.org is working fine.  Some of us wer= e in there together last night for tests in the "test" room. = ; The "mmox" room hasn't yet been set up or enabled, but no d= oubt our AD can fix that.

Looking at the Jabber room logs at http://jabber.ietf.org/logs/, it's worth noting that this faci= lity is in use by many workgroups, well over a dozen since the start of the= year.  I think that it would serve MMOX well too, both during the for= thcoming special meetings and subsequently when more interactive discussion= is needed than email allows.

Morgaine.
--001485f0a01ee36278046345a743-- From morgaine.dinova@googlemail.com Thu Feb 19 06:05:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9DB3A6B0C for ; Thu, 19 Feb 2009 06:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFtAmQvZ4zY5 for ; Thu, 19 Feb 2009 06:05:29 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id 6442E3A6B02 for ; Thu, 19 Feb 2009 06:05:29 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so376162fkf.5 for ; Thu, 19 Feb 2009 06:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=dJfFHwHhUjznIGGL71k7QKz+Otl3j7Mp3mXCLxnETJY=; b=qS+f6q8nALaGdH4YRcvPSpWp1ZirGXZVKTRZEhgM/Tc9Qib2w0e6U+uB5o7pSK48oN QVo2gRol1MkzGjCuVnvvKmv8CW9zvuBEbIc07Fv16QB8mPyTakZMOzEsZxaz6lGZR2ZR uddBQs9MyUdsrsE7GeeAtmWQyqxevly/Pca8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=nZRZKIJaihaVEuTZZQSMYwG5kfpNuAQ3acWDNgNrrmE/GDhVd3JfLIw4A0WZK5fE7z VwDUBmh8t7SUnf5K12gBUBuIVgm8GHwSkbVEAmAOxPa8O9fiG12EuivSRqT6rYlS+L35 w08FL3DQRSFl6K1HdQquQ+RWTZrbqAD4ru9Dg= MIME-Version: 1.0 Received: by 10.181.240.10 with SMTP id s10mr882280bkr.12.1235052341423; Thu, 19 Feb 2009 06:05:41 -0800 (PST) In-Reply-To: <53cd6c2e0902190257u37e957e7se4f208975dfadd64@mail.gmail.com> References: <20090219.014758.23973.0@webmail04.vgs.untd.com> <53cd6c2e0902190257u37e957e7se4f208975dfadd64@mail.gmail.com> Date: Thu, 19 Feb 2009 14:05:41 +0000 Message-ID: From: Morgaine To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636c5a82616ee2c0463460837 Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 14:05:31 -0000 --001636c5a82616ee2c0463460837 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 19, 2009 at 10:57 AM, Jesrad wrote: For months already I've been getting paid as an independant > content provider in SL for creating full-perm works. I have the exact > opposite claim to yours: my CC-like license cannot be enforced > correctly due to the permissions system in SL, and that's disrupting > my trade to a fortunately small extent, whenever someone buys stuff > from me then slaps restrictions on it that are illegitimate. To me the > permissions system is hampering the rights-model that I'm becoming > reliant on for earning a living That is very insightful, and shows just how hard this area really is. I think we may have to examine permissions propagation from first principles. A mechanism that doesn't work properly within even a single domain is clearly not the right one to endorse across multiple domains. Morgaine. --001636c5a82616ee2c0463460837 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 19, 2009 at 10:57 AM, Jesrad= <jesrad@gmail.com= > wrote:

For months already I've been getting paid as an independant
content provider in SL for creating full-perm works. I have the exact
opposite claim to yours: my CC-like license cannot be enforced
correctly due to the permissions system in SL, and that's disrupting my trade to a fortunately small extent, whenever someone buys stuff
from me then slaps restrictions on it that are illegitimate. To me the
permissions system is hampering the rights-model that I'm becoming
reliant on for earning a living

That is very insightfu= l, and shows just how hard this area really is.

I think we may have = to examine permissions propagation from first principles.  A mechanism= that doesn't work properly within even a single domain is clearly not = the right one to endorse across multiple domains.

Morgaine.

--001636c5a82616ee2c0463460837-- From morgaine.dinova@googlemail.com Thu Feb 19 07:36:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384813A6B97 for ; Thu, 19 Feb 2009 07:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrcUxWKiky1k for ; Thu, 19 Feb 2009 07:36:43 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id 649ED3A6B93 for ; Thu, 19 Feb 2009 07:36:42 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so415335fkf.5 for ; Thu, 19 Feb 2009 07:36:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jQgBnMPzoUqkQjihW4x7rShlM/LSP2gwkjterG4GXVg=; b=E8yyLxGYgel17W/+a9uCmgr980lzedO2hZCEjJ+J7l1DVdGf+14A2Zux4ZyRNowOTP D3P8zbecCwjhswVoj6/TdbpWd0FZaJefyh7Ls4AUlEFcGibRasMyjY3Q1uwVyBfkwRo8 CBSP35fraBzlnjZzq/lNIEsOcmevs/9DVyR00= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K4lDClFlp5ZkxZ6t+XYRX4ft3tjmqdRtJOl0qUE5nkqxT4nK8CyG1Qr2/bg35QNpoJ 6w46g2hshmi3R13sKJQOIilys4qMNk9ZhFbE1hhey2c1iaiSCl5kee267T0rHTbpGv7u iNuEKpafkvTcfUXwLEhflSBfQlaAZ3U4LVqfk= MIME-Version: 1.0 Received: by 10.181.197.6 with SMTP id z6mr1324154bkp.213.1235057814355; Thu, 19 Feb 2009 07:36:54 -0800 (PST) In-Reply-To: <499CA9BB.8070506@gmail.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> Date: Thu, 19 Feb 2009 15:36:54 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=00504502cd724d3f130463474e22 Cc: "mmox@ietf.org" Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 15:36:44 -0000 --00504502cd724d3f130463474e22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 19, 2009 at 12:37 AM, Jon Watte wrote: > > Let's assume organization A builds a space. Let's assume organization B > builds furniture. Now, they want to have a meeting, and see how the > furniture works in the space. The easiest way to accomplish this is to make > organization A users log into the organization A virtual world (like they > always do), and organization B users log into organization B virtual world > (like they always do), and make arrangements such that some room/area/island > within the two organizations is shared -- whatever comes to that space from > A, also shows up in B, and vice versa. This allows A to publish its space, > and B to bring the furniture to that space, without either having to > disconnect from their regular virtual world (buddy list, unified messaging, > inter-office collaboration, etc). > > Unfortunately, that's non-scalable, particularly along the complexity axis. It works fine in your example because you have only two parties wishing to share a space and hence there is only one space to simulate, but try to extrapolate from there to see where it leads. If your organization A has N users, and those N users wish to take part in N different worlds (which is asymptotically likely if N << total number of worlds), then your organization A must now simulate N different worlds. For large N, this places a colossal load on organization A, even if the individual shared spaces are minimally populated. To coin a common phrase by analogy, you're undertaking to "simulate the Internet". ;-) What's more, very few platform optimizations will be possible since the N worlds are all different, and this also means that the scalability of each shared space will be severely constrained as well. And as if that were not bad enough, the N worlds that your users visit tomorrow will not necessarily be today's N worlds, so for (N << total number of worlds) your local cache will need to grow almost without limit if it's to work at all. Even if organization A's machinery were powerful enough to support N radically different worlds through shared-space simulations though, they still couldn't do it, because in the general case the simulation code for a given world will not be available. The world simulation is the "secret sauce" of many virtual worlds, and from a business perspective it is quite likely to be their product differentiator and they will be loathe to share it. But even if it were freely available, the portability of one organization's simulation code to another organization's machinery is far from guaranteed with today's software technology, not to mention the management of upgrades for something this complex across organization boundaries. Now contrast that shared-space architecture to today's more prevalent one. Organizations A and B(1)...B(N) design their own worlds in accordance with their particular visions, and each world is tailored to their own optimized hardware. Now in the case when the N users of organization A travel to those N different B worlds, organization A has no world simulation load for active users at all (it just sends out data to the N worlds). Instead, some number of foreign users from the B worlds will arrive and need to be supported. However, they are supported in organization A's own world simulation, which is highly optimized by design and hence carries none of the complexity/scalability problems mentioned above in the shared-space approach. Foreign world simulations never need to be supported. In the Internet-like metaverse model of unlimited and extremely diverse worlds, I really don't see the shared-space approach as being at all viable, because diversity is its enemy. In some severely constrained corporate settings it might be quite usable (and even efficient for standardized worlds), but this does not seem to be a generally scalable model for an evolving metaverse. Morgaine. --00504502cd724d3f130463474e22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 19, 2009 at 12:37 AM, Jon Wa= tte <jwatte@gmail.= com> wrote:

Let's assume organization A builds a space. Let's assume organizati= on B builds furniture. Now, they want to have a meeting, and see how the fu= rniture works in the space. The easiest way to accomplish this is to make o= rganization A users log into the organization A virtual world (like they al= ways do), and organization B users log into organization B virtual world (l= ike they always do), and make arrangements such that some room/area/island = within the two organizations is shared -- whatever comes to that space from= A, also shows up in B, and vice versa. This allows A to publish its space,= and B to bring the furniture to that space, without either having to disco= nnect from their regular virtual world (buddy list, unified messaging, inte= r-office collaboration, etc).

Unfortu= nately, that's non-scalable, particularly along the complexity axis.
It works fine in your example because you have only two parties wishin= g to share a space and hence there is only one space to simulate, but try t= o extrapolate from there to see where it leads.  If your organization = A has N users, and those N users wish to take part in N different worlds (w= hich is asymptotically likely if N << total number of worlds), then y= our organization A must now simulate N different worlds.  For large N,= this places a colossal load on organization A, even if the individual shar= ed spaces are minimally populated.  To coin a common phrase by analogy= , you're undertaking to "simulate the Internet". ;-)

What's more, very few platform optimizations will be possible since= the N worlds are all different, and this also means that the scalability of each shared space will be severely constrained as well.  And as if tha= t were not bad enough, the N worlds that your users visit tomorrow will not= necessarily be today's N worlds, so for (N << total number of wo= rlds) your local cache will need to grow almost without limit if it's t= o work at all.

Even if organization A's machinery were powerful enough to support = N radically different worlds through shared-space simulations though, they = still couldn't do it, because in the general case the simulation code f= or a given world will not be available.  The world simulation is the &= quot;secret sauce" of many virtual worlds, and from a business perspec= tive it is quite likely to be their product differentiator and they will be= loathe to share it.  But even if it were freely available, the portab= ility of one organization's simulation code to another organization'= ;s machinery is far from guaranteed with today's software technology, n= ot to mention the management of upgrades for something this complex across = organization boundaries.

Now contrast that shared-space architecture to today's more prevale= nt one.  Organizations A and B(1)...B(N) design their own worlds in ac= cordance with their particular visions, and each world is tailored to their= own optimized hardware.  Now in the case when the N users of organiza= tion A travel to those N different B worlds, organization A has no world si= mulation load for active users at all (it just sends out data to the N worl= ds).  Instead, some number of foreign users from the B worlds will arr= ive and need to be supported.  However, they are supported in organiza= tion A's own world simulation, which is highly optimized by design and = hence carries none of the complexity/scalability problems mentioned above i= n the shared-space approach.  Foreign world simulations never need to = be supported.

In the Internet-like metaverse model of unlimited and extremely diverse= worlds, I really don't see the shared-space approach as being at all v= iable, because diversity is its enemy.  In some severely constrained c= orporate settings it might be quite usable (and even efficient for standard= ized worlds), but this does not seem to be a generally scalable model for a= n evolving metaverse.

Morgaine.
--00504502cd724d3f130463474e22-- From cfk@pacbell.net Thu Feb 19 07:55:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37AA33A6939 for ; Thu, 19 Feb 2009 07:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqQLIIMglUxo for ; Thu, 19 Feb 2009 07:55:34 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id D94443A6820 for ; Thu, 19 Feb 2009 07:55:33 -0800 (PST) Received: (qmail 77030 invoked by uid 60001); 19 Feb 2009 15:55:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=25De8iMIb7s0pTZX6sr9Q46Ikc/KwP2fdijTUjljYkCeAYErOw13qjA86c5/N/ikROVmLtefoi94RodWb5RoqItyf7afebWx+kqaOR08IW/XTrCQo2vC/4VvEhkTibMUouOy305yFOlFL0TPbV1K6yRfonoQJEovp4EHJz6hAJ4=; X-YMail-OSG: 5TKD.5AVM1nJihzRu1Zng.FZNp5n9hEk3SCpRuy696zyp2X86giUp8pQ Received: from [75.217.195.74] by web82602.mail.mud.yahoo.com via HTTP; Thu, 19 Feb 2009 07:55:45 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> Date: Thu, 19 Feb 2009 07:55:45 -0800 (PST) From: Charles Krinke To: "mmox@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-36906972-1235058945=:76086" Message-ID: <647098.76086.qm@web82602.mail.mud.yahoo.com> Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 15:55:35 -0000 --0-36906972-1235058945=:76086 Content-Type: text/plain; charset=us-ascii Dear Morgaine: That could very well be. Shared spaces may or may not be achievable in the near term. That sort of gets us back to figuring out what we "do" wish to accomplish. Are we here to seek consensus and modify the already existing and deployed OGP protocol of SecondLife? Are we here to see if HyperGrid from OpenSim is appropriate for this group? Are there other protocols to consider? So, I have to ask, as I am getting confused with all the e-mails flying around and like many, I have lots of things to concentrate on. So: "What are we here for and what do we hope to accomplish?" Charles ________________________________ From: Morgaine To: Jon Watte Cc: "mmox@ietf.org" Sent: Thursday, February 19, 2009 7:36:54 AM Subject: Re: [mmox] User Accounts / "Object" Transfer. On Thu, Feb 19, 2009 at 12:37 AM, Jon Watte wrote: Let's assume organization A builds a space. Let's assume organization B builds furniture. Now, they want to have a meeting, and see how the furniture works in the space. The easiest way to accomplish this is to make organization A users log into the organization A virtual world (like they always do), and organization B users log into organization B virtual world (like they always do), and make arrangements such that some room/area/island within the two organizations is shared -- whatever comes to that space from A, also shows up in B, and vice versa. This allows A to publish its space, and B to bring the furniture to that space, without either having to disconnect from their regular virtual world (buddy list, unified messaging, inter-office collaboration, etc). Unfortunately, that's non-scalable, particularly along the complexity axis. It works fine in your example because you have only two parties wishing to share a space and hence there is only one space to simulate, but try to extrapolate from there to see where it leads. If your organization A has N users, and those N users wish to take part in N different worlds (which is asymptotically likely if N << total number of worlds), then your organization A must now simulate N different worlds. For large N, this places a colossal load on organization A, even if the individual shared spaces are minimally populated. To coin a common phrase by analogy, you're undertaking to "simulate the Internet". ;-) What's more, very few platform optimizations will be possible since the N worlds are all different, and this also means that the scalability of each shared space will be severely constrained as well. And as if that were not bad enough, the N worlds that your users visit tomorrow will not necessarily be today's N worlds, so for (N << total number of worlds) your local cache will need to grow almost without limit if it's to work at all. Even if organization A's machinery were powerful enough to support N radically different worlds through shared-space simulations though, they still couldn't do it, because in the general case the simulation code for a given world will not be available. The world simulation is the "secret sauce" of many virtual worlds, and from a business perspective it is quite likely to be their product differentiator and they will be loathe to share it. But even if it were freely available, the portability of one organization's simulation code to another organization's machinery is far from guaranteed with today's software technology, not to mention the management of upgrades for something this complex across organization boundaries. Now contrast that shared-space architecture to today's more prevalent one. Organizations A and B(1)...B(N) design their own worlds in accordance with their particular visions, and each world is tailored to their own optimized hardware. Now in the case when the N users of organization A travel to those N different B worlds, organization A has no world simulation load for active users at all (it just sends out data to the N worlds). Instead, some number of foreign users from the B worlds will arrive and need to be supported. However, they are supported in organization A's own world simulation, which is highly optimized by design and hence carries none of the complexity/scalability problems mentioned above in the shared-space approach. Foreign world simulations never need to be supported. In the Internet-like metaverse model of unlimited and extremely diverse worlds, I really don't see the shared-space approach as being at all viable, because diversity is its enemy. In some severely constrained corporate settings it might be quite usable (and even efficient for standardized worlds), but this does not seem to be a generally scalable model for an evolving metaverse. Morgaine. --0-36906972-1235058945=:76086 Content-Type: text/html; charset=us-ascii
Dear Morgaine:

That could very well be. Shared spaces may or may not be achievable in the near term.

That sort of gets us back to figuring out what we "do" wish to accomplish.

Are we here to seek consensus and modify the already existing and deployed OGP protocol of SecondLife? Are we here to see if HyperGrid from OpenSim is appropriate for this group? Are there other protocols to consider?

So, I have to ask, as I am getting confused with all the e-mails flying around and like many, I have lots of things to concentrate on. So:

"What are we here for and what do we hope to accomplish?"

Charles

From: Morgaine <morgaine.dinova@googlemail.com>
To: Jon Watte <jwatte@gmail.com>
Cc: "mmox@ietf.org" <mmox@ietf.org>
Sent: Thursday, February 19, 2009 7:36:54 AM
Subject: Re: [mmox] User Accounts / "Object" Transfer.



On Thu, Feb 19, 2009 at 12:37 AM, Jon Watte <jwatte@gmail.com> wrote:

Let's assume organization A builds a space. Let's assume organization B builds furniture. Now, they want to have a meeting, and see how the furniture works in the space. The easiest way to accomplish this is to make organization A users log into the organization A virtual world (like they always do), and organization B users log into organization B virtual world (like they always do), and make arrangements such that some room/area/island within the two organizations is shared -- whatever comes to that space from A, also shows up in B, and vice versa. This allows A to publish its space, and B to bring the furniture to that space, without either having to disconnect from their regular virtual world (buddy list, unified messaging, inter-office collaboration, etc).

Unfortunately, that's non-scalable, particularly along the complexity axis.

It works fine in your example because you have only two parties wishing to share a space and hence there is only one space to simulate, but try to extrapolate from there to see where it leads.  If your organization A has N users, and those N users wish to take part in N different worlds (which is asymptotically likely if N << total number of worlds), then your organization A must now simulate N different worlds.  For large N, this places a colossal load on organization A, even if the individual shared spaces are minimally populated.  To coin a common phrase by analogy, you're undertaking to "simulate the Internet". ;-)

What's more, very few platform optimizations will be possible since the N worlds are all different, and this also means that the scalability of each shared space will be severely constrained as well.  And as if that were not bad enough, the N worlds that your users visit tomorrow will not necessarily be today's N worlds, so for (N << total number of worlds) your local cache will need to grow almost without limit if it's to work at all.

Even if organization A's machinery were powerful enough to support N radically different worlds through shared-space simulations though, they still couldn't do it, because in the general case the simulation code for a given world will not be available.  The world simulation is the "secret sauce" of many virtual worlds, and from a business perspective it is quite likely to be their product differentiator and they will be loathe to share it.  But even if it were freely available, the portability of one organization's simulation code to another organization's machinery is far from guaranteed with today's software technology, not to mention the management of upgrades for something this complex across organization boundaries.

Now contrast that shared-space architecture to today's more prevalent one.  Organizations A and B(1)...B(N) design their own worlds in accordance with their particular visions, and each world is tailored to their own optimized hardware.  Now in the case when the N users of organization A travel to those N different B worlds, organization A has no world simulation load for active users at all (it just sends out data to the N worlds).  Instead, some number of foreign users from the B worlds will arrive and need to be supported.  However, they are supported in organization A's own world simulation, which is highly optimized by design and hence carries none of the complexity/scalability problems mentioned above in the shared-space approach.  Foreign world simulations never need to be supported.

In the Internet-like metaverse model of unlimited and extremely diverse worlds, I really don't see the shared-space approach as being at all viable, because diversity is its enemy.  In some severely constrained corporate settings it might be quite usable (and even efficient for standardized worlds), but this does not seem to be a generally scalable model for an evolving metaverse.

Morgaine.
--0-36906972-1235058945=:76086-- From jesrad@gmail.com Thu Feb 19 08:35:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49C43A6BD9 for ; Thu, 19 Feb 2009 08:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj4GagWZ+JHQ for ; Thu, 19 Feb 2009 08:35:02 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 123EC3A6850 for ; Thu, 19 Feb 2009 08:35:01 -0800 (PST) Received: by bwz5 with SMTP id 5so1373495bwz.13 for ; Thu, 19 Feb 2009 08:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=STr5BIcHZUriRCl5eAeVT2q9LRqsVgu10WhH5EPnkk8=; b=Kz2Ck7LXZipa65ft/mR5f6sUnmvua4ZmQ5f7gimVYVc3KMrrDl1MPYSpFcfOzw8tvJ R27AJLMHYfL61tKQGhfGCeC5CoLViWnEnc4/vs4v/sb6vpAqvNbEd2dQafD38bu+Yp5Q 8dcSIxSSvMMERKisZveOG0nV/kUxcwcrfHxow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=W0Nn4qxkYbbuRCliAbp/Ekv8rbFObDIW/pr2toxJmoJgkq9/1STDehrI3VeTESIevQ pxVDUO2VMbylVFyCKnyjFqCG0tY/H0SV3j4U6kaSYnI82IbBVddGS0h0dxsXk2P+Y1h4 +uSMwS5+c+t8GV+UuyFZcbdBrMtcq1+o6MB3A= MIME-Version: 1.0 Received: by 10.180.244.19 with SMTP id r19mr2585177bkh.9.1235061314421; Thu, 19 Feb 2009 08:35:14 -0800 (PST) In-Reply-To: <647098.76086.qm@web82602.mail.mud.yahoo.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> Date: Thu, 19 Feb 2009 17:35:14 +0100 Message-ID: <53cd6c2e0902190835oa0303b3r9ba1e6598c11c20c@mail.gmail.com> From: Jesrad To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 16:35:03 -0000 > That sort of gets us back to figuring out what we "do" wish to accomplish. The way I see it, we're trying to figure out how the "language" that different VWs could use to exchange their common types of data. So first we should be figuring out what data types and features are common to the VWs/MMOGs targeted. Obvious ones (2D/3D representation, identity referal + authentication, experience/level/gold/L$ account, Then we classify these data types into a few major supertypes that each correspond to a basic grid service (can they be optional or not ?), a bit like how the Agent Domain includes IM, L$ and inventory: WoW players also have IM, gold, and inventory, and that can be considered the "WoW Agent Domain". In this way we can design containers for each supertype, seperately. The basic, universal operation of a VW (connecting the dots, see previous message) dictates the logic of the protocol, while the data types dictate the content/streams it transports. The idea is that each supertype of data may be supplied by different grids at the same time, so each shall regroup only the features and data subtypes that mandate each other: you're supposed to be able to login in your SL account then enter the OSGrid, while retaining your SL L$ balance. Tentative adoption plan: Step 1: Existing VW are expected to encapsulate their own protocols into this common grid protocol, as an additional layer on their existing protocols E.g. sending an object to the viewer becomes contained in the supertype container for "object". Step 2: Support for different data format can be added between this new layer and the existing ones, for each set of grid server + client: at this step, for example, it becomes possible to display previously unsupported 3D models, or to hear the . We'll have to figure out where the conversion is done (at the source or end-point or gateway ?) E.g. you download/buy an add-on for the SL viewer that lets it render the WoW avatar model it may receive in an "object" supertype container instead of the usual SL definition, by reading the static data it refers to. Step 3: at this point there is already basic interoperability, which can be expanded upon by switching to common format for the actual data transmitted. Specific exchanges between VWs can be set up to allow more interoperation (like an exchange between L$ and WoW gold so you can pay L$ in WoW and vice-versa). If we devise a "native" format for "common denominator" data types, step 3 would be the time where VWs switch to this native format from their previous incompatible ones. This whole proposal assumes there IS a basic, universal operation that all VWs/MMOGs do respect. On Thu, Feb 19, 2009 at 4:55 PM, Charles Krinke wrote: > Dear Morgaine: > > That could very well be. Shared spaces may or may not be achievable in the > near term. > > That sort of gets us back to figuring out what we "do" wish to accomplish. > > Are we here to seek consensus and modify the already existing and deployed > OGP protocol of SecondLife? Are we here to see if HyperGrid from OpenSim is > appropriate for this group? Are there other protocols to consider? > > So, I have to ask, as I am getting confused with all the e-mails flying > around and like many, I have lots of things to concentrate on. So: > > "What are we here for and what do we hope to accomplish?" > > Charles > > ________________________________ > From: Morgaine > To: Jon Watte > Cc: "mmox@ietf.org" > Sent: Thursday, February 19, 2009 7:36:54 AM > Subject: Re: [mmox] User Accounts / "Object" Transfer. > > > > On Thu, Feb 19, 2009 at 12:37 AM, Jon Watte wrote: >> >> Let's assume organization A builds a space. Let's assume organization B >> builds furniture. Now, they want to have a meeting, and see how the >> furniture works in the space. The easiest way to accomplish this is to make >> organization A users log into the organization A virtual world (like they >> always do), and organization B users log into organization B virtual world >> (like they always do), and make arrangements such that some room/area/island >> within the two organizations is shared -- whatever comes to that space from >> A, also shows up in B, and vice versa. This allows A to publish its space, >> and B to bring the furniture to that space, without either having to >> disconnect from their regular virtual world (buddy list, unified messaging, >> inter-office collaboration, etc). > > Unfortunately, that's non-scalable, particularly along the complexity axis. > > It works fine in your example because you have only two parties wishing to > share a space and hence there is only one space to simulate, but try to > extrapolate from there to see where it leads. If your organization A has N > users, and those N users wish to take part in N different worlds (which is > asymptotically likely if N << total number of worlds), then your > organization A must now simulate N different worlds. For large N, this > places a colossal load on organization A, even if the individual shared > spaces are minimally populated. To coin a common phrase by analogy, you're > undertaking to "simulate the Internet". ;-) > > What's more, very few platform optimizations will be possible since the N > worlds are all different, and this also means that the scalability of each > shared space will be severely constrained as well. And as if that were not > bad enough, the N worlds that your users visit tomorrow will not necessarily > be today's N worlds, so for (N << total number of worlds) your local cache > will need to grow almost without limit if it's to work at all. > > Even if organization A's machinery were powerful enough to support N > radically different worlds through shared-space simulations though, they > still couldn't do it, because in the general case the simulation code for a > given world will not be available. The world simulation is the "secret > sauce" of many virtual worlds, and from a business perspective it is quite > likely to be their product differentiator and they will be loathe to share > it. But even if it were freely available, the portability of one > organization's simulation code to another organization's machinery is far > from guaranteed with today's software technology, not to mention the > management of upgrades for something this complex across organization > boundaries. > > Now contrast that shared-space architecture to today's more prevalent one. > Organizations A and B(1)...B(N) design their own worlds in accordance with > their particular visions, and each world is tailored to their own optimized > hardware. Now in the case when the N users of organization A travel to > those N different B worlds, organization A has no world simulation load for > active users at all (it just sends out data to the N worlds). Instead, some > number of foreign users from the B worlds will arrive and need to be > supported. However, they are supported in organization A's own world > simulation, which is highly optimized by design and hence carries none of > the complexity/scalability problems mentioned above in the shared-space > approach. Foreign world simulations never need to be supported. > > In the Internet-like metaverse model of unlimited and extremely diverse > worlds, I really don't see the shared-space approach as being at all viable, > because diversity is its enemy. In some severely constrained corporate > settings it might be quite usable (and even efficient for standardized > worlds), but this does not seem to be a generally scalable model for an > evolving metaverse. > > Morgaine. > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From tme@multicasttech.com Thu Feb 19 09:02:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB9203A6B0A for ; Thu, 19 Feb 2009 09:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.557 X-Spam-Level: X-Spam-Status: No, score=-103.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRYkaUZI9i9t for ; Thu, 19 Feb 2009 09:02:27 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id A8ED63A6BFC for ; Thu, 19 Feb 2009 09:02:27 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14709570; Thu, 19 Feb 2009 12:00:58 -0500 Message-Id: <0183ADE5-AF9D-4552-8146-4D9C7858B37F@multicasttech.com> From: Marshall Eubanks To: Dave Coyle In-Reply-To: <20090219125626.GB1721@frog.knifejaw.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 12:02:39 -0500 References: <499CC99D.8040302@cox.net> <5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com> <6A5E83A8-A7A1-4D38-8FAC-C04E360E4777@lindenlab.com> <20090219125626.GB1721@frog.knifejaw.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] meeting minutes from today's ietf mmox simulcasting meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 17:02:31 -0000 I have asked for mmox@jabber.ietf.org to be created. Regards Marshall On Feb 19, 2009, at 7:56 AM, Dave Coyle wrote: > On 2009-02-18 23:45:45 -0500, infinity@lindenlab.com wrote: >> * is the use of mmox@jabber.ietf.org required? several mac users >> have noted difficulty in using it. > > That's because the room hasn't been created yet. :) Try > test@jabber.ietf.org ... that works, mmox doesn't. > > -Coyle > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Thu Feb 19 09:06:43 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370413A6AB1 for ; Thu, 19 Feb 2009 09:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLE4imZ4qlwO for ; Thu, 19 Feb 2009 09:06:39 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 6D9B53A67FA for ; Thu, 19 Feb 2009 09:06:39 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 976ED3DBC45A; Thu, 19 Feb 2009 09:06:52 -0800 (PST) Message-Id: <2A3D6CCD-58D1-4A01-9450-816839F05A4E@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Morgaine In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2--942029319 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 09:06:48 -0800 References: <499CC99D.8040302@cox.net> <5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com> <6A5E83A8-A7A1-4D38-8FAC-C04E360E4777@lindenlab.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] meeting minutes from today's ietf mmox simulcasting meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 17:06:43 -0000 --Apple-Mail-2--942029319 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit hmm... what client were you using? colloquy seems to have problems with both test@jabber.ietf.org as well as other jabber servers. and can you change the mmox wiki page you made to not reference mmox@jabber.ietf.org ? thx On Feb 19, 2009, at 5:38 AM, Morgaine wrote: > Excellent summary of a complex meeting, thanks Infinity. :-) > > On Thu, Feb 19, 2009 at 4:45 AM, Meadhbh Hamrick (Infinity) > wrote: > > * is the use of mmox@jabber.ietf.org required? several mac users > have noted difficulty in using it. > > I'll echo Dave's reply that jabber.ietf.org is working fine. Some > of us were in there together last night for tests in the "test" > room. The "mmox" room hasn't yet been set up or enabled, but no > doubt our AD can fix that. > > Looking at the Jabber room logs at http://jabber.ietf.org/logs/, > it's worth noting that this facility is in use by many workgroups, > well over a dozen since the start of the year. I think that it > would serve MMOX well too, both during the forthcoming special > meetings and subsequently when more interactive discussion is needed > than email allows. > > Morgaine. > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-2--942029319 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hmm... what client were you = using? colloquy seems to have problems with both test@jabber.ietf.org as well as = other jabber servers.

and can you change the mmox = wiki page you made to not reference mmox@jabber.ietf.org = ?

thx

On Feb 19, 2009, = at 5:38 AM, Morgaine wrote:

Excellent = summary of a complex meeting, thanks Infinity. :-)

On Thu, Feb 19, 2009 at 4:45 AM, Meadhbh Hamrick = (Infinity) <infinity@lindenlab.com> = wrote:
 
  * is the use of mmox@jabber.ietf.org required? several mac users = have noted difficulty in using it.

I'll echo = Dave's reply that jabber.ietf.org = is working fine.  Some of us were in there together last night for = tests in the "test" room.  The "mmox" room hasn't yet been set up = or enabled, but no doubt our AD can fix that.

Looking at the = Jabber room logs at http://jabber.ietf.org/logs/, = it's worth noting that this facility is in use by many workgroups, well = over a dozen since the start of the year.  I think that it would = serve MMOX well too, both during the forthcoming special meetings and = subsequently when more interactive discussion is needed than email = allows.

Morgaine.
= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mmox

= --Apple-Mail-2--942029319-- From john.hurliman@intel.com Thu Feb 19 09:28:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B87EF3A6AB1 for ; Thu, 19 Feb 2009 09:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCmGhz4CGJkm for ; Thu, 19 Feb 2009 09:28:43 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id A99DE3A67F7 for ; Thu, 19 Feb 2009 09:28:42 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 19 Feb 2009 09:21:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,236,1233561600"; d="scan'208";a="388169758" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga002.jf.intel.com with ESMTP; 19 Feb 2009 09:37:43 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Thu, 19 Feb 2009 10:28:55 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Thu, 19 Feb 2009 10:28:52 -0700 Thread-Topic: [mmox] The Story So Far... Thread-Index: AcmSVnmXssgLX5oATe+nKIGn1gAqqAAX+eEg Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FE739@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> <499CF3F7.1010304@gmail.com> In-Reply-To: <499CF3F7.1010304@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 17:28:44 -0000 >-----Original Message----- >From: Jon Watte [mailto:jwatte@gmail.com] >Sent: Wednesday, February 18, 2009 9:54 PM >To: Hurliman, John >Cc: mmox@ietf.org >Subject: Re: [mmox] The Story So Far... > >Hurliman, John wrote: >> include anything like that. Instead, a teleport is done from grid A to >grid B where identity and appearance are the only things that need to >persist. I don't see why grid<->grid communication is fundamentally >necessary to transfer identity and appearance. >> > >At least three reasons: > >1) When I am logged into a virtual world, it's usually for a reason. For >me, it's work -- my virtual world allows me to cooperate with remote >workers, visualize 3D data, and have meetings that are more effective >and cheaper than conference calls. (Customers love "cheaper" :-) If I >were to log off my "home" virtual world, then I would lose some or all >of those capabilities while I "went elsewhere." For example, if my >company has a policy of recording all interactions in the world, for >regulatory compliance, if I suddenly disconnected and connected to >another grid, that function would not be present. > I visit my internal homepage at intel.com and browse several other parts of= the web at the same time. It doesn't require any established trust between= intel.com and the rest of the web. >2) Object behavior is not portable. One system may use SecondLife Script >version 2.3 for its objects. Another may use Java Runtime 1.5.6. A third >may use Visual C++ 9.0 linkable libraries. > Just as some websites are powered with PHP, some use Java backends, and som= e have bits written in C++? >3) If you "grid hop" to another location, you have to have a client that >can connect to whatever server protocol that location is using. Writing >a "universal client" has proven to be quite quixotic for two reasons: a) >Any real system will have to have a "home protocol" anyway to provide >functionality not provided for in the standard, and b) re-implementing >virtual world presence for a client as a separate channel only to use >for interoperability isn't a good idea. > I agree that the universal client solution is not an answer to interoperabi= lity. However, this seems to just be pushing the problem back to the server= . Instead of a universal client we'll have a universal server that can do u= niversal protocol translation. What if this universal server was ran on loc= alhost? Would it become a universal client? > >If I "grid hop," I might as well just have two clients installed (one >that uses ClosedGardenWorld protocol 1.3, and one which uses >WalledSpacesWorld protocol 2.7), and launch the right client for where I >want to go -- the "benefit" of interoperability would be quite marginal; >basically just not having to fill out a registration form for each >world. No business will do a lot of engineering work to enable a >scenario like that, because it delivers very little added value. > >Sincerely, > >jw I think it's arguable whether merging the view of two worlds together has h= igher value than teleporting presence and content between worlds. John From morgaine.dinova@googlemail.com Thu Feb 19 10:09:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA723A68C8 for ; Thu, 19 Feb 2009 10:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3IvM08IoTyY for ; Thu, 19 Feb 2009 10:09:29 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 21F9D3A6A25 for ; Thu, 19 Feb 2009 10:09:28 -0800 (PST) Received: by bwz5 with SMTP id 5so1505172bwz.13 for ; Thu, 19 Feb 2009 10:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ziy6x10bwqHG4kE3KeUaPHa1oq0RMH4t0IuakKzZX2k=; b=gAJHT1SKRKcZXLdVos0FyIpUAzL3UpNdChP4eyV6fvXMre9eTmUbo1lfZ0FagCOTGD BUaK48QH6vYrpN11xVHMFIdPQn3LCt5hmX8pux7zM3NkQlhDmUVY5IyNqj9lXB2rYrj/ NyiIc/bSYomPk1LNOVD5TJ6tcTBXsY6BpGcpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BOQF2WSbIOLGW7mGVsyNI24oCtHU/Fs5CxyCDc3ETwcMSLcmOX1Ci7cx9KwlJU+NAD Xi5iAv91UqGTzAFXduB1zGXvGkVcf3R2d7zT5CQ8wmy9+GjPJgO0GErp+wcCekYHjPnm RjuCIKentgqj4gAmBvZTysXFaGv77eAKQs9fk= MIME-Version: 1.0 Received: by 10.181.199.16 with SMTP id b16mr3289420bkq.142.1235066981429; Thu, 19 Feb 2009 10:09:41 -0800 (PST) In-Reply-To: References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> Date: Thu, 19 Feb 2009 18:09:41 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=0016e6d59d1db3b41604634970a5 Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 18:09:31 -0000 --0016e6d59d1db3b41604634970a5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jon, after reading your other posts, I think that you may have been referring to your "shared-spaces" idea when you questioned the value of "teleport between grids", as I can't see any other architecture being discussed. However, if that's the case then I don't understand the point being made, because shared-spaces seems to be a "teleport only" architecture. The only means by which a user can go from one shared space to another is by teleport, since shared spaces do not have topological relationships to each other, from your description. If you ignore the local simulation for a moment, then what happens when one of your users changes from one local shared space to one belonging to a different provider is very similar in implementation to the usual separate worlds case: the agent appears in the space at the remote end. Adding a local simulation on top of that doesn't really change the matter. That's teleport between grids, plus a local accelerator. And perceptually from the users' perspective, the model suggests that they too see a teleport occurring every time that they change their shared space to one operated by a different world provider. This looks like perfectly ordinary "teleport between grids" to them too. Morgaine. On Thu, Feb 19, 2009 at 7:39 AM, Morgaine wrote: > > > On Wed, Feb 18, 2009 at 9:37 PM, Jon Watte wrote: > >> What end-user value does "teleport between grids" solve? >> >> In my opinion, that feature is very un-interesting, as it requires lots of >> engineering, and gives very little value, compared to lower-hanging fruit >> like physical spaces shared across interoperating servers. >> >> After perception of the world around you, travel is the next most > important form of interaction with the world. Teleport is simply > instantaneous travel, and teleport between grids is simply instantaneous > travel between worlds in different organizational domains. How can it > possibly be uninteresting and give little value to travel to distant places > in virtual space? ;-) > > I expect that you meant something *completely* different to the above. > :-) Are we hitting an ambiguity in terminology of some kind here? > > Morgaine. > --0016e6d59d1db3b41604634970a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jon, after reading your other posts, I think that you may have been referri= ng to your "shared-spaces" idea when you questioned the value of = "teleport between grids", as I can't see any other architectu= re being discussed.

However, if that's the case then I don't understand the point b= eing made, because shared-spaces seems to be a "teleport only" ar= chitecture.  The only means by which a user can go from one shared spa= ce to another is by teleport, since shared spaces do not have topological r= elationships to each other, from your description.

If you ignore the local simulation for a moment, then what happens when= one of your users changes from one local shared space to one belonging to = a different provider is very similar in implementation to the usual separat= e worlds case:  the agent appears in the space at the remote end. = ;  Adding a local simulation on top of that doesn't really change = the matter.  That's teleport between grids, plus a local accelerat= or.

And perceptually from the users' perspective, the model suggests th= at they too see a teleport occurring every time that they change their shar= ed space to one operated by a different world provider.  This looks li= ke perfectly ordinary "teleport between grids" to them too.

Morgaine.




On Thu, Feb 19,= 2009 at 7:39 AM, Morgaine <morgaine.dinova@googlemail.com> wrote= :


On Wed, Feb 18, 2009 at 9:37 PM, Jo= n Watte <jwatte@gmail.com> wrote:
What end-user value does "teleport between grids" solve?

In my opinion, that feature is very un-interesting, as it requires lots of = engineering, and gives very little value, compared to lower-hanging fruit l= ike physical spaces shared across interoperating servers.

After perception of the world around you, trav= el is the next most important form of interaction with the world.  Tel= eport is simply instantaneous travel, and teleport between grids is simply = instantaneous travel between worlds in different organizational domains.&nb= sp; How can it possibly be uninteresting and give little value to travel to= distant places in virtual space?  ;-)

I expect that you meant something completely different to the ab= ove.  :-)   Are we hitting an ambiguity in terminology of some ki= nd here?

Morgaine.

--0016e6d59d1db3b41604634970a5-- From cfk@pacbell.net Thu Feb 19 10:26:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D9A3A6A25 for ; Thu, 19 Feb 2009 10:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfaNk6UmYS35 for ; Thu, 19 Feb 2009 10:26:20 -0800 (PST) Received: from web82606.mail.mud.yahoo.com (web82606.mail.mud.yahoo.com [68.142.201.123]) by core3.amsl.com (Postfix) with SMTP id 81DD63A6915 for ; Thu, 19 Feb 2009 10:26:20 -0800 (PST) Received: (qmail 43793 invoked by uid 60001); 19 Feb 2009 18:26:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=Ih4aJbqWd5x6sxfxpHEr0BKkfHhkwtyICLApm6hl7jXVVMuQ4S9PSoyaypS4Rx3JtiVVUiFiOzo93YD5xKv6fK65yjxWifRE3MqZUQrBmxZpqIZIzjc3nXnREoyF8YQKWcn51Lfr//J1ErjaQ0C9jp0sATZFboEHdGi6qkQKlFE=; X-YMail-OSG: 7T5gAwgVM1mt_1oX.sTseYFFo71F1VOZUIXfylK.14sF6FMKbKpDEStsN5sFdMY86p6ZlEbdnIseXdr1t7xARshsoq_ypLgqW3vWf7L9XaP07BqhC5TSUJHY3B._plRwwmBaXr0o8_0T8dtEJIpFAz7hnUOhANvF7toAPuJ60x8de_jO6LFtIuXGl76SjzqyukTAhng41uplqVdXxvp9yt5XO3w- Received: from [75.217.195.74] by web82606.mail.mud.yahoo.com via HTTP; Thu, 19 Feb 2009 10:26:32 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> Date: Thu, 19 Feb 2009 10:26:32 -0800 (PST) From: Charles Krinke To: Morgaine , Jon Watte MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-393028015-1235067992=:37604" Message-ID: <186624.37604.qm@web82606.mail.mud.yahoo.com> Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 18:26:21 -0000 --0-393028015-1235067992=:37604 Content-Type: text/plain; charset=us-ascii Both good points, JHurliman and Morgaine. I think the punch line is we are not talking about a theoretical implementation that might be, but rather a practical implementation that is already deployed and in use by thousands of folks and this deployment is growing every day. We are concerned with whether the avatar landing manifests as a cloud of fog, an amorphous gray character, an ANPC, a Ruth or even a tourist with a camera about its neck. We are also concerned with ensuring that the first person and various third person scenes are consistent with each other. Getting the teleport presence consistent between virtual worlds is a moving target as various groups work seperately and then interface occaisionally. And getting this teleport prescence consistent is the pre-requisite to then having attachments, scripts, huds, AO, inventory and other features work functional in cross-world teleporting, or as some folks say 'Interop'. Charles ________________________________ From: Morgaine To: Jon Watte Cc: mmox@ietf.org Sent: Thursday, February 19, 2009 10:09:41 AM Subject: Re: [mmox] User Accounts / "Object" Transfer. Jon, after reading your other posts, I think that you may have been referring to your "shared-spaces" idea when you questioned the value of "teleport between grids", as I can't see any other architecture being discussed. However, if that's the case then I don't understand the point being made, because shared-spaces seems to be a "teleport only" architecture. The only means by which a user can go from one shared space to another is by teleport, since shared spaces do not have topological relationships to each other, from your description. If you ignore the local simulation for a moment, then what happens when one of your users changes from one local shared space to one belonging to a different provider is very similar in implementation to the usual separate worlds case: the agent appears in the space at the remote end. Adding a local simulation on top of that doesn't really change the matter. That's teleport between grids, plus a local accelerator. And perceptually from the users' perspective, the model suggests that they too see a teleport occurring every time that they change their shared space to one operated by a different world provider. This looks like perfectly ordinary "teleport between grids" to them too. Morgaine. On Thu, Feb 19, 2009 at 7:39 AM, Morgaine wrote: On Wed, Feb 18, 2009 at 9:37 PM, Jon Watte wrote: What end-user value does "teleport between grids" solve? In my opinion, that feature is very un-interesting, as it requires lots of engineering, and gives very little value, compared to lower-hanging fruit like physical spaces shared across interoperating servers. After perception of the world around you, travel is the next most important form of interaction with the world. Teleport is simply instantaneous travel, and teleport between grids is simply instantaneous travel between worlds in different organizational domains. How can it possibly be uninteresting and give little value to travel to distant places in virtual space? ;-) I expect that you meant something completely different to the above. :-) Are we hitting an ambiguity in terminology of some kind here? Morgaine. --0-393028015-1235067992=:37604 Content-Type: text/html; charset=us-ascii

Both good points, JHurliman and Morgaine.

I think the punch line is we are not talking about a theoretical implementation that might be, but rather a practical implementation that is already deployed and in use by thousands of folks and this deployment is growing every day.

We are concerned with whether the avatar landing manifests as a cloud of fog, an amorphous gray character, an ANPC, a Ruth or even a tourist with a camera about its neck. We are also concerned with ensuring that the first person and various third person scenes are consistent with each other.

Getting the teleport presence consistent between virtual worlds is a moving target as various groups work seperately and then interface occaisionally. And getting this teleport prescence consistent is the pre-requisite to then having attachments, scripts, huds, AO, inventory and other features work functional in cross-world teleporting, or as some folks say 'Interop'.

Charles



From: Morgaine <morgaine.dinova@googlemail.com>
To: Jon Watte <jwatte@gmail.com>
Cc: mmox@ietf.org
Sent: Thursday, February 19, 2009 10:09:41 AM
Subject: Re: [mmox] User Accounts / "Object" Transfer.

Jon, after reading your other posts, I think that you may have been referring to your "shared-spaces" idea when you questioned the value of "teleport between grids", as I can't see any other architecture being discussed.

However, if that's the case then I don't understand the point being made, because shared-spaces seems to be a "teleport only" architecture.  The only means by which a user can go from one shared space to another is by teleport, since shared spaces do not have topological relationships to each other, from your description.

If you ignore the local simulation for a moment, then what happens when one of your users changes from one local shared space to one belonging to a different provider is very similar in implementation to the usual separate worlds case:  the agent appears in the space at the remote end.   Adding a local simulation on top of that doesn't really change the matter.  That's teleport between grids, plus a local accelerator.

And perceptually from the users' perspective, the model suggests that they too see a teleport occurring every time that they change their shared space to one operated by a different world provider.  This looks like perfectly ordinary "teleport between grids" to them too.

Morgaine.




On Thu, Feb 19, 2009 at 7:39 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:


On Wed, Feb 18, 2009 at 9:37 PM, Jon Watte <jwatte@gmail.com> wrote:
What end-user value does "teleport between grids" solve?

In my opinion, that feature is very un-interesting, as it requires lots of engineering, and gives very little value, compared to lower-hanging fruit like physical spaces shared across interoperating servers.

After perception of the world around you, travel is the next most important form of interaction with the world.  Teleport is simply instantaneous travel, and teleport between grids is simply instantaneous travel between worlds in different organizational domains.  How can it possibly be uninteresting and give little value to travel to distant places in virtual space?  ;-)

I expect that you meant something completely different to the above.  :-)   Are we hitting an ambiguity in terminology of some kind here?

Morgaine.

--0-393028015-1235067992=:37604-- From mccahill@duke.edu Thu Feb 19 10:26:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E135C3A6AFF for ; Thu, 19 Feb 2009 10:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nG0aa-f7062 for ; Thu, 19 Feb 2009 10:26:40 -0800 (PST) Received: from smtp.duke.edu (smtp-02.oit.duke.edu [152.3.174.84]) by core3.amsl.com (Postfix) with ESMTP id 86E003A6915 for ; Thu, 19 Feb 2009 10:26:40 -0800 (PST) Received: from smtp.duke.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4647451121A for ; Thu, 19 Feb 2009 13:26:53 -0500 (EST) Received: from dyn-152-3-124-53.oit.duke.edu (dyn-152-3-124-53.oit.duke.edu [152.3.124.53]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.duke.edu (Postfix) with ESMTP id 063465109EB for ; Thu, 19 Feb 2009 13:26:53 -0500 (EST) Message-Id: <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> From: Mark P. McCahill To: mmox@ietf.org In-Reply-To: <499CA916.1090008@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 13:26:51 -0500 References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> X-Mailer: Apple Mail (2.930.3) X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2009.2.19.181319 Subject: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 18:26:42 -0000 These worlds are fundamentally social environments. I would suggest starting with interoperability for federated identity and presence. At a minimum I want to know which worlds my buddies are currently playing in, and be able to chat with them, and be able to chat with people outside the virtual worlds. If there are any ambitions toward integrating presence in virtual worlds with more traditional audio, video, and text communications, then SIP and XMPP-based presence would be worth considering rather than re-inventing these functions. Most virtual worlds act as both metaverse service providers (MSP) and identity providers. This is a mistake. Tightly coupling the MSP and identity provider functions is why I have to keep telling people that Mark McCahill is named Mysterio Sinister in Second Life - I can't easily be mccahill@duke.edu because Second Life doesn't use external federated identity providers. Then when I go to one of the OpenSim worlds, I need to create another account, and hope that nobody has signed up for Mysterio Sinister before I got there. Requiring avatars to create a new account/password at each of the different metaverse service providers is not a very appealing prospect. Why aren't we addressing the federated identity/presence issue now? There are a number of existing approaches that could be relatively easily adopted across different technologies and set the stage for deeper interoperability down the road. To make any real progress, we need agreement about standards for accepting identities provided by other virtual worlds. Even better, how about something that is not a virtual world (OAuth, OpenID, Shibboleth all come to mind) an option as an identity provider? Solving this problem is a prerequisite for making any real progress toward allowing free movement across worlds. Why aren't we talking about standards for name@identity_provider authentication which could be used across worlds? Mark McCahill OpenCroquet/Cobalt On Feb 18, 2009, at 7:34 PM, Jon Watte wrote: > > So, what is an avatar anyway? I think it has one or more meshes > (that are not standard), draped over a skeleton (that is not > standard), with one or more textures applied (that are not > standard). Avatars also represent users, which have identity. > Avatars can move (physically, with collision detection), animate > (interactions, emotes), voice communicate and text chat. > > If you can send that information ([identity, mesh, texture, > skeleton] as set-up, and [movement, animation, interactions, voice > and text chat] at runtime) then do you have an interoperable avatar? > And, if so, what separates an avatar from another animated, movable > object? Could the same way that avatars are interoperating be used > to interoperate other simulated objects? From a remote systems' > point of view, there's not that much difference between a human- > driven avatar, and a tumbling rock -- the remote system can't be > expected to run the simulation for either one, so it needs to have > that stream of behavior to represent it. > > As far as I know Wonderland, Qwaq, Multiverse and other possible > adopters, the above representations maps fairly straightforward to > their systems, although any system will have to expect to write > adaption code to accept "arbitrary" external meshes as avatars. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From morgaine.dinova@googlemail.com Thu Feb 19 10:34:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4023A6ABF for ; Thu, 19 Feb 2009 10:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWfOeOk0x7Qk for ; Thu, 19 Feb 2009 10:34:22 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id C3F983A68A6 for ; Thu, 19 Feb 2009 10:34:18 -0800 (PST) Received: by bwz5 with SMTP id 5so1535572bwz.13 for ; Thu, 19 Feb 2009 10:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WQaldo79IzIA8PLqtkjZ4A3LlDYg4eCDFbwfZMroQuc=; b=qWj/veHOaXENZfs7rqASEJLMHk8J9svnDS+NPpgy+2QZsKam+TgFkBj5U2SA7MFt7G gFCxAtaSvnyBaaThP8AqClurRPyrftr/3hLLuOscUswkPMBuIorTFGJKyOJHQVDAKBXx EGiaO/tGlBZT5rbBrEPxHogBGqEwW65UEBEkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XxZXUWQvA51bHHjVi2LYXyg/iapcfKOLMy1P4Xj/9iVFsCg8buqZedb6ISMNITbPuJ N6xTMt841iX92O1jQ3AGRNikQ/ImnX+Uh0MhsbzQX25Sv7bTqgcWlxH+agJtvTQAfqN5 WKMskUZnzigjyYJDOujoXCciYkxJ1TNbrMhJw= MIME-Version: 1.0 Received: by 10.180.222.14 with SMTP id u14mr752160bkg.141.1235068470132; Thu, 19 Feb 2009 10:34:30 -0800 (PST) In-Reply-To: <0183ADE5-AF9D-4552-8146-4D9C7858B37F@multicasttech.com> References: <499CC99D.8040302@cox.net> <5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com> <6A5E83A8-A7A1-4D38-8FAC-C04E360E4777@lindenlab.com> <20090219125626.GB1721@frog.knifejaw.com> <0183ADE5-AF9D-4552-8146-4D9C7858B37F@multicasttech.com> Date: Thu, 19 Feb 2009 18:34:30 +0000 Message-ID: From: Morgaine To: Marshall Eubanks Content-Type: multipart/alternative; boundary=001636c924576f8183046349c998 Cc: mmox@ietf.org Subject: Re: [mmox] meeting minutes from today's ietf mmox simulcasting meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 18:34:22 -0000 --001636c924576f8183046349c998 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 19, 2009 at 5:02 PM, Marshall Eubanks wrote: > I have asked for mmox@jabber.ietf.org to be created. > Wow, fast work, it's been created already! Thanks Marshall, and whoever turned the switch. :-) Morgaine. --001636c924576f8183046349c998 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 19, 2009 at 5:02 PM, Marshal= l Eubanks <tm= e@multicasttech.com> wrote:
I have asked for = mmox@jabber.ietf.org to be created.


Wow, fast work, it's been created already!
Thanks Marshall, and whoever turned the switch. :-)

Morgaine. <= br>

--001636c924576f8183046349c998-- From john.hurliman@intel.com Thu Feb 19 10:49:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CCA23A6801 for ; Thu, 19 Feb 2009 10:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.005 X-Spam-Level: X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYj-iw-WbwA8 for ; Thu, 19 Feb 2009 10:49:28 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 13EB23A691D for ; Thu, 19 Feb 2009 10:49:28 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 19 Feb 2009 10:47:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,236,1233561600"; d="scan'208";a="666922709" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga001.fm.intel.com with ESMTP; 19 Feb 2009 10:53:34 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Thu, 19 Feb 2009 11:49:41 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Thu, 19 Feb 2009 11:49:20 -0700 Thread-Topic: [mmox] where is identity @ in all this? Thread-Index: AcmSv6hS5CXp9uWJQ5KlwkJryBdxjAAArslA Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FE800@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> In-Reply-To: <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 18:49:29 -0000 That is the identity proposal I'm working on. OpenID + OpenID Token Exchang= e* + OpenID Attribute Exchange =3D=3D VW Identity Service. * OAuth was specifically designed for a three legged scenario, and when you= start adding in more services such as content, messaging, voice, etc. it n= o longer becomes feasible. OpenID Token Exchange solves this problem nicely= though. John >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Mark P.McCahill >Sent: Thursday, February 19, 2009 10:27 AM >To: mmox@ietf.org >Subject: [mmox] where is identity @ in all this? > >These worlds are fundamentally social environments. I would suggest >starting with interoperability for federated identity and presence. > >At a minimum I want to know which worlds my buddies are currently >playing in, and be able to chat with them, and be able to chat with >people outside the virtual worlds. If there are any ambitions toward >integrating presence in virtual worlds with more traditional audio, >video, and text communications, then SIP and XMPP-based presence would >be worth considering rather than re-inventing these functions. > >Most virtual worlds act as both metaverse service providers (MSP) and >identity providers. This is a mistake. > >Tightly coupling the MSP and identity provider functions is why I have >to keep telling people that Mark McCahill is named Mysterio Sinister >in Second Life - I can't easily be mccahill@duke.edu because Second >Life doesn't use external federated identity providers. Then when I go >to one of the OpenSim worlds, I need to create another account, and >hope that nobody has signed up for Mysterio Sinister before I got there. > >Requiring avatars to create a new account/password at each of the >different metaverse service providers is not a very appealing >prospect. Why aren't we addressing the federated identity/presence >issue now? There are a number of existing approaches that could be >relatively easily adopted across different technologies and set the >stage for deeper interoperability down the road. > >To make any real progress, we need agreement about standards for >accepting identities provided by other virtual worlds. Even better, >how about something that is not a virtual world (OAuth, OpenID, >Shibboleth all come to mind) an option as an identity provider? >Solving this problem is a prerequisite for making any real progress >toward allowing free movement across worlds. > >Why aren't we talking about standards for > > name@identity_provider > >authentication which could be used across worlds? > > > >Mark McCahill >OpenCroquet/Cobalt > > >On Feb 18, 2009, at 7:34 PM, Jon Watte wrote: >> >> So, what is an avatar anyway? I think it has one or more meshes >> (that are not standard), draped over a skeleton (that is not >> standard), with one or more textures applied (that are not >> standard). Avatars also represent users, which have identity. >> Avatars can move (physically, with collision detection), animate >> (interactions, emotes), voice communicate and text chat. >> >> If you can send that information ([identity, mesh, texture, >> skeleton] as set-up, and [movement, animation, interactions, voice >> and text chat] at runtime) then do you have an interoperable avatar? >> And, if so, what separates an avatar from another animated, movable >> object? Could the same way that avatars are interoperating be used >> to interoperate other simulated objects? From a remote systems' >> point of view, there's not that much difference between a human- >> driven avatar, and a tumbling rock -- the remote system can't be >> expected to run the simulation for either one, so it needs to have >> that stream of behavior to represent it. >> >> As far as I know Wonderland, Qwaq, Multiverse and other possible >> adopters, the above representations maps fairly straightforward to >> their systems, although any system will have to expect to write >> adaption code to accept "arbitrary" external meshes as avatars. >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > >_______________________________________________ >mmox mailing list >mmox@ietf.org >https://www.ietf.org/mailman/listinfo/mmox >=20 From cfk@pacbell.net Thu Feb 19 10:52:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278663A69E3 for ; Thu, 19 Feb 2009 10:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1QRyWUagvCW for ; Thu, 19 Feb 2009 10:52:33 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id AB9F23A691D for ; Thu, 19 Feb 2009 10:52:33 -0800 (PST) Received: (qmail 36041 invoked by uid 60001); 19 Feb 2009 18:52:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=AV//4yHwpRFcM/LzH3pWwNewNeMhhCLB5sW/zHXaj3bROGKTHgvNLXw1hZc09DqBP3B9u484uqIO2ypxILnG5vKf1nHUVw2hM9DlMQyyM6NCa8d+pMrnzC/a56X2HyKwWtpzgmZzFnacU631cXKKQkMwpiQ/d1baT2ZAGoeUAAE=; X-YMail-OSG: uDr2ldEVM1k6Cu3opnt4acOnk0s8osc3j9.ymc4Lam8bqUIXffwpOgfuNwTui2MP3.IczGsYYQQep.Bihxw7gbzmavoKa7lcmJxQmCC0FQKDArW_g51DQ3azz.T4_7ND0oYdqq5gXtm5o2eLWrd1ZFQEqVLg4sV01i.PI05AhiYfZ8Y.FBPwZZm7eXLzdPryOrzEcdEaMzIlh2PpgfEGSm_nC4s- Received: from [75.217.195.74] by web82602.mail.mud.yahoo.com via HTTP; Thu, 19 Feb 2009 10:52:46 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> Date: Thu, 19 Feb 2009 10:52:46 -0800 (PST) From: Charles Krinke To: "Mark P. McCahill" , mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1643646255-1235069566=:34293" Message-ID: <747254.34293.qm@web82602.mail.mud.yahoo.com> Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 18:52:35 -0000 --0-1643646255-1235069566=:34293 Content-Type: text/plain; charset=us-ascii Dear Mark: Yes, that is a place where we can make progress. I am in fact "Charles Krinke" on OSGrid, but I needed to be "Charlesk Bing" on SecondLife due to the rules of that particular grid. I have a gmail account, as many other folks to and thus I believe I already have an OpenID, so using OpenID is not unreasonable. I would personally suggest that we recommend at least two different authentication methods so as not to paint ourselves into a corner down the road a bit. Charles Krinke p.s. I would love to hear more about Croquet and how we can find ways to interop and teleport between SecondLife, OpenSim and Croquet. ________________________________ From: Mark P. McCahill To: mmox@ietf.org Sent: Thursday, February 19, 2009 10:26:51 AM Subject: [mmox] where is identity @ in all this? These worlds are fundamentally social environments. I would suggest starting with interoperability for federated identity and presence. At a minimum I want to know which worlds my buddies are currently playing in, and be able to chat with them, and be able to chat with people outside the virtual worlds. If there are any ambitions toward integrating presence in virtual worlds with more traditional audio, video, and text communications, then SIP and XMPP-based presence would be worth considering rather than re-inventing these functions. Most virtual worlds act as both metaverse service providers (MSP) and identity providers. This is a mistake. Tightly coupling the MSP and identity provider functions is why I have to keep telling people that Mark McCahill is named Mysterio Sinister in Second Life - I can't easily be mccahill@duke.edu because Second Life doesn't use external federated identity providers. Then when I go to one of the OpenSim worlds, I need to create another account, and hope that nobody has signed up for Mysterio Sinister before I got there. Requiring avatars to create a new account/password at each of the different metaverse service providers is not a very appealing prospect. Why aren't we addressing the federated identity/presence issue now? There are a number of existing approaches that could be relatively easily adopted across different technologies and set the stage for deeper interoperability down the road. To make any real progress, we need agreement about standards for accepting identities provided by other virtual worlds. Even better, how about something that is not a virtual world (OAuth, OpenID, Shibboleth all come to mind) an option as an identity provider? Solving this problem is a prerequisite for making any real progress toward allowing free movement across worlds. Why aren't we talking about standards for name@identity_provider authentication which could be used across worlds? Mark McCahill OpenCroquet/Cobalt On Feb 18, 2009, at 7:34 PM, Jon Watte wrote: > > So, what is an avatar anyway? I think it has one or more meshes (that are not standard), draped over a skeleton (that is not standard), with one or more textures applied (that are not standard). Avatars also represent users, which have identity. Avatars can move (physically, with collision detection), animate (interactions, emotes), voice communicate and text chat. > > If you can send that information ([identity, mesh, texture, skeleton] as set-up, and [movement, animation, interactions, voice and text chat] at runtime) then do you have an interoperable avatar? > And, if so, what separates an avatar from another animated, movable object? Could the same way that avatars are interoperating be used to interoperate other simulated objects? From a remote systems' point of view, there's not that much difference between a human-driven avatar, and a tumbling rock -- the remote system can't be expected to run the simulation for either one, so it needs to have that stream of behavior to represent it. > > As far as I know Wonderland, Qwaq, Multiverse and other possible adopters, the above representations maps fairly straightforward to their systems, although any system will have to expect to write adaption code to accept "arbitrary" external meshes as avatars. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-1643646255-1235069566=:34293 Content-Type: text/html; charset=us-ascii

Dear Mark:

Yes, that is a place where we can make progress. I am in fact "Charles Krinke" on OSGrid, but I needed to be "Charlesk Bing" on SecondLife due to the  rules of that particular grid.

I have a gmail account, as many other folks to and thus I believe I already have an OpenID, so using OpenID is not unreasonable.

I would personally suggest that we recommend at least two different authentication methods so as not to paint ourselves into a corner down the road a bit.

Charles Krinke

p.s. I would love to hear more about Croquet and how we can find ways to interop and teleport between SecondLife, OpenSim and Croquet.


From: Mark P. McCahill <mccahill@duke.edu>
To: mmox@ietf.org
Sent: Thursday, February 19, 2009 10:26:51 AM
Subject: [mmox] where is identity @ in all this?

These worlds are fundamentally social environments. I would suggest starting with interoperability for federated identity and presence.

At a minimum I want to know which worlds my buddies are currently playing in, and be able to chat with them, and be able to chat with people outside the virtual worlds. If there are any ambitions toward integrating presence in virtual worlds with more traditional audio, video, and text communications, then SIP and XMPP-based presence would be worth considering rather than re-inventing these functions.

Most virtual worlds act as both metaverse service providers (MSP) and identity providers. This is a mistake.

Tightly coupling the MSP and identity provider functions is why I have to keep telling people that Mark McCahill is named Mysterio Sinister in Second Life - I can't easily be mccahill@duke.edu because Second Life doesn't use external federated identity providers. Then when I go to one of the OpenSim worlds, I need to create another account, and hope that nobody has signed up for Mysterio Sinister before I got there.

Requiring avatars to create a new account/password at each of the different metaverse service providers is not a very appealing prospect. Why aren't we addressing the federated identity/presence issue now? There are a number of existing approaches that could be relatively easily adopted across different technologies and set the stage for deeper interoperability down the road.

To make any real progress, we need agreement about standards for accepting identities provided by other virtual worlds. Even better, how about something that is not a virtual world (OAuth, OpenID, Shibboleth all come to mind) an option as an identity provider? Solving this problem is a prerequisite for making any real progress toward allowing free movement across worlds.

Why aren't we talking about standards for

    name@identity_provider

authentication which could be used across worlds?



Mark McCahill
OpenCroquet/Cobalt


On Feb 18, 2009, at 7:34 PM, Jon Watte wrote:
>
> So, what is an avatar anyway? I think it has one or more meshes (that are not standard), draped over a skeleton (that is not standard), with one or more textures applied (that are not standard). Avatars also represent users, which have identity. Avatars can move (physically, with collision detection), animate (interactions, emotes), voice communicate and text chat.
>
> If you can send that information ([identity, mesh, texture, skeleton] as set-up, and [movement, animation, interactions, voice and text chat] at runtime) then do you have an interoperable avatar?
> And, if so, what separates an avatar from another animated, movable object? Could the same way that avatars are interoperating be used to interoperate other simulated objects? From a remote systems' point of view, there's not that much difference between a human-driven avatar, and a tumbling rock -- the remote system can't be expected to run the simulation for either one, so it needs to have that stream of behavior to represent it.
>
> As far as I know Wonderland, Qwaq, Multiverse and other possible adopters, the above representations maps fairly straightforward to their systems, although any system will have to expect to write adaption code to accept "arbitrary" external meshes as avatars.
>
> Sincerely,
>
> jw
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--0-1643646255-1235069566=:34293-- From john.hurliman@intel.com Thu Feb 19 11:00:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820513A68F5 for ; Thu, 19 Feb 2009 11:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D9v9zBE-Eju for ; Thu, 19 Feb 2009 11:00:05 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 5CF1B3A67FA for ; Thu, 19 Feb 2009 11:00:05 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 19 Feb 2009 10:55:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,236,1233561600"; d="scan'208";a="388196760" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga002.jf.intel.com with ESMTP; 19 Feb 2009 11:09:06 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Thu, 19 Feb 2009 12:00:18 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Thu, 19 Feb 2009 12:00:16 -0700 Thread-Topic: [mmox] where is identity @ in all this? Thread-Index: AcmSw0R59BPlMSFEQGGw1RTyyltcbgAAKS+A Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FE824@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> <747254.34293.qm@web82602.mail.mud.yahoo.com> In-Reply-To: <747254.34293.qm@web82602.mail.mud.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 19:00:06 -0000 I would go even further and say authentication methods should be completely= out of scope for VW interop. Authentication methods are out of scope for O= penID as well. OpenID provides bits and pieces to make federated identity w= ork, and I would argue that supporting multiple federated identity solution= s drastically increases the complexity of the system with no return. But th= ere's no reason you can't have OpenID+LDAP, OpenID+username/password, OpenI= D+XML-RPC token exchange, etc. John >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Charles Krinke >Sent: Thursday, February 19, 2009 10:53 AM >To: Mark P. McCahill; mmox@ietf.org >Subject: Re: [mmox] where is identity @ in all this? > > >Dear Mark: > >Yes, that is a place where we can make progress. I am in fact "Charles >Krinke" on OSGrid, but I needed to be "Charlesk Bing" on SecondLife due >to the rules of that particular grid. > >I have a gmail account, as many other folks to and thus I believe I >already have an OpenID, so using OpenID is not unreasonable. > >I would personally suggest that we recommend at least two different >authentication methods so as not to paint ourselves into a corner down >the road a bit. > >Charles Krinke > >p.s. I would love to hear more about Croquet and how we can find ways to >interop and teleport between SecondLife, OpenSim and Croquet. > > > >________________________________ > >From: Mark P. McCahill >To: mmox@ietf.org >Sent: Thursday, February 19, 2009 10:26:51 AM >Subject: [mmox] where is identity @ in all this? > >These worlds are fundamentally social environments. I would suggest >starting with interoperability for federated identity and presence. > >At a minimum I want to know which worlds my buddies are currently >playing in, and be able to chat with them, and be able to chat with >people outside the virtual worlds. If there are any ambitions toward >integrating presence in virtual worlds with more traditional audio, >video, and text communications, then SIP and XMPP-based presence would >be worth considering rather than re-inventing these functions. > >Most virtual worlds act as both metaverse service providers (MSP) and >identity providers. This is a mistake. > >Tightly coupling the MSP and identity provider functions is why I have >to keep telling people that Mark McCahill is named Mysterio Sinister in >Second Life - I can't easily be mccahill@duke.edu because Second Life >doesn't use external federated identity providers. Then when I go to one >of the OpenSim worlds, I need to create another account, and hope that >nobody has signed up for Mysterio Sinister before I got there. > >Requiring avatars to create a new account/password at each of the >different metaverse service providers is not a very appealing prospect. >Why aren't we addressing the federated identity/presence issue now? >There are a number of existing approaches that could be relatively >easily adopted across different technologies and set the stage for >deeper interoperability down the road. > >To make any real progress, we need agreement about standards for >accepting identities provided by other virtual worlds. Even better, how >about something that is not a virtual world (OAuth, OpenID, Shibboleth >all come to mind) an option as an identity provider? Solving this >problem is a prerequisite for making any real progress toward allowing >free movement across worlds. > >Why aren't we talking about standards for > > name@identity_provider > >authentication which could be used across worlds? > > > >Mark McCahill >OpenCroquet/Cobalt > > >On Feb 18, 2009, at 7:34 PM, Jon Watte wrote: >> >> So, what is an avatar anyway? I think it has one or more meshes (that >are not standard), draped over a skeleton (that is not standard), with >one or more textures applied (that are not standard). Avatars also >represent users, which have identity. Avatars can move (physically, with >collision detection), animate (interactions, emotes), voice communicate >and text chat. >> >> If you can send that information ([identity, mesh, texture, skeleton] >as set-up, and [movement, animation, interactions, voice and text chat] >at runtime) then do you have an interoperable avatar? >> And, if so, what separates an avatar from another animated, movable >object? Could the same way that avatars are interoperating be used to >interoperate other simulated objects? From a remote systems' point of >view, there's not that much difference between a human-driven avatar, >and a tumbling rock -- the remote system can't be expected to run the >simulation for either one, so it needs to have that stream of behavior >to represent it. >> >> As far as I know Wonderland, Qwaq, Multiverse and other possible >adopters, the above representations maps fairly straightforward to their >systems, although any system will have to expect to write adaption code >to accept "arbitrary" external meshes as avatars. >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > >_______________________________________________ >mmox mailing list >mmox@ietf.org >https://www.ietf.org/mailman/listinfo/mmox > From yesha.sivan@gmail.com Thu Feb 19 11:52:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2673A69A3 for ; Thu, 19 Feb 2009 11:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.438 X-Spam-Level: X-Spam-Status: No, score=0.438 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0U-91WXhki9c for ; Thu, 19 Feb 2009 11:52:05 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id DEC013A68C5 for ; Thu, 19 Feb 2009 11:52:04 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so1031871fgb.41 for ; Thu, 19 Feb 2009 11:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=nesYsV4I5GYkslN2C7bzXJ5OUYdsJeXpMU8Jz6N/Qjk=; b=AmOB16HA6TgCb7LSbmt9iMYw7rweYyIkzc6TTu6lLmcAPlqu8cPOxyqbH/qts9vsyu rRUS/9fEa0ni18uKjSFkSPF7UepgV4btBq12TOvkE+qIp7Fv/NE9WBO42Hjhd62HnU3r tHwX3ZtxEWVe0i1bJ9Vx394JpC724uLocIRPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=GIbgI3m0TQEQ4+sEa0t8/8Yxwca1JabQVQIRuLgaZlC3PHNy5fzYjM/o8KZjA56kSw TQLVpOgAYdE3uT9DJtaZOaKx32MTwiktt3LGsMubmGB1TZCzoWlyl6QQenL7OgbXW/e8 OBCjnwLawroYu775aj8e5QSao+sEHHOWJMLlo= MIME-Version: 1.0 Sender: yesha.sivan@gmail.com Received: by 10.103.214.13 with SMTP id r13mr952458muq.37.1235073137846; Thu, 19 Feb 2009 11:52:17 -0800 (PST) In-Reply-To: <3e3ef2f00902191147n487c28f0o56cf5845ff4aa404@mail.gmail.com> References: <3e3ef2f00902191147n487c28f0o56cf5845ff4aa404@mail.gmail.com> Date: Thu, 19 Feb 2009 21:52:17 +0200 X-Google-Sender-Auth: 903e1cc6ef539fd7 Message-ID: <3e3ef2f00902191152p70380e81x2fbfbefb921d6c1f@mail.gmail.com> From: Yesha Sivan To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636a7d912a7296404634adf3b Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 19:52:06 -0000 --001636a7d912a7296404634adf3b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Friends (real and virtual, current and future): My name is Yesha Sivan and I'm the technical coordinator of the Metaverse1 EU based group (www.metaverse1.org) -- we are the leading team behind MPEG-V . I have worked on standards for virtual worlds (and real worlds) for 2 years now -- mainly taking the approach that we need a formal official process. MPEG was our choice. In my academic life I teach courses in software design (and virtual worlds), as well as MBA (and virtual worlds), and... fashion (and virtual worlds). I can actually teach any topic and virtual worlds course and I will have lots of fun with it. In my business life I work for Metaverse Labs which is a consulting firm (mainly working with VCs and policy makers, as well as on strategy issues for IT). In SL I'm Dera Kit (but not enough in-world as I want or should). Blog: www.dryesha.com In virtual worlds I'm best known for the "3D3C" theory (3D, Community, Creation, Commerce) which I have spoken/written in many places. One of the latest places is here: (it has other virtual worlds and enterprise it related papers) http://www.dryesha.com/2008/09/cutter-journal-finding-real-world-value.html For my older work on standards see: http://www.dryesha.com/2000/12/yeshas-five-dimentions-of-standards.html I also want to invite people to write papers for a special issue of the Journal of Virtual Worlds -- I'm co-editing about Virtual Worlds: Technology, Economy, and Standards. http://www.dryesha.com/2009/01/cfp-virtual-worlds-technology-economy.html Looking forward to the work here... --Yesha Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual Worlds. --001636a7d912a7296404634adf3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= div class=3D"Ih2E3d">Friends (real and virtual, current and future):
My name is Yesha Sivan and I'm the technical coordinator of the Metave= rse1 EU based group (www.metaverse1.org) -- we are the leading team behind MPEG-V.

I have worked on standards for virtual worlds (and real worlds) for 2 years now -- mainly taking the approach that we need a formal official process. MPEG was our choice.

In my academic life I teach courses in software design (and virtual worlds), as well as MBA (and virtual worlds), and... fashion (and virtual worlds).  I can actually teach any topic and virtual worlds co= urse and I will have lots of fun with it.


In my business life I work for Metaverse Labs which is a consulting firm (mainly working with VCs and policy makers, as well as on strategy issues for IT).

In SL I'm Dera Kit (but not enough in-world as I= want or should).

Blog: www.dryesha= .com

In virtual worlds I'm best known for the "3D3C" theory (3D, Comm= unity, Creation, Commerce) which I have spoken/written in many places. One of the latest places  is here: (it has other virtual worlds and enterpris= e it related papers)
http://www.dryesha.com/2008/09/cutter-journa= l-finding-real-world-value.html

For my older work on standards see:
http://www.dryesha.com/2000/12/yeshas-five-dimen= tions-of-standards.html

I also want to invite people to write papers for a special issue of the= Journal of Virtual Worlds -- I'm co-editing
about Virtual Worlds: T= echnology, Economy, and Standards.
http://w= ww.dryesha.com/2009/01/cfp-virtual-worlds-technology-economy.html

Looking forward to the work here...

--Yesha

Dr. Yesha Y. Sivan, = http://www.dryesha.com; Connecting Real and Virtual Worlds.
--001636a7d912a7296404634adf3b-- From infinity@lindenlab.com Thu Feb 19 12:06:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E21A28C0E7 for ; Thu, 19 Feb 2009 12:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80-qv7MSjOhc for ; Thu, 19 Feb 2009 12:06:19 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id C5D5C3A68EC for ; Thu, 19 Feb 2009 12:06:19 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id B1BEB3DBC0A2; Thu, 19 Feb 2009 12:06:33 -0800 (PST) Message-Id: <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> From: Meadhbh Hamrick (Infinity) To: Charles Krinke In-Reply-To: <647098.76086.qm@web82602.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1--931252393 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 12:06:25 -0800 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 20:06:21 -0000 --Apple-Mail-1--931252393 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit the draft charter is the best guide for what we're hoping to achieve. you can find a copy at http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter the things to remember here are: a. we're not trying to solve the problem of interoperability between every existing virtual world. at least not in the near term. - and... by extension... we're not trying to specify a general- purpose virtual world application stack that would enable a single client application to interoperate with any virtual world. b. we're not trying to solve the general problem of "what is a virtual world." i would refer you to the VWR and MPEG-V groups for that. c. we're trying to build a flexible, extensible application layer wire protocol used for virtual world interoperability. but the protocol we define here may need to be augmented by an "interoperability profile" - in other words, we're defining mechanism, not policy. for example, second life and opensim now have a "one simulator per 256m square region." we may not want to enshrine this in the protocol (i mean... what does this mean in the context of a virtual world like EVE Online?) instead, we should put this in an interoperability profile. the profile would reference the ogp base documents, but add implementation details required for proper presentation of the virtual world, but not required for the definition of the wire protocol. d. OGP is not what Second Life currently uses. OGP was originally conceived as being the AWG's "next generation" virtual worlds protocol. (the AWG being a technical architecture working group with Linden, IBM and OpenSIm contributors) for what it's worth... we demonstrated interoperability last summer between systems managed by linden lab and various partner systems using open sim and PyOGP. e. SL OGP (the OGP drafts that were written last summer) is not a complete body of work. there's still a lot of stuff to add. part of linden's motivation for participating in an IETF process is to continue to develop this protocol in a forum where we get maximal involvement from the internet community. f. HyperGrid is pretty darn'd cool, IMHO. and there's nothing in it that would eliminate it from consideration by this group. I believe John Hurliman is trying to define it in draft form to be considered at the upcoming face to face in san francisco. even if we don't have a HG draft for that meeting, i am confident it will attract considerable attention on the mailing list, and honestly, we're months (if not years) away from turning any internet drafts into RFCs. - if you've been following the HG discussion, you may have seen talk about the difference in trust models between OGP and HG. but... if we can create an abstract trust model that allows implementers to pick "OGP" or "HG" trust, i think we could easily define the wire protocol for both traditional OGP and HG users. so... to recap... * we're about application layer wire protocol * we're about interoperability between current or near future implementations * we're NOT blessing Second Life's existing protocol as an official standard * it's entirely possible application developers using MMOX protocols would need to define an "interoperability profile," which defines how MMOX applies to their application. * in other words, "we define mechanism, not policy." On Feb 19, 2009, at 7:55 AM, Charles Krinke wrote: > Dear Morgaine: > > That could very well be. Shared spaces may or may not be achievable > in the near term. > > That sort of gets us back to figuring out what we "do" wish to > accomplish. > > Are we here to seek consensus and modify the already existing and > deployed OGP protocol of SecondLife? Are we here to see if HyperGrid > from OpenSim is appropriate for this group? Are there other > protocols to consider? > > So, I have to ask, as I am getting confused with all the e-mails > flying around and like many, I have lots of things to concentrate > on. So: > > "What are we here for and what do we hope to accomplish?" > > Charles > > From: Morgaine > To: Jon Watte > Cc: "mmox@ietf.org" > Sent: Thursday, February 19, 2009 7:36:54 AM > Subject: Re: [mmox] User Accounts / "Object" Transfer. > > > > On Thu, Feb 19, 2009 at 12:37 AM, Jon Watte wrote: > > Let's assume organization A builds a space. Let's assume > organization B builds furniture. Now, they want to have a meeting, > and see how the furniture works in the space. The easiest way to > accomplish this is to make organization A users log into the > organization A virtual world (like they always do), and organization > B users log into organization B virtual world (like they always do), > and make arrangements such that some room/area/island within the two > organizations is shared -- whatever comes to that space from A, also > shows up in B, and vice versa. This allows A to publish its space, > and B to bring the furniture to that space, without either having to > disconnect from their regular virtual world (buddy list, unified > messaging, inter-office collaboration, etc). > > Unfortunately, that's non-scalable, particularly along the > complexity axis. > > It works fine in your example because you have only two parties > wishing to share a space and hence there is only one space to > simulate, but try to extrapolate from there to see where it leads. > If your organization A has N users, and those N users wish to take > part in N different worlds (which is asymptotically likely if N << > total number of worlds), then your organization A must now simulate > N different worlds. For large N, this places a colossal load on > organization A, even if the individual shared spaces are minimally > populated. To coin a common phrase by analogy, you're undertaking > to "simulate the Internet". ;-) > > What's more, very few platform optimizations will be possible since > the N worlds are all different, and this also means that the > scalability of each shared space will be severely constrained as > well. And as if that were not bad enough, the N worlds that your > users visit tomorrow will not necessarily be today's N worlds, so > for (N << total number of worlds) your local cache will need to grow > almost without limit if it's to work at all. > > Even if organization A's machinery were powerful enough to support N > radically different worlds through shared-space simulations though, > they still couldn't do it, because in the general case the > simulation code for a given world will not be available. The world > simulation is the "secret sauce" of many virtual worlds, and from a > business perspective it is quite likely to be their product > differentiator and they will be loathe to share it. But even if it > were freely available, the portability of one organization's > simulation code to another organization's machinery is far from > guaranteed with today's software technology, not to mention the > management of upgrades for something this complex across > organization boundaries. > > Now contrast that shared-space architecture to today's more > prevalent one. Organizations A and B(1)...B(N) design their own > worlds in accordance with their particular visions, and each world > is tailored to their own optimized hardware. Now in the case when > the N users of organization A travel to those N different B worlds, > organization A has no world simulation load for active users at all > (it just sends out data to the N worlds). Instead, some number of > foreign users from the B worlds will arrive and need to be > supported. However, they are supported in organization A's own > world simulation, which is highly optimized by design and hence > carries none of the complexity/scalability problems mentioned above > in the shared-space approach. Foreign world simulations never need > to be supported. > > In the Internet-like metaverse model of unlimited and extremely > diverse worlds, I really don't see the shared-space approach as > being at all viable, because diversity is its enemy. In some > severely constrained corporate settings it might be quite usable > (and even efficient for standardized worlds), but this does not seem > to be a generally scalable model for an evolving metaverse. > > Morgaine. > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-1--931252393 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable the draft charter is the best = guide for what we're hoping to achieve.


the = things to remember here are:

a. we're = not trying to solve the problem of interoperability between every = existing virtual world. at least not in the near term.
- = and... by extension... we're not trying to specify a general-purpose = virtual world application stack that would enable a single client = application to interoperate with any virtual = world.

b. we're not trying to solve the = general problem of "what is a virtual world." i would refer you to the = VWR and MPEG-V groups for that.

c. we're = trying to build a flexible, extensible application layer wire protocol = used for virtual world interoperability. but the protocol we define here = may need to be augmented by an "interoperability = profile"
- in other words, we're = defining mechanism, not policy. for example, second life and opensim now = have a "one simulator per 256m square region." we may not want to = enshrine this in the protocol (i mean... what does this mean in the = context of a virtual world like EVE Online?) instead, we should put this = in an interoperability profile. the profile would reference the ogp base = documents, but add implementation details required for proper = presentation of the virtual world, but not required for the definition = of the wire protocol.

d. OGP is = not what Second Life currently uses. OGP was originally conceived as = being the AWG's "next generation" virtual worlds protocol. (the AWG = being a technical architecture working group with Linden, IBM and = OpenSIm contributors) for what it's worth... we demonstrated = interoperability last summer between systems managed by linden lab and = various partner systems using open sim and = PyOGP. 

e. SL OGP (the OGP drafts that = were written last summer) is not a complete body of work. there's still = a lot of stuff to add. part of linden's motivation for participating in = an IETF process is to continue to develop this protocol in a forum where = we get maximal involvement from the internet = community.

f. HyperGrid is pretty darn'd = cool, IMHO. and there's nothing in it that would eliminate it from = consideration by this group. I believe John Hurliman is trying to define = it in draft form to be considered at the upcoming face to face in san = francisco. even if we don't have a HG draft for that meeting, i am = confident it will attract considerable attention on the mailing list, = and honestly, we're months (if not years) away from turning any internet = drafts into RFCs.=
- if you've been = following the HG discussion, you may have seen talk about the difference = in trust models between OGP and HG. but... if we can create an abstract = trust model that allows implementers to pick "OGP" or "HG" trust, i = think we could easily define the wire protocol for both traditional OGP = and HG users.

so... to = recap...

* we're about application layer = wire protocol
* we're about interoperability = between current or near future implementations
* we're = NOT blessing Second Life's existing protocol as an official = standard
* it's entirely possible = application developers using MMOX protocols would need to define an = "interoperability profile," which defines how MMOX applies to their = application.
* in other words, "we = define mechanism, not policy."

On Feb 19, = 2009, at 7:55 AM, Charles Krinke wrote:

Dear Morgaine:

That could very well be. = Shared spaces may or may not be achievable in the near term.

That = sort of gets us back to figuring out what we "do" wish to = accomplish. 

Are = we here to seek consensus and modify the already existing and deployed = OGP protocol of SecondLife? Are we here to see if HyperGrid from OpenSim = is appropriate for this group? Are there other protocols to = consider?

So, I have to ask, as I am getting confused with all = the e-mails flying around and like many, I have lots of things to = concentrate on. So:

"What are we here for and what do we hope to = accomplish?"

Charles

From: Morgaine <morgaine.dinova@googlemail.= com>
To: Jon Watte <jwatte@gmail.com>
Cc: "mmox@ietf.org" <mmox@ietf.org>
Sent: Thursday, February 19, 2009 = 7:36:54 AM
 Re: [mmox] User Accounts / = "Object" Transfer.



On Thu, Feb 19, 2009 at 12:37 AM, Jon Watte <jwatte@gmail.com> wrote:

What's more, very few platform optimizations will be possible = since the N worlds are all different, and this also means that the = scalability of each shared space will be severely constrained as = well.  And as if that were not bad enough, the N worlds that your = users visit tomorrow will not necessarily be today's N worlds, so for (N = << total number of worlds) your local cache will need to grow = almost without limit if it's to work at all.

Even if organization = A's machinery were powerful enough to support N radically different = worlds through shared-space simulations though, they still couldn't do = it, because in the general case the simulation code for a given world = will not be available.  The world simulation is the "secret sauce" = of many virtual worlds, and from a business perspective it is quite = likely to be their product differentiator and they will be loathe to = share it.  But even if it were freely available, the portability of = one organization's simulation code to another organization's machinery = is far from guaranteed with today's software technology, not to mention = the management of upgrades for something this complex across = organization boundaries.

Now contrast that shared-space = architecture to today's more prevalent one.  Organizations A and = B(1)...B(N) design their own worlds in accordance with their particular = visions, and each world is tailored to their own optimized = hardware.  Now in the case when the N users of organization A = travel to those N different B worlds, organization A has no world = simulation load for active users at all (it just sends out data to the N = worlds).  Instead, some number of foreign users from the B worlds = will arrive and need to be supported.  However, they are supported = in organization A's own world simulation, which is highly optimized by = design and hence carries none of the complexity/scalability problems = mentioned above in the shared-space approach.  Foreign world = simulations never need to be supported.

In the Internet-like = metaverse model of unlimited and extremely diverse worlds, I really = don't see the shared-space approach as being at all viable, because = diversity is its enemy.  In some severely constrained corporate = settings it might be quite usable (and even efficient for standardized = worlds), but this does not seem to be a generally scalable model for an = evolving = metaverse.

Morgaine.
_________________________= ______________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/m= ailman/listinfo/mmox

= --Apple-Mail-1--931252393-- From john.hurliman@intel.com Thu Feb 19 12:36:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044D93A69A3 for ; Thu, 19 Feb 2009 12:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+qR0Y07PwZF for ; Thu, 19 Feb 2009 12:36:32 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 1DCFE3A6881 for ; Thu, 19 Feb 2009 12:36:31 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 19 Feb 2009 12:36:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,236,1233561600"; d="scan'208";a="112425269" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by azsmga001.ch.intel.com with ESMTP; 19 Feb 2009 12:36:45 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Thu, 19 Feb 2009 13:36:40 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Thu, 19 Feb 2009 13:36:38 -0700 Thread-Topic: [mmox] User Accounts / "Object" Transfer. Thread-Index: AcmSzZ2kC5n0lGDlTGa/SylF5t3fqwAAmDaQ Message-ID: <62BFE5680C037E4DA0B0A08946C0933D501FE91E@rrsmsx506.amr.corp.intel.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> In-Reply-To: <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 20:36:34 -0000 >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Meadhbh Hamrick >Sent: Thursday, February 19, 2009 12:06 PM >To: Charles Krinke >Cc: mmox@ietf.org >Subject: Re: [mmox] User Accounts / "Object" Transfer. > >the draft charter is the best guide for what we're hoping to achieve. > >you can find a copy at >http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter > >the things to remember here are: > >a. we're not trying to solve the problem of interoperability between >every existing virtual world. at least not in the near term. >- and... by extension... we're not trying to specify a general-purpose >virtual world application stack that would enable a single client >application to interoperate with any virtual world. > > >b. we're not trying to solve the general problem of "what is a virtual >world." i would refer you to the VWR and MPEG-V groups for that. > >c. we're trying to build a flexible, extensible application layer wire >protocol used for virtual world interoperability. but the protocol we >define here may need to be augmented by an "interoperability profile" >- in other words, we're defining mechanism, not policy. for example, >second life and opensim now have a "one simulator per 256m square >region." we may not want to enshrine this in the protocol (i mean... >what does this mean in the context of a virtual world like EVE Online?) >instead, we should put this in an interoperability profile. the profile >would reference the ogp base documents, but add implementation details >required for proper presentation of the virtual world, but not required >for the definition of the wire protocol. > >d. OGP is not what Second Life currently uses. OGP was originally >conceived as being the AWG's "next generation" virtual worlds protocol. >(the AWG being a technical architecture working group with Linden, IBM >and OpenSIm contributors) for what it's worth... we demonstrated >interoperability last summer between systems managed by linden lab and >various partner systems using open sim and PyOGP. > At the first AWG meeting in September 2007, it was made clear that Linden L= ab had already defined the architecture of OGP, and the purpose of the AWG = was to refine and implement this protocol. I'm not sure that demonstrating = compatibility between three codebases that all speak the Second Life protoc= ol could be categorized as interoperability. >e. SL OGP (the OGP drafts that were written last summer) is not a >complete body of work. there's still a lot of stuff to add. part of >linden's motivation for participating in an IETF process is to continue >to develop this protocol in a forum where we get maximal involvement >from the internet community. > >f. HyperGrid is pretty darn'd cool, IMHO. and there's nothing in it that >would eliminate it from consideration by this group. I believe John >Hurliman is trying to define it in draft form to be considered at the >upcoming face to face in san francisco. even if we don't have a HG draft >for that meeting, i am confident it will attract considerable attention >on the mailing list, and honestly, we're months (if not years) away from >turning any internet drafts into RFCs. >- if you've been following the HG discussion, you may have seen talk >about the difference in trust models between OGP and HG. but... if we >can create an abstract trust model that allows implementers to pick >"OGP" or "HG" trust, i think we could easily define the wire protocol >for both traditional OGP and HG users. > I don't know where you got the idea that I'm creating a HyperGrid proposal,= but I don't think anyone is pretending that merging two administrative dom= ains with some clever backend coding is interoperability. See my post at ht= tp://software.intel.com/en-us/blogs/2009/02/18/approaching-virtual-world-in= teroperability/ for the longer explanation of why OGP and HyperGrid are the= same solution with different default settings, and why neither actually ad= dress interoperability. > >so... to recap... > >* we're about application layer wire protocol >* we're about interoperability between current or near future >implementations >* we're NOT blessing Second Life's existing protocol as an official >standard That's not the question anyone is asking. The important question is: "Is th= e scope of MMOX limited to OGP, or mandating the discussion of OGP? Are vir= tual world interoperability proposals that are not compatible with OGP outs= ide of the scope of MMOX?" We can either stop talking about MMOX as a worki= ng group for OGP, or put it in writing that that's the case and people who = are not interested in OGP can save themselves the trouble. >* it's entirely possible application developers using MMOX protocols >would need to define an "interoperability profile," which defines how >MMOX applies to their application. >* in other words, "we define mechanism, not policy." > > ... From robla@lindenlab.com Thu Feb 19 13:02:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370F628C15E for ; Thu, 19 Feb 2009 13:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTIu92TTLBcy for ; Thu, 19 Feb 2009 13:02:17 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 737DA28C0E8 for ; Thu, 19 Feb 2009 13:02:17 -0800 (PST) Received: from synergy.lindenlab.com (synergy.lindenlab.com [10.1.23.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 3A67E3DBC0A2; Thu, 19 Feb 2009 13:02:31 -0800 (PST) Message-ID: <499DC8C4.4040008@lindenlab.com> Date: Thu, 19 Feb 2009 13:01:56 -0800 From: Rob Lanphier User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <499CC99D.8040302@cox.net><5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com><6A5E83A8-A7A1-4D38-8FAC-C04E360E47 77@lindenlab.com> <2A3D6CCD-58D1-4A01-9450-816839F05A4E@lindenlab.com> In-Reply-To: <2A3D6CCD-58D1-4A01-9450-816839F05A4E@lindenlab.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: [mmox] Jabber clients for mmox (Re: meeting minutes from today's ietf mmox simulcastingmeeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:02:18 -0000 On Mac, I've been able to get Adium to work (using my Google Talk account). Colloquy was a bust (failed, and eventually crashed) Adium instructions: 1. Get a Jabber account on a publicly-connected server somewhere (e.g. Google) 2. Log into the account 3. Choose "Join Chat", select your Jabber account, then fill in these fields: a. Chat room name: mmox b. Server: jabber.ietf.org 4. Join Since I already had a private IM exchange going, it added the chat room as a tab on the existing dialog box, not giving it focus. That made me think it wasn't working when it fact, people were saying "Hi Rob" to me without my knowing it. Since Adium uses libpurple (nee libgaim), I imagine that Pidgin (nee Gaim) should work just fine for Win32 and Linux. Rob On 2/19/09 9:06 AM, Meadhbh Hamrick (Infinity) wrote: > hmm... what client were you using? colloquy seems to have problems > with both test@jabber.ietf.org as well > as other jabber servers. > > and can you change the mmox wiki page you made to not reference > mmox@jabber.ietf.org ? > > thx > > On Feb 19, 2009, at 5:38 AM, Morgaine wrote: > >> Excellent summary of a complex meeting, thanks Infinity. :-) >> >> On Thu, Feb 19, 2009 at 4:45 AM, Meadhbh Hamrick (Infinity) >> > wrote: >> >> >> * is the use of mmox@jabber.ietf.org >> required? several mac users have >> noted difficulty in using it. >> >> >> I'll echo Dave's reply that jabber.ietf.org >> is working fine. Some of us were in there together last night for >> tests in the "test" room. The "mmox" room hasn't yet been set up or >> enabled, but no doubt our AD can fix that. >> >> Looking at the Jabber room logs at http://jabber.ietf.org/logs/, it's >> worth noting that this facility is in use by many workgroups, well >> over a dozen since the start of the year. I think that it would >> serve MMOX well too, both during the forthcoming special meetings and >> subsequently when more interactive discussion is needed than email >> allows. >> >> Morgaine. >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From dwl@us.ibm.com Thu Feb 19 13:15:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84A53A6C0F; Thu, 19 Feb 2009 13:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.39 X-Spam-Level: X-Spam-Status: No, score=-5.39 tagged_above=-999 required=5 tests=[AWL=1.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bX4lb3J2kDIt; Thu, 19 Feb 2009 13:15:38 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 59B473A6BB0; Thu, 19 Feb 2009 13:15:38 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1JL8jhV019205; Thu, 19 Feb 2009 16:08:45 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1JLFpKu179976; Thu, 19 Feb 2009 16:15:51 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1JLEeaW026709; Thu, 19 Feb 2009 16:14:40 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1JLEehD026704; Thu, 19 Feb 2009 16:14:40 -0500 In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FE91E@rrsmsx506.amr.corp.intel.com> To: "Hurliman, John" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Thu, 19 Feb 2009 16:15:50 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/19/2009 16:15:50, Serialize complete at 02/19/2009 16:15:50 Content-Type: multipart/alternative; boundary="=_alternative 0074CE5485257562_=" Cc: mmox-bounces@ietf.org, "mmox@ietf.org" Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:15:39 -0000 This is a multipart message in MIME format. --=_alternative 0074CE5485257562_= Content-Type: text/plain; charset="US-ASCII" mmox-bounces@ietf.org wrote on 02/19/2009 03:36:38 PM: > >> John Hurliman wrote: > That's not the question anyone is asking. The important question is: > "Is the scope of MMOX limited to OGP, or mandating the discussion of > OGP? Are virtual world interoperability proposals that are not > compatible with OGP outside of the scope of MMOX?" We can either > stop talking about MMOX as a working group for OGP, or put it in > writing that that's the case and people who are not interested in > OGP can save themselves the trouble. This is a BOF with the explicit purpose of working towards a charter which answers that question. There is no charter, nor formal scope at the moment. That said.... The goal is an open process, with propels bringing proposals. Linden Lab has brought the OGP work and some ancillary documents to the table. They represent one place to mine for understanding of what we need. Croquet, (and more specifically, in many ways, QWAQ) offer a very different starting point. Collada has a huge amount of material about edge of system import/export models. Jon Watte, from Forterra brings another set of perspectives. The OpenSim community clearly has insight based on working within the broad "Second Life" model, as do other virtual world vendors. Our goal is not to constrain input, but to encourage it. I have a much longer post forthcoming trying to frame my sense of what it means to do a broad standard in the space, but let me be very clear. I don't think MMOX is about taking any one input and enshrining it as a standard. The BOF is, specifically about sorting out a charter and a shared vision of what we can productively do. If anyone is saying MMOX is about turning OGP into an IETF standard, they are confused. The OGP work, represents one concrete input into the process. The whole point of a BOF, and getting people together is to get a broad set of inputs, and participants. At the same time, there is a need to avoid "boiling the ocean" and pick off concrete, low hanging fruit we can work on within a broader context we define. The BOF won't be about doing that work, the BOF will be about creating a shared sense of the scope of the work, and working towards a charter with language that describes that shared goal. Note that in general, the IETF approach is to use face to face opportunities to bash out hard issues, and the mailing list and off line discussion between face to face meetings to drive details, get concrete proposals together and figure out both areas of consensus and difference. The current discussion, about what is in scope, and what is not, seems exactly right to help us have a productive BOF and capture some good language to seed the charter discussion. - David W. Levine ~ Zha Ewry (ISL) --=_alternative 0074CE5485257562_= Content-Type: text/html; charset="US-ASCII"

mmox-bounces@ietf.org wrote on 02/19/2009 03:36:38 PM:

> >>
John Hurliman wrote:
> That's not the question anyone is asking. The important question is:
> "Is the scope of MMOX limited to OGP, or mandating the discussion of
> OGP? Are virtual world interoperability proposals that are not
> compatible with OGP outside of the scope of MMOX?" We can either
> stop talking about MMOX as a working group for OGP, or put it in
> writing that that's the case and people who are not interested in
> OGP can save themselves the trouble.
This is a BOF with the explicit purpose of working towards a charter which answers that question.
There is no charter, nor formal scope at the moment. That said....

The goal is an open process, with propels bringing proposals. Linden Lab has brought the OGP work
and some ancillary documents to the table. They represent one place to mine for understanding of what we need.
Croquet, (and more specifically, in many ways, QWAQ) offer a very different starting point. Collada has a huge amount
of material about edge of system import/export models. Jon Watte, from Forterra brings another set of perspectives. The OpenSim community clearly has insight based on working within the broad "Second Life" model, as do other virtual world vendors. Our goal is not to constrain input, but to encourage it.

I have a much longer post forthcoming trying to frame my sense of what it means to do a broad standard in the space, but let me be very clear. I don't think MMOX is about taking any one input and enshrining it as a standard.  The BOF is, specifically about sorting out a charter and a shared vision of what we can productively do. If anyone is saying MMOX is about turning OGP into an IETF standard, they are confused. The OGP work, represents one concrete input into the process.

The whole point of a BOF, and getting people together is to get a broad set of inputs, and participants. At the same time, there is a need to avoid "boiling the ocean" and pick off concrete, low hanging fruit we can work on within a broader context we define. The BOF won't be about doing that work, the BOF will be about creating a shared sense of the scope  of the work, and working towards a charter with language that describes that shared goal.

Note that in general, the IETF approach is to use face to face opportunities to bash out hard issues, and the mailing list and off line discussion between face to face meetings to drive details, get concrete proposals together and figure out both areas of consensus and difference. The current discussion, about what is in scope, and what is not, seems exactly right to help us have a productive BOF and capture some good language to seed the charter discussion.

- David W. Levine
~ Zha Ewry (ISL)
--=_alternative 0074CE5485257562_=-- From jwatte@gmail.com Thu Feb 19 13:17:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5013A6BB0 for ; Thu, 19 Feb 2009 13:17:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ0oeGNyiF9p for ; Thu, 19 Feb 2009 13:17:31 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id DEE2F3A6B81 for ; Thu, 19 Feb 2009 13:17:30 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so494220yxm.49 for ; Thu, 19 Feb 2009 13:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YIRTQJuz6M1o32f/E/oquBA2ZZEnHuTah+I77WNJ/MI=; b=sR7HShtJu8aDMcpj9GVVvceIPu8GTTqFmZmg3roFZRo9g53hMvU0YhR8/uPA9RBfdy H9Zgp63Ckhw/GLh0U5zy/imlK6RAJsDmlrFviNjW1ld3tchtPzzmCY6TwabcYIHMwpcB 1Er3WrUOadI9Jzc2wahMIigYqP2NjU2mqgmqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hTZx0ufcd7xYOMF4wESGBCNmk3lmYD6wbMsA9pCXdW7BWGgL3WCVPYjEp1VsKALhPt FzUw0rSb8FtI9DhIFrAsECGv5s7yStMRG4bHMv2PeMv8EzcVtXpsRGJm6BGpQQPEBUef H+a28qZpwCCa/UJ369fv6z8SEinCHb5Fnps0E= Received: by 10.100.43.10 with SMTP id q10mr69609anq.1.1235078264537; Thu, 19 Feb 2009 13:17:44 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d29sm2392784and.34.2009.02.19.13.17.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 13:17:44 -0800 (PST) Message-ID: <499DCC75.2040009@gmail.com> Date: Thu, 19 Feb 2009 13:17:41 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dan Olivares References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> <499CF445.1000705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:17:32 -0000 I think here it's important, and it does matter. The user is only connected to the "home" server. The servers are connected, and exchange the data, but the client only gets data from the "home" server (which includes data about the interoperating entities). How else could the server side entities know about the other entities in the same space? Also, if you want to connect one client to a number of different systems, what do you do about UI, and protocols? If I connect to another system, do I suddenly have to learn the UI of that system? How would you even merge the UI of two different systems? Would my server-side activity logging work for the remote connection in that case? Having worked on interoperable virtual worlds since 2005, virtual worlds technology since 2001, and studying all the succeesses and failures since the 1980's (Cosmo player, anyone? :-), I've come to the conclusion that interoperating on the back end at the semantic layer is actually the simplest and most straightforward solution, while simultaneously enabling the most compelling interoperability scenarios. Sincerely, jw Dan Olivares wrote: > >From the technical perspective, agreed. From a user perspective, > it's all part of the same visible world. It doesn't matter that the > user is actually connected to 5 different servers each with it's own > scene that it's simulating in it's delegated space in the contiguous > world. > > Best Regards > > Daniel Olivares > > On Thu, Feb 19, 2009 at 12:55 AM, Jon Watte wrote: > >> There is no shared scene graph. Each server simulates "its" objects, and >> translates from the "interop" protocol to its internal system at the >> gateway. Think of it like a more modern version of IEEE 1278 (which has been >> a great success as far as interoperable distributed simulation goes). >> >> Sincerely, >> >> jw >> From tme@multicasttech.com Thu Feb 19 13:18:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518D83A6C13 for ; Thu, 19 Feb 2009 13:18:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Aq8cj2xweUn for ; Thu, 19 Feb 2009 13:18:43 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 405E73A6C12 for ; Thu, 19 Feb 2009 13:18:43 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14711974; Thu, 19 Feb 2009 16:17:13 -0500 Message-Id: <3E082D73-D3B8-41E5-87C8-39791D6D8E9F@multicasttech.com> From: Marshall Eubanks To: Rob Lanphier In-Reply-To: <499DC8C4.4040008@lindenlab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 16:18:52 -0500 References: <499CC99D.8040302@cox.net><5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com><6A5E83A8-A7A1-4D38-8FAC-C04E360E47 77@lindenlab.com> <2A3D6CCD-58D1-4A01-9450-816839F05A4E@lindenlab.com> <499DC8C4.4040008@lindenlab.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Jabber clients for mmox (Re: meeting minutes from today's ietf mmox simulcastingmeeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:18:44 -0000 Dear Rob; On Feb 19, 2009, at 4:01 PM, Rob Lanphier wrote: > On Mac, I've been able to get Adium to work (using my Google Talk > account). Colloquy was a bust (failed, and eventually crashed) On the Mac, what's wrong with iChat ? Marshall > > > Adium instructions: > 1. Get a Jabber account on a publicly-connected server somewhere > (e.g. > Google) > 2. Log into the account > 3. Choose "Join Chat", select your Jabber account, then fill in these > fields: > a. Chat room name: mmox > b. Server: jabber.ietf.org > 4. Join > > Since I already had a private IM exchange going, it added the chat > room > as a tab on the existing dialog box, not giving it focus. That made > me > think it wasn't working when it fact, people were saying "Hi Rob" to > me > without my knowing it. > > Since Adium uses libpurple (nee libgaim), I imagine that Pidgin (nee > Gaim) should work just fine for Win32 and Linux. > > Rob > > On 2/19/09 9:06 AM, Meadhbh Hamrick (Infinity) wrote: >> hmm... what client were you using? colloquy seems to have problems >> with both test@jabber.ietf.org as well >> as other jabber servers. >> >> and can you change the mmox wiki page you made to not reference >> mmox@jabber.ietf.org ? >> >> thx >> >> On Feb 19, 2009, at 5:38 AM, Morgaine wrote: >> >>> Excellent summary of a complex meeting, thanks Infinity. :-) >>> >>> On Thu, Feb 19, 2009 at 4:45 AM, Meadhbh Hamrick (Infinity) >>> > wrote: >>> >>> >>> * is the use of mmox@jabber.ietf.org >>> required? several mac users have >>> noted difficulty in using it. >>> >>> >>> I'll echo Dave's reply that jabber.ietf.org >>> is working fine. Some of us were in there together last night for >>> tests in the "test" room. The "mmox" room hasn't yet been set up or >>> enabled, but no doubt our AD can fix that. >>> >>> Looking at the Jabber room logs at http://jabber.ietf.org/logs/, >>> it's >>> worth noting that this facility is in use by many workgroups, well >>> over a dozen since the start of the year. I think that it would >>> serve MMOX well too, both during the forthcoming special meetings >>> and >>> subsequently when more interactive discussion is needed than email >>> allows. >>> >>> Morgaine. >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From jwatte@gmail.com Thu Feb 19 13:21:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4883A6B81 for ; Thu, 19 Feb 2009 13:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YLfnZd1v4r4 for ; Thu, 19 Feb 2009 13:21:30 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 3E8043A68EF for ; Thu, 19 Feb 2009 13:21:30 -0800 (PST) Received: by gxk22 with SMTP id 22so1702568gxk.13 for ; Thu, 19 Feb 2009 13:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Fv79vLXBnkj723XJjDMNTfKq77+BrxSD05b3ZeaiW58=; b=BC1u0lOmNr50UN5seZ3hIAZTWCwyiNNQkULkxL58J+t1zHr+wnwQ1bPwKTwhxkFluw KJ+u04ocFrH9wjn1teobvk07+wc6Pfvprxq6N+310NwWYKusqysGJj7FM4LRdNam8I0M Ti9ol77lOBq+0Rz9sQSjHzxnhvWWFx9a2RPHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=mBCu8B9Xy3HsTgfCjh8BfEwYWMgz8PfVCFaBfb48+uhKxqSEWQ5u5AMfRkYGEzGyna yb16feXfcMVa7YOjkrnXpouE15dTe1I3YpvlWpsyS5Q37Rq1opzTG71RwyVAEHxuFApK 5NhrHA6tUn+3qmiHf71VcDyoDpcnnyziV35ak= Received: by 10.100.93.17 with SMTP id q17mr11325anb.93.1235078502147; Thu, 19 Feb 2009 13:21:42 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c9sm1569913ana.13.2009.02.19.13.21.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 13:21:41 -0800 (PST) Message-ID: <499DCD63.50201@gmail.com> Date: Thu, 19 Feb 2009 13:21:39 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090219.011715.22395.1@webmail19.vgs.untd.com> In-Reply-To: <20090219.011715.22395.1@webmail19.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 48 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:21:31 -0000 Can we please stop the sound-byte-ing. We're not daring pioneers in the larger sense -- virtual worlds have been around forever. There have been many attempts over many years (Habitat, ActiveWorlds, The Palace, all the VRML in the '90s...) , and interoperability between dozens of vendors, including imagery and real-time voice, has been done since the '80s. What's new is that the technology is being popularized to more users. I suggest we focus on building features that users want to pay for, because that's how things actually get done on a larger scale. Btw: If it's a regular video stream, served by video streaming servers, and watchable through a regular web browser, does that even count as "bringint the meeting into the virtual world"? It's just video streaming, not interactive. I agree it's useful and worthwhile, but I really do wish that the sound-byting would end... Sincerely, jw dyerbrookme@juno.com wrote: > > Excuse me, but you do not "represent" these virtual worlds. You did this without the public's consent. It's also not up to you to do gate-keeping and "allow" meeting participation from within them. > > Prokofy Neva > > ____________________________________________________________ > Click here to save cash and find low rates on auto loans. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLaWzD1kfoiUAtgagQj9giOkex5Vb7bGoJ9MNSrQ9x66VJjfFwD88/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From robla@lindenlab.com Thu Feb 19 13:25:43 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042EC28C122 for ; Thu, 19 Feb 2009 13:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLhlvVVBOP+F for ; Thu, 19 Feb 2009 13:25:42 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 2D96228C10B for ; Thu, 19 Feb 2009 13:25:42 -0800 (PST) Received: from synergy.lindenlab.com (synergy.lindenlab.com [10.1.23.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 208BE3DBC45B; Thu, 19 Feb 2009 13:25:56 -0800 (PST) Message-ID: <499DCE41.1080209@lindenlab.com> Date: Thu, 19 Feb 2009 13:25:21 -0800 From: Rob Lanphier User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Marshall Eubanks References: <499CC99D.8040302@cox.net><5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com><6A5E83A8-A7A1-4D38-8FAC-C04E360E47 77@lindenlab.com> <2A3D6CCD-58D1-4A01-9450-816839F05A4E@lindenlab.com> <499DC8C4.4040008@lindenlab.com> <3E082D73-D3B8-41E5-87C8-39791D6D8E9F@multicasttech.com> In-Reply-To: <3E082D73-D3B8-41E5-87C8-39791D6D8E9F@multicasttech.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Jabber clients for mmox (Re: meeting minutes from today's ietf mmox simulcastingmeeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:25:43 -0000 On 2/19/09 1:18 PM, Marshall Eubanks wrote: > On Feb 19, 2009, at 4:01 PM, Rob Lanphier wrote: > >> On Mac, I've been able to get Adium to work (using my Google Talk >> account). Colloquy was a bust (failed, and eventually crashed) > > On the Mac, what's wrong with iChat ? I wasn't able to get it to work. I tried that as well. Rob >> >> >> Adium instructions: >> 1. Get a Jabber account on a publicly-connected server somewhere (e.g. >> Google) >> 2. Log into the account >> 3. Choose "Join Chat", select your Jabber account, then fill in these >> fields: >> a. Chat room name: mmox >> b. Server: jabber.ietf.org >> 4. Join >> >> Since I already had a private IM exchange going, it added the chat room >> as a tab on the existing dialog box, not giving it focus. That made me >> think it wasn't working when it fact, people were saying "Hi Rob" to me >> without my knowing it. >> >> Since Adium uses libpurple (nee libgaim), I imagine that Pidgin (nee >> Gaim) should work just fine for Win32 and Linux. >> >> Rob >> >> On 2/19/09 9:06 AM, Meadhbh Hamrick (Infinity) wrote: >>> hmm... what client were you using? colloquy seems to have problems >>> with both test@jabber.ietf.org as well >>> as other jabber servers. >>> >>> and can you change the mmox wiki page you made to not reference >>> mmox@jabber.ietf.org ? >>> >>> thx >>> >>> On Feb 19, 2009, at 5:38 AM, Morgaine wrote: >>> >>>> Excellent summary of a complex meeting, thanks Infinity. :-) >>>> >>>> On Thu, Feb 19, 2009 at 4:45 AM, Meadhbh Hamrick (Infinity) >>>> > wrote: >>>> >>>> >>>> * is the use of mmox@jabber.ietf.org >>>> required? several mac users have >>>> noted difficulty in using it. >>>> >>>> >>>> I'll echo Dave's reply that jabber.ietf.org >>>> is working fine. Some of us were in there together last night for >>>> tests in the "test" room. The "mmox" room hasn't yet been set up or >>>> enabled, but no doubt our AD can fix that. >>>> >>>> Looking at the Jabber room logs at http://jabber.ietf.org/logs/, it's >>>> worth noting that this facility is in use by many workgroups, well >>>> over a dozen since the start of the year. I think that it would >>>> serve MMOX well too, both during the forthcoming special meetings and >>>> subsequently when more interactive discussion is needed than email >>>> allows. >>>> >>>> Morgaine. >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > From jwatte@gmail.com Thu Feb 19 13:33:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E831728C122 for ; Thu, 19 Feb 2009 13:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9I1m-F4BAXv for ; Thu, 19 Feb 2009 13:33:19 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id DB1743A6ABF for ; Thu, 19 Feb 2009 13:33:18 -0800 (PST) Received: by gxk22 with SMTP id 22so1718485gxk.13 for ; Thu, 19 Feb 2009 13:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=I0iIyQxa6qnuCKszC70ecKDRnD8X+9gLADHP4zY1dLE=; b=oLr2/7m9mnh2vZdgyK5l46eSA9Z+Z4QgIDNW00XTNVTCvgWh+VkM2BlaF8pj6d5UJa EGrCU69s/ed7MjNrofISDAitUVG1/yQgsYVllcSf356yKiFNVTb8tt1U5Ebe5GgVDtn0 3huXdMd1T9hu9V2h2n5qqKaseHIREhGXddTkc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=lHmrFnXj1NFJ6vy8Y36la3Hy4bFM46thVBdV7CsyIiIy1a0hU8tSFYm92O2bJ9SWn/ 9M8JGfV2UZJUtfqOZEWnQ1iNOUfkfGOeM4WfAbfZIkPTCFehuqPyQYvo3Y/ftQgDhHnc HEpp9HjcGVEGDkeEqnxNYPQevLhkIK66i48xE= Received: by 10.100.163.8 with SMTP id l8mr10184ane.127.1235079211962; Thu, 19 Feb 2009 13:33:31 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b29sm192683ana.51.2009.02.19.13.33.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 13:33:31 -0800 (PST) Message-ID: <499DD029.8010608@gmail.com> Date: Thu, 19 Feb 2009 13:33:29 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090219.014758.23973.0@webmail04.vgs.untd.com> In-Reply-To: <20090219.014758.23973.0@webmail04.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:33:20 -0000 dyerbrookme@juno.com wrote: > decided by a handful of people at Linden Lab, IBM, OpenSim, and various members of the "Architectural Working Group" who have shown up to take over the topic. There is no broad user demand for interoperability; it is a concoction. > > However, we do have customers who are asking for interoperability, and are prepared to pay for it. That's why I'm here. If you're thinking of interoperability only in the sense of the Second Life grid, using Second Life protocols, serving Second Life customers, I don't think that's something the IETF should care much about. > So in that forced-march context, you have to look at what you are saying here. What platform-specific means to prevent content from being shared would be implemented in OpenSim, which has no intention of implementing the copy/mod/transfer regime of Second Life? It seems a contradiction in terms to expect that a platform eagerly seeking interoperability with another platform is then going to introduce "platform-specific means to prevent content from being shared. > > As I said, that's up to each platform vendor. The important thing is to enable the metadata to travel with the content, and to empower the sending side to make determinations about: a) who they interoperate with b) what specific content will and won't interoperate based on local policy. How Linden Labs decides to apply policy to content created by Linden Lab users is totally separate from how the interoperability specification should treat interoperable content, and should not be subject of discussion on this list (just like I won't discuss my customer specifics on this list). > I fail to see why you can't add the checkoff boxes copy/mod/transfer when implementing interoperability. Why do you oppose it? We all get that hackers can get around such regimes. I think you have misunderstood my proposal. My proposal is that the copy semantics should be explicitly part of the metadata, and should be enforced on the sending side, according to the EULA of that sending side. If an object is marked "do not copy" then the sending side won't send it, and the object won't interoperate. Exactly how each producer implements that is beside the scope of any standard, though. For example, if Linden Labs decides to apply a default policy of "interoperable" to all existing content, or to apply a default policy of "not interoperable," is entirely outside of the scope of any standard or standards discussion. It's a Linden-specific matter. In fact, I am arguing that we should enable exactly what you're describing! I don't understand how you belive I'm not. Sincerely, jw From lenglish5@cox.net Thu Feb 19 13:39:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4347628C0E8 for ; Thu, 19 Feb 2009 13:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.503 X-Spam-Level: X-Spam-Status: No, score=0.503 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce2DETzjrH15 for ; Thu, 19 Feb 2009 13:39:12 -0800 (PST) Received: from fed1rmmtao102.cox.net (fed1rmmtao102.cox.net [68.230.241.44]) by core3.amsl.com (Postfix) with ESMTP id 6AFB43A696A for ; Thu, 19 Feb 2009 13:39:12 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao102.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090219213926.DAIG13097.fed1rmmtao102.cox.net@fed1rmimpo02.cox.net>; Thu, 19 Feb 2009 16:39:26 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id HxfR1b00a4N6T0Q04xfSQx; Thu, 19 Feb 2009 16:39:26 -0500 X-Authority-Analysis: v=1.0 c=1 a=MthLulolaBoA:10 a=r-rcRZjYqYEA:10 a=Wajolswj7cQA:10 a=SPALM6HuDOnYMfswr5AA:9 a=fV748t9v8zoRkZ5JPNYA:7 a=ZoyRoD7LoQVbcx8d9GHYkrM8CBwA:4 a=zUBsD6tbDSsA:10 a=JPSgEe6QZ6_8XOwf:21 a=wiCF-pB4Ws51TmxW:21 X-CM-Score: 0.00 Message-ID: <499DD18D.2050104@cox.net> Date: Thu, 19 Feb 2009 14:39:25 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <20090219.011715.22395.1@webmail19.vgs.untd.com> <499DCD63.50201@gmail.com> In-Reply-To: <499DCD63.50201@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 48 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:39:13 -0000 Jon Watte wrote: > > Can we please stop the sound-byte-ing. We're not daring pioneers in > the larger sense -- virtual worlds have been around forever. There > have been many attempts over many years (Habitat, ActiveWorlds, The > Palace, all the VRML in the '90s...) , and interoperability between > dozens of vendors, including imagery and real-time voice, has been > done since the '80s. What's new is that the technology is being > popularized to more users. I suggest we focus on building features > that users want to pay for, because that's how things actually get > done on a larger scale. > > Btw: If it's a regular video stream, served by video streaming > servers, and watchable through a regular web browser, does that even > count as "bringint the meeting into the virtual world"? It's just > video streaming, not interactive. I agree it's useful and worthwhile, > but I really do wish that the sound-byting would end... > > Sincerely, > > jw > Well, the in-world meeting seemed productive to me. If you're not familiar with the Metanomics and Science Friday venues, you don't know how powerful a shared inworld/outworld experience can be even with minimal hardware (nothing as elaborate as what Qwaq apparently can do). Sharing text chat, a visual space (or more) and the ability to interact live in-world and RL is different than what your describing, at least it feels different to me. Croquet's app sharing appears to take it to a higher level in many ways, but the principle is the same. People get a sense of shared space better in 3D than simply looking at 2D, even if the shared space is a bunch of avatars watching a movie screen. And multi-world chat should rock if we get it working right. Lawson From tme@multicasttech.com Thu Feb 19 13:41:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E738B28C0E8 for ; Thu, 19 Feb 2009 13:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PfoVuv5u6Iw for ; Thu, 19 Feb 2009 13:41:06 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id D16DF3A6BB0 for ; Thu, 19 Feb 2009 13:41:05 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14712117; Thu, 19 Feb 2009 16:39:35 -0500 Message-Id: <8634BFA6-A729-4A73-BD38-81A794FB1896@multicasttech.com> From: Marshall Eubanks To: Rob Lanphier In-Reply-To: <499DCE41.1080209@lindenlab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 16:41:15 -0500 References: <499CC99D.8040302@cox.net><5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com><6A5E83A8-A7A1-4D38-8FAC-C04E360E47 77@lindenlab.com> <2A3D6CCD-58D1-4A01-9450-816839F05A4E@lindenlab.com> <499DC8C4.4040008@lindenlab.com> <3E082D73-D3B8-41E5-87C8-39791D6D8E9F@multicasttech.com> <499DCE41.1080209@lindenlab.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Jabber clients for mmox (Re: meeting minutes from today's ietf mmox simulcastingmeeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:41:07 -0000 On Feb 19, 2009, at 4:25 PM, Rob Lanphier wrote: > On 2/19/09 1:18 PM, Marshall Eubanks wrote: >> On Feb 19, 2009, at 4:01 PM, Rob Lanphier wrote: >> >>> On Mac, I've been able to get Adium to work (using my Google Talk >>> account). Colloquy was a bust (failed, and eventually crashed) >> >> On the Mac, what's wrong with iChat ? > > I wasn't able to get it to work. I tried that as well. On iChat File Go to Chat Room (AKA Command R) enter room name "mmox@jabber.ietf.org" make sure that you have right account selected (jabber, not AIM, etc) push "go" Marshall > > > Rob > >>> >>> >>> Adium instructions: >>> 1. Get a Jabber account on a publicly-connected server somewhere >>> (e.g. >>> Google) >>> 2. Log into the account >>> 3. Choose "Join Chat", select your Jabber account, then fill in >>> these >>> fields: >>> a. Chat room name: mmox >>> b. Server: jabber.ietf.org >>> 4. Join >>> >>> Since I already had a private IM exchange going, it added the chat >>> room >>> as a tab on the existing dialog box, not giving it focus. That >>> made me >>> think it wasn't working when it fact, people were saying "Hi Rob" >>> to me >>> without my knowing it. >>> >>> Since Adium uses libpurple (nee libgaim), I imagine that Pidgin (nee >>> Gaim) should work just fine for Win32 and Linux. >>> >>> Rob >>> >>> On 2/19/09 9:06 AM, Meadhbh Hamrick (Infinity) wrote: >>>> hmm... what client were you using? colloquy seems to have problems >>>> with both test@jabber.ietf.org as >>>> well >>>> as other jabber servers. >>>> >>>> and can you change the mmox wiki page you made to not reference >>>> mmox@jabber.ietf.org ? >>>> >>>> thx >>>> >>>> On Feb 19, 2009, at 5:38 AM, Morgaine wrote: >>>> >>>>> Excellent summary of a complex meeting, thanks Infinity. :-) >>>>> >>>>> On Thu, Feb 19, 2009 at 4:45 AM, Meadhbh Hamrick (Infinity) >>>>> > wrote: >>>>> >>>>> >>>>> * is the use of mmox@jabber.ietf.org >>>>> required? several mac users have >>>>> noted difficulty in using it. >>>>> >>>>> >>>>> I'll echo Dave's reply that jabber.ietf.org >>>> > >>>>> is working fine. Some of us were in there together last night for >>>>> tests in the "test" room. The "mmox" room hasn't yet been set >>>>> up or >>>>> enabled, but no doubt our AD can fix that. >>>>> >>>>> Looking at the Jabber room logs at http://jabber.ietf.org/logs/, >>>>> it's >>>>> worth noting that this facility is in use by many workgroups, well >>>>> over a dozen since the start of the year. I think that it would >>>>> serve MMOX well too, both during the forthcoming special >>>>> meetings and >>>>> subsequently when more interactive discussion is needed than email >>>>> allows. >>>>> >>>>> Morgaine. >>>>> _______________________________________________ >>>>> mmox mailing list >>>>> mmox@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmox >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> > From jwatte@gmail.com Thu Feb 19 13:42:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345323A6C12 for ; Thu, 19 Feb 2009 13:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3I8G68wK8Xy for ; Thu, 19 Feb 2009 13:42:43 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 190643A696A for ; Thu, 19 Feb 2009 13:42:43 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so503671ywh.49 for ; Thu, 19 Feb 2009 13:42:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=PxsuLlMIlWwPG+R2l5Q3Zox6fISrrIGq3AaC8LgftU0=; b=F0S3Sjnfczxp+r65ex2b1C3IkWAHvBZvluzAwLm+zXzoef3BB6cPpnitCSEG7a+1/t yFRzM9HsGgLI7+hL6y1aVebMi3QkC1mGbkUV+0UiKFsZnsQpvjF8CRVjsBGkg6mIi2nt 5l27OSr3/KqpfLZ0/Jp8Y+rPzW66pVgdov+58= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=f4gB2M9AlwsoYTlUSbReSl1ONA7qA49iExLE1pkeaYnBdfX5Eo0hVaUxRFSeRBRWTu 1qdAprqrDplDpyjcPVX0+IHqqQrJimfzhEJ9yq+9F6BWYqvtB22jhqkiCzo7J1wu0LU1 6OYdjmlbb7fVqTHAnoqX7kCdwDxEQwnwu4fyQ= Received: by 10.100.11.14 with SMTP id 14mr54184ank.89.1235079775870; Thu, 19 Feb 2009 13:42:55 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c23sm2378991ana.12.2009.02.19.13.42.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 13:42:55 -0800 (PST) Message-ID: <499DD25C.90003@gmail.com> Date: Thu, 19 Feb 2009 13:42:52 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:42:44 -0000 Morgaine wrote: > After perception of the world around you, travel is the next most > important form of interaction with the world. Teleport is simply > instantaneous travel, and teleport between grids is simply > instantaneous travel between worlds in different organizational > domains. How can it possibly be uninteresting and give little value > to travel to distant places in virtual space? ;-) > > I expect that you meant something /completely/ different to the > above. :-) Are we hitting an ambiguity in terminology of some kind > here? Let's think about this: I'm in my office. I'm connected to the office virtual world, where we do training, collaboration, meetings, etc. I have my office buddy list, I have my office document server, my office system conforms to all regulatory compliance necessary for my particular line of business (Sarbanes-Oxley, Freedom of Information Act, Clean Food Act or what have you). Maybe my system ties into corporate phone and video conferencing systems, too, allowing someone on a cell phone to participate in meetings, audio-only. Now, my buddy who uses Qwaq web forums and I want to meet. If my client were to disconnect from my office system, and re-connect to his Qwaq system, I'm suddenly losing all of the features provided by the office system, and my communication is now subject to his regulatory compliance (or not). This, in itself, is a non-starter for many larger organizations. But it doesn't end there! Because the Qwaq system is not connected to my "home" system, I can't have a sales guy out in the field call into this meeting using a cell phone, because the user I'm visiting doesn't have a cell phone gateway on his system. Or, if he did, the sales guy would have to hang up and dial another number, just because I teleported away. What if I have an interactive object I want to use? Qwaq can only run objects written to their API, which is largely Python. If mine is written for Wonderland, in Java, then the object won't work once I've re-connected my client to his system. That would be sad. What UI do I get when I'm connected to the Qwaq system? Should my client suddenly understand arbitrary UI systems from arbitrary providers? Do I have to learn a new UI for each system I want to connect to? Do you want to standardize the UI used by all clients of all systems? Interoperating between the back-end systems, at the semantic level, nicely side-steps most of these problems. In fact, each back-end system becomes a virtual world service provider much like an e-mail provider like GMail provides your e-mail service. Once you learn the capabilities of your given VWSP, you can use that interface and those capabilities no matter whom you visit. Note that visiting other people is still totally supported -- but, using this model, you get more capabilities, and the makers of virtual world software have to do less work, and agree on a smaller set of standard protocols. In my view, that's the only model that could end up working out well. Sincerely, jw From jwatte@gmail.com Thu Feb 19 13:45:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18DC73A69C3 for ; Thu, 19 Feb 2009 13:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-Bw1uovu6QC for ; Thu, 19 Feb 2009 13:45:25 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 240DD3A6881 for ; Thu, 19 Feb 2009 13:45:25 -0800 (PST) Received: by gxk22 with SMTP id 22so1734324gxk.13 for ; Thu, 19 Feb 2009 13:45:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=b2fqWYWe/tGSpH1S5zNMavuar8d/7XNzYpsfxhvt3iU=; b=iT5LUG0cpH0skk4R7Puxnr5vYGxlr+hYs7ReHuO0vlJT/46eFxMr2QuG7cL2nxu733 6gKpnv9xQV2wV+T7G9ouhL9jPrnPctC3rageE92zHjVDQpOfpdHR6rehN7G4T475s+G3 Cl9mHtjw4wpqXzQ37hUYlRco98ts8VsPlqV+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pyyjSDlztsXo6FyyCPl69ykuGCl0feZTTRBfCFIfeVlr41ljTjyiamnpNsGPC8p7yz GzYCwaQg7+ZKRlHZBYwVjbCUnQZNa5y0kpcx12K2X6vgsGqWrlvykvUddFeSnku3LoOF UuCN997gntBFARX5bS7iszPJ/RxbXCxTeU5NE= Received: by 10.100.231.6 with SMTP id d6mr23463anh.141.1235079938130; Thu, 19 Feb 2009 13:45:38 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b37sm2416772ana.37.2009.02.19.13.45.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 13:45:37 -0800 (PST) Message-ID: <499DD2FF.7040901@gmail.com> Date: Thu, 19 Feb 2009 13:45:35 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jesrad References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> <499CF445.1000705@gmail.com> <53cd6c2e0902190128t2c1df992safb425d3e43550a5@mail.gmail.com> In-Reply-To: <53cd6c2e0902190128t2c1df992safb425d3e43550a5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:45:26 -0000 Jesrad wrote: > The approach used in IEEE 1278 seems to differ radically from the > function OGP is assumed to permit, from a glance: as you said it lets > otherwise incompatible domains of simulation (call them grids) > exchange just the amount and type of information needed to remain > consistent between themselves. > > Transposed to a VW, this would mean you can use the SL client to > connect to an SL grid, then your current simulator connects you > through to other environments (WoW, Solipsis, etc.) and does the > "translation". If the "foreign" domain/grid does not support some > Agent Domain services or something else, then the "local" domain can > then provide its own as a substitute, while the client is tasked with > interpreting any native data that rides through (like 3D > representation and sound format). > That's about right. I think the focus on Second-Life specific proposals like OGP will not have success in a broader virtual world sense. While interesting from a technical point of view, I think it would be a mistake to assume that a vendor-neutral, open virtual world interoperability protocol would look anything like OGP. Sincerely, jw From jwatte@gmail.com Thu Feb 19 13:48:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C1A3A69C3 for ; Thu, 19 Feb 2009 13:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erjQXtJjiGw8 for ; Thu, 19 Feb 2009 13:48:32 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 1DECE3A6881 for ; Thu, 19 Feb 2009 13:48:32 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so505680ywh.49 for ; Thu, 19 Feb 2009 13:48:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Ttw9h7+DbMkbFkwCBvLP0k1D/Y5+6wGtyYy5Ya69UqA=; b=vnstYUlUcOmSDfT1hXKJIX7ipT6i9TCd3HfMaN6STV7VBLtSK0UMPR1zr5FxxWX+tn n+q43u31zpIFLgdZoKJq3c5ycv2Wtn95I6RT73EfB+8RIfaSE1fJjK0X+7Bk3bQfIa8k TnBlLFgMxaPhlbsdopc6cm2bLLS22p0czQFh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=r/4XEeDWX/ki87kBx9mHhHQET+zqjk/l02ZaMkQzVBUiiIgqBPLQ3g/KC6roxE8a4m uGBHTWIebhnqgryA0nSX7yD+QAw4vtwh0aRHsMhvY/n9mMrjm54H+r7D4cv9KSvi5Dqm VNhx+tQAuSgqepJ50ZEQSxBsFzBXA5UdReqfA= Received: by 10.101.68.19 with SMTP id v19mr87363ank.58.1235080124492; Thu, 19 Feb 2009 13:48:44 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c23sm1728587ana.32.2009.02.19.13.48.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 13:48:43 -0800 (PST) Message-ID: <499DD3B8.80900@gmail.com> Date: Thu, 19 Feb 2009 13:48:40 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jesrad References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <659848.26941.qm@web82607.mail.mud.yahoo.com> <499CA6DA.2010003@gmail.com> <53cd6c2e0902190338m5aad4ed2ia624e7826c17fb15@mail.gmail.com> In-Reply-To: <53cd6c2e0902190338m5aad4ed2ia624e7826c17fb15@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:48:33 -0000 Jesrad wrote: > The problem I see here is that in this model, internal scripts for > objects need to be accessed uniformly, too. When my car bumps into > something and is scripted for that event, both grids need to be > capable of calling the right event handler. > > You're assuming that every virtual world that wants to interoperate will use the Second Life scripting language, with the Second Life event model. This is not unlike how VRML was specified. It didn't work out so well :-) Sincerely, jw From lenglish5@cox.net Thu Feb 19 13:54:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 731473A69C3 for ; Thu, 19 Feb 2009 13:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgsJCgn1a-xn for ; Thu, 19 Feb 2009 13:54:38 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id CB85E28C22E for ; Thu, 19 Feb 2009 13:54:26 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090219215437.WCUE12838.fed1rmmtao103.cox.net@fed1rmimpo03.cox.net>; Thu, 19 Feb 2009 16:54:37 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id Hxuc1b00M4N6T0Q04xudF8; Thu, 19 Feb 2009 16:54:37 -0500 X-Authority-Analysis: v=1.0 c=1 a=MthLulolaBoA:10 a=r-rcRZjYqYEA:10 a=Wajolswj7cQA:10 a=NoAKp6exAAAA:8 a=kgeW_OXWEA8XT4kBqJ0A:9 a=1cplGQ-tQAYilMfW3gwA:7 a=Qr8pEwJphDxxk7c-rgFmLmP89ZUA:4 a=zUBsD6tbDSsA:10 a=B0cvAcWxpcAA:10 a=U-77vRNMeqxrjs12:21 a=0G24KBSCHV1xU278:21 X-CM-Score: 0.00 Message-ID: <499DD51C.70602@cox.net> Date: Thu, 19 Feb 2009 14:54:36 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <20090219.014758.23973.0@webmail04.vgs.untd.com> <499DD029.8010608@gmail.com> In-Reply-To: <499DD029.8010608@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:54:39 -0000 Jon Watte wrote: > dyerbrookme@juno.com wrote: >> decided by a handful of people at Linden Lab, IBM, OpenSim, and >> various members of the "Architectural Working Group" who have shown >> up to take over the topic. There is no broad user demand for >> interoperability; it is a concoction. >> >> > > However, we do have customers who are asking for interoperability, and > are prepared to pay for it. That's why I'm here. If you're thinking of > interoperability only in the sense of the Second Life grid, using > Second Life protocols, serving Second Life customers, I don't think > that's something the IETF should care much about. > >> So in that forced-march context, you have to look at what you are >> saying here. What platform-specific means to prevent content from >> being shared would be implemented in OpenSim, which has no intention >> of implementing the copy/mod/transfer regime of Second Life? It seems >> a contradiction in terms to expect that a platform eagerly seeking >> interoperability with another platform is then going to introduce >> "platform-specific means to prevent content from being shared. >> >> > > As I said, that's up to each platform vendor. The important thing is > to enable the metadata to travel with the content, and to empower the > sending side to make determinations about: > a) who they interoperate with > b) what specific content will and won't interoperate > based on local policy. How Linden Labs decides to apply policy to > content created by Linden Lab users is totally separate from how the > interoperability specification should treat interoperable content, and > should not be subject of discussion on this list (just like I won't > discuss my customer specifics on this list). > > >> I fail to see why you can't add the checkoff boxes copy/mod/transfer >> when implementing interoperability. Why do you oppose it? We all get >> that hackers can get around such regimes. > > I think you have misunderstood my proposal. My proposal is that the > copy semantics should be explicitly part of the metadata, and should > be enforced on the sending side, according to the EULA of that sending > side. If an object is marked "do not copy" then the sending side won't > send it, and the object won't interoperate. Exactly how each producer > implements that is beside the scope of any standard, though. For > example, if Linden Labs decides to apply a default policy of > "interoperable" to all existing content, or to apply a default policy > of "not interoperable," is entirely outside of the scope of any > standard or standards discussion. It's a Linden-specific matter. > > In fact, I am arguing that we should enable exactly what you're > describing! I don't understand how you belive I'm not. > > > Sincerely, The proposed meta-data for OGP has never been made explicit. All LL has said is that they won't violate the existing TOS for intellectual property and won't create a system to support the violation for existing IP. What future agreements/TOS/IPR LL will use aren't public knowledge. We've been debating which is the "next step" for OGP interop after getting something roughly looking like a permanent identity after teleporting between grids. We hit upon 2 main features: appearance and Instant Messaging between worlds, especially of the group variety. Trying to implement a SL-style group IM for 84,000 concurrent users has proven to be very difficult for LL, almost impossible. Evoking similar behavior (or even remotely similar) for avatars in a collection of hundreds or thousands of virtual worlds, is beyond comprehension at this point. Consistent appearance between worlds is merely a technical detail by comparison, and there are many obvious approaches to solving it (whether they are workable or not is another question, of course) Lawson From jwatte@gmail.com Thu Feb 19 13:59:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0CBC3A696A for ; Thu, 19 Feb 2009 13:59:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrAZ2-nfNF5z for ; Thu, 19 Feb 2009 13:59:08 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id C84DD3A6807 for ; Thu, 19 Feb 2009 13:59:07 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so323962ana.4 for ; Thu, 19 Feb 2009 13:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=liuefEhE7IwSAdPLYkOipW/SD2SYGn/atAp0AZbkGzM=; b=gq08DUw+QEmiGycXuQyHcK1zpJUdA1Oij5jdlOhEYxbETGELdDkoF010XAxJRey9oA oTRYTejnHrt16FtiynoJCBMyyRln3leNr4AwuYExCSbfJlW9ojm/FAreerzFo8tra5E+ f7dpJu7LQierUDUPSYMwpvHs+HQBwpFyEYKwg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FvG0GiBGlgBvcJvY1QP/O3r1PegjVAibkL6jHS2t11xYoRpfc2yGzbR640NA2A1aWZ sSPodSCPxJJL3ybn0s6WlP2AHXLiRp4pUG+0MRDcix1jVKk2QjLd64nOS3YClxaUjjRE xBVIg9Xww+3WPyUNrrPqOunB8bHjR7Pe/brX0= Received: by 10.100.168.18 with SMTP id q18mr141738ane.7.1235080759667; Thu, 19 Feb 2009 13:59:19 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c14sm2562061ana.21.2009.02.19.13.59.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 13:59:18 -0800 (PST) Message-ID: <499DD634.3050101@gmail.com> Date: Thu, 19 Feb 2009 13:59:16 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:59:09 -0000 Morgaine wrote: > Unfortunately, that's non-scalable, particularly along the complexity > axis. > I disagree. See below: > It works fine in your example because you have only two parties > wishing to share a space and hence there is only one space to > simulate, but try to extrapolate from there to see where it leads. If > your organization A has N users, and those N users wish to take part > in N different worlds (which is asymptotically likely if N << total > number of worlds), then your organization A must now simulate N > different worlds. For large N, this places a colossal load on > organization A, even if the individual shared spaces are minimally > populated. To coin a common phrase by analogy, you're undertaking to > "simulate the Internet". ;-) > Not at all. Note that the actual simulation of each object happens on the "home" sim server of that object. Only telemetry is sent to other servers. I'm assuming forwarding telemetry is "cheap" whereas simulation of objects is "expensive" -- previous technical history shows that that is true. Thus, a virtual world service provider will undertake to provide simulation capacity for a user and N objects, and that's how many objects the user can put into the world. Some servers might be on an "all you can eat, and damn the lag" plan; others may be very metered and charge by the CPU-second. That is all up to policy, not mechanism. If people from 8 different virtual world service providers meet in one physical space ("my room"), then there will be 8 copies of "my room" temporarily running on the greater internet, but each of those copies just simulate one user in that room. The cost of physical space ("my room") is very cheap, compared to the cost of managing an active, simulated user. Each server will connect to 7 peer servers, and send the telemetry data for the one user it simulates, and receive interactions from those 7 peers for things that affect that one user. > What's more, very few platform optimizations will be possible since > the N worlds are all different, and this also means that the > scalability of each shared space will be severely constrained as > well. And as if that were not bad enough, the N worlds that your > users visit tomorrow will not necessarily be today's N worlds, so for > (N << total number of worlds) your local cache will need to grow > almost without limit if it's to work at all. > Luckily, bandwidth between well connected servers is not a problem. You can purge the cache when it gets big, and just pull down the asset when you need it. Compare to YouTube, or MSN, or any other large service provider. That's not a problem. > Even if organization A's machinery were powerful enough to support N > radically different worlds through shared-space simulations though, > they still couldn't do it, because in the general case the simulation > code for a given world will not be available. The world simulation is > the "secret sauce" of many virtual worlds, and from a business > perspective it is quite likely to be their product differentiator and > they will be loathe to share it. But even if it were freely > available, the portability of one organization's simulation code to > another organization's machinery is far from guaranteed with today's > software technology, not to mention the management of upgrades for > something this complex across organization boundaries. > My proposal specifically says that simulation code stays on the home server, and only interactions (the "result" of simulation) is shared to other servers. I agree that no other system can work. > Foreign world simulations never need to be supported. > I agree! If you think my proposal requires that, I don't understand how that came across. Could you find the part where you thought I was suggesting that and point it out, so I could clarify it? Sincerely, jw From jwatte@gmail.com Thu Feb 19 14:10:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77B033A68EC for ; Thu, 19 Feb 2009 14:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, GB_AUTODESK=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPfyz6wPQ7mb for ; Thu, 19 Feb 2009 14:10:35 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 36FA83A6807 for ; Thu, 19 Feb 2009 14:10:35 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so513512ywh.49 for ; Thu, 19 Feb 2009 14:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=IhEGel+B9MbcDe1+7VypqYbV9WL9B8s3OZP2EwvzjvI=; b=pYjdHn/dBsuh063G2mZROtJ4zn+dvQUdCak4WIzcM1+2+guXygZlXEJDmNIS/T+9Ts 5KGkk1At4uW+oI8ZP6pupgADNi6v3pSrvY1ECgK+LwNWn4RfPuI0lOSoujIM0fBdXiCe zPhRRnYXAgy8jWro5Igd/ZrW/lXh6n4CAgy48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=h4evu7lnNL7gDVwpLgJE6xm+B3s8kG8sdQtBD3f2dWja/NufO6kxM+wehg91OLOUcN k32SK3pjSvrSrtj3fDk+aEcupoN2xnT1PJfDy2hr5Lv+zjz5BD6DxFqY9f0Z64U5bM65 /5GhRPZd/52ezFHeemiT78ECzXQXNJbJZ2A2g= Received: by 10.100.122.12 with SMTP id u12mr111699anc.78.1235081448826; Thu, 19 Feb 2009 14:10:48 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c23sm2419234ana.12.2009.02.19.14.10.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 14:10:47 -0800 (PST) Message-ID: <499DD8E5.4020205@gmail.com> Date: Thu, 19 Feb 2009 14:10:45 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Hurliman, John" References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE4C3@rrsmsx506.amr.corp.intel.com> <499CF3F7.1010304@gmail.com> <62BFE5680C037E4DA0B0A08946C0933D501FE739@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FE739@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] The Story So Far... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:10:36 -0000 Hurliman, John wrote: >> 1) When I am logged into a virtual world, it's usually for a reason. For >> me, it's work -- my virtual world allows me to cooperate with remote >> workers, visualize 3D data, and have meetings that are more effective >> and cheaper than conference calls. (Customers love "cheaper" :-) If I >> > > I visit my internal homepage at intel.com and browse several other parts of the web at the same time. It doesn't require any established trust between intel.com and the rest of the web. > > But the virtual world is not the web. The virtual world requires interaction. It requires simple things like microphone focus. It requires complex things like 3D graphics and physical simulation. And, most importantly, the data changes in real time. I can see a distant future where you may be browsing multiple virtual worlds at a time, and all of those issues are solved through "infinite compute power" and smart user interfaces for things like focus. But consider the local services: What if you have a server-side record/playback function you use for archival purposes? If you want to compare to the 2D web (which is a poor comparison in my experience): You can view the local server as a web cache, firewall and e-mail server, all rolled into one. >> 2) Object behavior is not portable. One system may use SecondLife Script >> version 2.3 for its objects. Another may use Java Runtime 1.5.6. A third >> may use Visual C++ 9.0 linkable libraries. >> >> > > Just as some websites are powered with PHP, some use Java backends, and some have bits written in C++? > > But that's the whole point! In web 2.0, you have two different web sites talking to each other, rather than having the client do the work. My suggestion is analogous: When object X is implemented to run on technology Y, it is always run by a server using technology Y; it's not transferred to technology Z just because I happen to be browsing the main frame of my page on technology Z. Trying to translate the scripting between Y and Z, or enforcing that things are always implemented using Y, is a losing proposition. >> 3) If you "grid hop" to another location, you have to have a client that >> can connect to whatever server protocol that location is using. Writing >> a "universal client" has proven to be quite quixotic for two reasons: a) >> Any real system will have to have a "home protocol" anyway to provide >> functionality not provided for in the standard, and b) re-implementing >> virtual world presence for a client as a separate channel only to use >> for interoperability isn't a good idea. >> >> > > I agree that the universal client solution is not an answer to interoperability. However, this seems to just be pushing the problem back to the server. Instead of a universal client we'll have a universal server that can do universal protocol translation. What if this universal server was ran on localhost? Would it become a universal client? > > In effect, yes. When I keynoted the IEEE MMVR workshop last year, I actually showed a possible peer-to-peer topology, as sitting on top of such as standard. However, the point is that, for the cases where peer-to-peer is not desirable (which we can all agree are important, too), the server-translated system provides for capabilities that the client-translated system does not. > I think it's arguable whether merging the view of two worlds together has higher value than teleporting presence and content between worlds. > > Well, let's argue that, then. I know that offline translation of content is worth a lot for our customers, but we have basically solved that problem by using a COLLADA tool chain, and supporting most of the Autodesk and Multigen formats. However, trying to teleport an entire object (with behavior) in real time will never actually work across a larger, interoperable virtual world, for the same reason you pointed out: some are implemented in C#, others in Java, and yet others in some language you've never heard of. If you're only interested in interoperating between worlds that support the Second Life scripting language, then I think the SL AWG is the place for that discussion. My point is that solving the back-end problem is actually less work, and provides both a better user experience, and more end-user capabilities, than "teleporting" between worlds. Note that the base capability of visiting someone else in their environment is provided by both proposals. It's after that that the differences start to show. Sincerely, jw From jwatte@gmail.com Thu Feb 19 14:14:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6654C28C209 for ; Thu, 19 Feb 2009 14:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vVvy7dFOqH2 for ; Thu, 19 Feb 2009 14:14:55 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 55DB328C138 for ; Thu, 19 Feb 2009 14:14:55 -0800 (PST) Received: by gxk22 with SMTP id 22so1772003gxk.13 for ; Thu, 19 Feb 2009 14:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xW/q/aIMTDu8KS8YpXjn3d72vW6iw/8/6sdWIy32BYo=; b=hVV+unL6xLbVBFwqy8Urb1BAU/3vP/O5eW9iHiVPh7KCBLqsJIg7Nky1vYOOu3+EUL 0WMFV6SLhxRFy4Dq+59Ma5ZTdHK6XHFzXMutdvTm3C4QNp/8do6PnRw0vrd2nmYCjpg2 ZNWKeLhg6y666YZcXRzLT3WFJv9jBSzhtjrFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qhxmTl58SOS1rxxD5F2k9dZEgBMF7CC3c6JR7pjChZZSB4uvL2etirhquRg2P3gh3y EoMl6bW4JCGUEhGG6JCHQJrErCbg0qub87O+D1s5qxRS3RttVHmtZ5Egxmw2G4hvIaql 6I9/8YGjR9IgbxMFZF9GGnUEsI/it6KWiPaOM= Received: by 10.100.132.14 with SMTP id f14mr99772and.107.1235081708231; Thu, 19 Feb 2009 14:15:08 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c14sm3262309ana.41.2009.02.19.14.15.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 14:15:04 -0800 (PST) Message-ID: <499DD9E6.1080106@gmail.com> Date: Thu, 19 Feb 2009 14:15:02 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:14:56 -0000 Morgaine wrote: > However, if that's the case then I don't understand the point being > made, because shared-spaces seems to be a "teleport only" > architecture. The only means by which a user can go from one shared > space to another is by teleport, since shared spaces do not have > topological relationships to each other, from your description. > They may or may not -- that's up to each hosting system. If the hosting system has the geometry for the Earth as its reference, then I get to Paris from London by swimming, and then walking. If it turns out that only the Eiffel Tower observation deck is currently being shared to another system, then only when I'm in that part would I be visible to outside users. Clearly, you can't enforce a single topology for all systems, but you still want to allow users of one system to be able to interact with people in other systems, even if they have different topologies, so I think topology has to be system dependent, and not specifically part of the specification (other than as used to identify the shared coordinate space to use for the session). > If you ignore the local simulation for a moment, then what happens > when one of your users changes from one local shared space to one > belonging to a different provider is very similar in implementation to > the usual separate worlds case: the agent appears in the space at the > remote end. Adding a local simulation on top of that doesn't really > change the matter. That's teleport between grids, plus a local > accelerator. > > And perceptually from the users' perspective, the model suggests that > they too see a teleport occurring every time that they change their > shared space to one operated by a different world provider. This > looks like perfectly ordinary "teleport between grids" to them too. The difference starts after that. How can you make sure that the features and user interface that the local user is used to, is still available after going into the other space? How can you make sure that objects that the local user own can be used while in the other space? How can you avoid having to dictate both user interface and simulation language for any participating system? Sincerely, jw From infinity@lindenlab.com Thu Feb 19 14:15:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2053A6AB3 for ; Thu, 19 Feb 2009 14:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 342YN2ApjeMQ for ; Thu, 19 Feb 2009 14:15:06 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 83E7A3A68EC for ; Thu, 19 Feb 2009 14:15:06 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 84A443DBC45A; Thu, 19 Feb 2009 14:15:20 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Marshall Eubanks In-Reply-To: <8634BFA6-A729-4A73-BD38-81A794FB1896@multicasttech.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 14:15:20 -0800 References: <499CC99D.8040302@cox.net><5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com><6A5E83A8-A7A1-4D38-8FAC-C04E360E47 77@lindenlab.com> <2A3D6CCD-58D1-4A01-9450-816839F05A4E@lindenlab.com> <499DC8C4.4040008@lindenlab.com> <3E082D73-D3B8-41E5-87C8-39791D6D8E9F@multicasttech.com> <499DCE41.1080209@lindenlab.com> <8634BFA6-A729-4A73-BD38-81A794FB1896@multicasttech.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Jabber clients for mmox (Re: meeting minutes from today's ietf mmox simulcastingmeeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:15:07 -0000 okay. i've tried this. iChat gives no indication i've joined a chat room. it gives no error to say i have not entered a chat room. it provides no UI for me to enter text (which is what i'm assuming it's supposed to do.) i've been trying this with a livejournal account and my two gtalk accounts. On Feb 19, 2009, at 1:41 PM, Marshall Eubanks wrote: > > On Feb 19, 2009, at 4:25 PM, Rob Lanphier wrote: > >> On 2/19/09 1:18 PM, Marshall Eubanks wrote: >>> On Feb 19, 2009, at 4:01 PM, Rob Lanphier wrote: >>> >>>> On Mac, I've been able to get Adium to work (using my Google Talk >>>> account). Colloquy was a bust (failed, and eventually crashed) >>> >>> On the Mac, what's wrong with iChat ? >> >> I wasn't able to get it to work. I tried that as well. > > On iChat > > File > Go to Chat Room (AKA Command R) > enter room name "mmox@jabber.ietf.org" > make sure that you have right account selected (jabber, not AIM, etc) > push "go" > > Marshall > >> >> >> Rob >> >>>> >>>> >>>> Adium instructions: >>>> 1. Get a Jabber account on a publicly-connected server somewhere >>>> (e.g. >>>> Google) >>>> 2. Log into the account >>>> 3. Choose "Join Chat", select your Jabber account, then fill in >>>> these >>>> fields: >>>> a. Chat room name: mmox >>>> b. Server: jabber.ietf.org >>>> 4. Join >>>> >>>> Since I already had a private IM exchange going, it added the >>>> chat room >>>> as a tab on the existing dialog box, not giving it focus. That >>>> made me >>>> think it wasn't working when it fact, people were saying "Hi Rob" >>>> to me >>>> without my knowing it. >>>> >>>> Since Adium uses libpurple (nee libgaim), I imagine that Pidgin >>>> (nee >>>> Gaim) should work just fine for Win32 and Linux. >>>> >>>> Rob >>>> >>>> On 2/19/09 9:06 AM, Meadhbh Hamrick (Infinity) wrote: >>>>> hmm... what client were you using? colloquy seems to have problems >>>>> with both test@jabber.ietf.org as >>>>> well >>>>> as other jabber servers. >>>>> >>>>> and can you change the mmox wiki page you made to not reference >>>>> mmox@jabber.ietf.org ? >>>>> >>>>> thx >>>>> >>>>> On Feb 19, 2009, at 5:38 AM, Morgaine wrote: >>>>> >>>>>> Excellent summary of a complex meeting, thanks Infinity. :-) >>>>>> >>>>>> On Thu, Feb 19, 2009 at 4:45 AM, Meadhbh Hamrick (Infinity) >>>>>> > wrote: >>>>>> >>>>>> >>>>>> * is the use of mmox@jabber.ietf.org >>>>>> required? several mac users have >>>>>> noted difficulty in using it. >>>>>> >>>>>> >>>>>> I'll echo Dave's reply that jabber.ietf.org >>>>> > >>>>>> is working fine. Some of us were in there together last night >>>>>> for >>>>>> tests in the "test" room. The "mmox" room hasn't yet been set >>>>>> up or >>>>>> enabled, but no doubt our AD can fix that. >>>>>> >>>>>> Looking at the Jabber room logs at http://jabber.ietf.org/ >>>>>> logs/, it's >>>>>> worth noting that this facility is in use by many workgroups, >>>>>> well >>>>>> over a dozen since the start of the year. I think that it would >>>>>> serve MMOX well too, both during the forthcoming special >>>>>> meetings and >>>>>> subsequently when more interactive discussion is needed than >>>>>> email >>>>>> allows. >>>>>> >>>>>> Morgaine. >>>>>> _______________________________________________ >>>>>> mmox mailing list >>>>>> mmox@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmox >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> _______________________________________________ >>>>> mmox mailing list >>>>> mmox@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmox >>>>> >>>> >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>> >> > From jwatte@gmail.com Thu Feb 19 14:36:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6A13A69F6 for ; Thu, 19 Feb 2009 14:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTiWh0Vpn8+8 for ; Thu, 19 Feb 2009 14:36:19 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 540B83A69DD for ; Thu, 19 Feb 2009 14:36:19 -0800 (PST) Received: by gxk22 with SMTP id 22so1796581gxk.13 for ; Thu, 19 Feb 2009 14:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=wYRcLOhBN5nE33zAcvymrDvK671W+eiiO3zwen+RXWg=; b=TkggNJTGhN7DfacWFamULXZh4GBO1owgLzXhGlXizBFSj+vNmpVp4TgsIBnDpucIxC K0XuwTBo+HTQYjN99n8casUS4t+imttCHT3r8EL75J5fZUhw6tlgiP1zXYlknAt4ExxX cI7zWubOpRF96QO+dwrBykQqXwTC+2wIGEJFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=eYMEbqwaHx/GdJxmpe76c0oDVWHqB/J8bWT30DLIjnkoXSyIlm6S0wrtSljj9lVLSc 7RkP+ulBQSaqkFbPpo+KKPk4QZtmgmPzi9xNEjL16Pi+0QumF75T38zBpVE6t86GYELR oAOHheJRZ1kXPsvXiyfUiNhEdZP634+Kg6V9I= Received: by 10.100.109.13 with SMTP id h13mr57231anc.21.1235082992206; Thu, 19 Feb 2009 14:36:32 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d38sm3485654and.29.2009.02.19.14.36.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 14:36:31 -0800 (PST) Message-ID: <499DDEED.2000109@gmail.com> Date: Thu, 19 Feb 2009 14:36:29 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> In-Reply-To: <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:36:20 -0000 Meadhbh Hamrick (Infinity) wrote: > * we're about application layer wire protocol > * we're about interoperability between current or near future > implementations Implementations of what? OLIVE has a gateway in use by various customers since 2005. It uses DIS, HLA, and a variety of other protocols, depending on what system it's talking to. I'd be happy to talk more about that system, and how that can grow. It's a currently implemented system in commercial use, which seems like a good place to start. Or do you want to use the Second Life system just because it's Second Life, even if it's not currently implemented or in current commercial use? > * we're NOT blessing Second Life's existing protocol as an official > standard > * it's entirely possible application developers using MMOX protocols > would need to define an "interoperability profile," which defines how > MMOX applies to their application. > * in other words, "we define mechanism, not policy." That's like saying "E-mail exchange should be done using MIME encoded data on port 25" without specifying SMTP. That's neither interoperable nor vendor neutral. Sincerely, jw From jwatte@gmail.com Thu Feb 19 14:41:42 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD59728C21C for ; Thu, 19 Feb 2009 14:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZqrycLBcP9V for ; Thu, 19 Feb 2009 14:41:42 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id E66813A67C1 for ; Thu, 19 Feb 2009 14:41:41 -0800 (PST) Received: by gxk22 with SMTP id 22so1802352gxk.13 for ; Thu, 19 Feb 2009 14:41:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=jMxnswgFbMhlaLBUh0Lqcw5lvMIZ10SkU7yb2AEvKY8=; b=LFUU29mTgTTVh/974v7o5PqpElOsUoyZs8vzTPkIorXSaXlHZmLHkeapObsqbawnBi mHwBLfyE+jaRH9uvr2A6qyaA7bRoblWWaPShiZ2Em6ImsFBfehY82q0MBnH2RCRQrCp2 B3dItd/ZlKu+kUsB/NbwNLyj/YqXmU11ElIU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pwrFlMCpRPUUJkt3eNI9lvfdcgFLLrh25UdojKTRaRW2ViMGKE+29U59NatcAQlO8A uf13xL2EvRvssTLY+VkLNeUwjs5uXp0yEXdLdM53VTyGApQUYvHKC3Eto6axVbO44O+F R3zD3EGE+hMZzSag6WEfWJX6chryOx3cODtFQ= Received: by 10.100.3.13 with SMTP id 13mr170704anc.74.1235083314894; Thu, 19 Feb 2009 14:41:54 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c9sm1655484ana.13.2009.02.19.14.41.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 14:41:54 -0800 (PST) Message-ID: <499DE02F.9050903@gmail.com> Date: Thu, 19 Feb 2009 14:41:51 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <20090219.011715.22395.1@webmail19.vgs.untd.com> <499DCD63.50201@gmail.com> <499DD18D.2050104@cox.net> In-Reply-To: <499DD18D.2050104@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 48 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:41:42 -0000 Lawson English wrote: > Well, the in-world meeting seemed productive to me. If you're not > familiar with the Metanomics and Science Friday venues, you don't know > how powerful a shared inworld/outworld experience can be even with > minimal hardware (nothing as elaborate as what Qwaq apparently can do). > Being that our company sells virtual world systems based around the power of virtual world meetings, and we hold all our corporate status meetings in our world, I would say I know very well how powerful it is. I'm one of the biggest advocates of using virtual worlds! However the specific case I was talking about was the perceived attempt to frame a discussion about setting up a live video stream from an upcoming meeting as something that's somehow groundbreaking and new. I find that trying to sound-byte things like that end up confusing outside observers, and obscuring the inside work that's really going on. Sincerely, jw From tme@multicasttech.com Thu Feb 19 14:43:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F0B28C22E for ; Thu, 19 Feb 2009 14:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P8FsJqCcDi7 for ; Thu, 19 Feb 2009 14:43:23 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 4394F28C216 for ; Thu, 19 Feb 2009 14:43:23 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14712642; Thu, 19 Feb 2009 17:41:51 -0500 Message-Id: <9F7E6441-6BA9-4FFF-9494-4FBE1BD8ED51@multicasttech.com> From: Marshall Eubanks To: "Meadhbh Hamrick (Infinity)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 17:43:25 -0500 References: <499CC99D.8040302@cox.net><5B7AC832-F851-4103-AB45-9FF2A536CCD5@multicasttech.com><6A5E83A8-A7A1-4D38-8FAC-C04E360E47 77@lindenlab.com> <2A3D6CCD-58D1-4A01-9450-816839F05A4E@lindenlab.com> <499DC8C4.4040008@lindenlab.com> <3E082D73-D3B8-41E5-87C8-39791D6D8E9F@multicasttech.com> <499DCE41.1080209@lindenlab.com> <8634BFA6-A729-4A73-BD38-81A794FB1896@multicasttech.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Jabber clients for mmox (Re: meeting minutes from today's ietf mmox simulcastingmeeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:43:24 -0000 On Feb 19, 2009, at 5:15 PM, Meadhbh Hamrick (Infinity) wrote: > okay. i've tried this. iChat gives no indication i've joined a chat > room. it gives no error to say i have not entered a chat room. it > provides no UI for me to enter text (which is what i'm assuming it's > supposed to do.) > Are you sure you are online with jabber ? (To add, go to preferences, add the jabber account by clicking on the "+".) I have hide it "hide" one window behind another on rare occasions, but the window has a UI for entering text - a text box, exactly as for any other IM. If you are not on line, the text box goes away. If you have joined the room : Under "Accounts" you should see a check mark by your jabber account name Under "Window" you should see "Chatting in mmox@jabber.ietf.org" Regards Marshall > i've been trying this with a livejournal account and my two gtalk > accounts. > > On Feb 19, 2009, at 1:41 PM, Marshall Eubanks wrote: > >> >> On Feb 19, 2009, at 4:25 PM, Rob Lanphier wrote: >> >>> On 2/19/09 1:18 PM, Marshall Eubanks wrote: >>>> On Feb 19, 2009, at 4:01 PM, Rob Lanphier wrote: >>>> >>>>> On Mac, I've been able to get Adium to work (using my Google Talk >>>>> account). Colloquy was a bust (failed, and eventually crashed) >>>> >>>> On the Mac, what's wrong with iChat ? >>> >>> I wasn't able to get it to work. I tried that as well. >> >> On iChat >> >> File >> Go to Chat Room (AKA Command R) >> enter room name "mmox@jabber.ietf.org" >> make sure that you have right account selected (jabber, not AIM, etc) >> push "go" >> >> Marshall >> >>> >>> >>> Rob >>> >>>>> >>>>> >>>>> Adium instructions: >>>>> 1. Get a Jabber account on a publicly-connected server >>>>> somewhere (e.g. >>>>> Google) >>>>> 2. Log into the account >>>>> 3. Choose "Join Chat", select your Jabber account, then fill in >>>>> these >>>>> fields: >>>>> a. Chat room name: mmox >>>>> b. Server: jabber.ietf.org >>>>> 4. Join >>>>> >>>>> Since I already had a private IM exchange going, it added the >>>>> chat room >>>>> as a tab on the existing dialog box, not giving it focus. That >>>>> made me >>>>> think it wasn't working when it fact, people were saying "Hi >>>>> Rob" to me >>>>> without my knowing it. >>>>> >>>>> Since Adium uses libpurple (nee libgaim), I imagine that Pidgin >>>>> (nee >>>>> Gaim) should work just fine for Win32 and Linux. >>>>> >>>>> Rob >>>>> >>>>> On 2/19/09 9:06 AM, Meadhbh Hamrick (Infinity) wrote: >>>>>> hmm... what client were you using? colloquy seems to have >>>>>> problems >>>>>> with both test@jabber.ietf.org as >>>>>> well >>>>>> as other jabber servers. >>>>>> >>>>>> and can you change the mmox wiki page you made to not reference >>>>>> mmox@jabber.ietf.org ? >>>>>> >>>>>> thx >>>>>> >>>>>> On Feb 19, 2009, at 5:38 AM, Morgaine wrote: >>>>>> >>>>>>> Excellent summary of a complex meeting, thanks Infinity. :-) >>>>>>> >>>>>>> On Thu, Feb 19, 2009 at 4:45 AM, Meadhbh Hamrick (Infinity) >>>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> * is the use of mmox@jabber.ietf.org >>>>>>> required? several mac users have >>>>>>> noted difficulty in using it. >>>>>>> >>>>>>> >>>>>>> I'll echo Dave's reply that jabber.ietf.org >>>>>> > >>>>>>> is working fine. Some of us were in there together last night >>>>>>> for >>>>>>> tests in the "test" room. The "mmox" room hasn't yet been set >>>>>>> up or >>>>>>> enabled, but no doubt our AD can fix that. >>>>>>> >>>>>>> Looking at the Jabber room logs at http://jabber.ietf.org/ >>>>>>> logs/, it's >>>>>>> worth noting that this facility is in use by many workgroups, >>>>>>> well >>>>>>> over a dozen since the start of the year. I think that it would >>>>>>> serve MMOX well too, both during the forthcoming special >>>>>>> meetings and >>>>>>> subsequently when more interactive discussion is needed than >>>>>>> email >>>>>>> allows. >>>>>>> >>>>>>> Morgaine. >>>>>>> _______________________________________________ >>>>>>> mmox mailing list >>>>>>> mmox@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mmox >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> mmox mailing list >>>>>> mmox@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/mmox >>>>>> >>>>> >>>>> _______________________________________________ >>>>> mmox mailing list >>>>> mmox@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmox >>>> >>> >> > From cs@comlounge.net Thu Feb 19 15:04:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66B223A69BB for ; Thu, 19 Feb 2009 15:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvgVeWXMIt6k for ; Thu, 19 Feb 2009 15:04:58 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id E99233A6C17 for ; Thu, 19 Feb 2009 15:04:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 1EA5B6F404D; Fri, 20 Feb 2009 00:05:11 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hs28sdirnuYZ; Fri, 20 Feb 2009 00:05:09 +0100 (CET) Received: from [192.168.178.40] (pD9EBCC3B.dip.t-dialin.net [217.235.204.59]) by post.comlounge.net (Postfix) with ESMTP id 51C231CE021B; Fri, 20 Feb 2009 00:05:09 +0100 (CET) Message-ID: <499DE5A4.50705@comlounge.net> Date: Fri, 20 Feb 2009 00:05:08 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Hurliman, John" References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> <62BFE5680C037E4DA0B0A08946C0933D501FE800@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FE800@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 23:04:59 -0000 Hurliman, John schrieb: > That is the identity proposal I'm working on. OpenID + OpenID Token Exchange* + OpenID Attribute Exchange == VW Identity Service. > > * OAuth was specifically designed for a three legged scenario, and when you start adding in more services such as content, messaging, voice, etc. it no longer becomes feasible. OpenID Token Exchange solves this problem nicely though. Can you elaborate what the specific problem with OAuth is? Is it that you'd need to authorize each and every service as a user? (the same problem is coming up on the web as well though if you think about data in all sorts of places you might want to give somebody access to) And what are you planning to use Attribute Exchange (AX) for? We discussed using this in the DataPortability Group a while back for storing the URL to your service catalogue that way but the problem was a bit lack of adoption. I also tried to do some tests with myopenid but it seemed that I couldn't store new fields. If it's for profile retrieval the OpenSocial REST API is IMHO a better fit as it's a) easier to implement and b) more discussed and already adopted by e.g. myspace (and yahoo is talking about it). -- Christian > > John > >> -----Original Message----- >> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >> Mark P.McCahill >> Sent: Thursday, February 19, 2009 10:27 AM >> To: mmox@ietf.org >> Subject: [mmox] where is identity @ in all this? >> >> These worlds are fundamentally social environments. I would suggest >> starting with interoperability for federated identity and presence. >> >> At a minimum I want to know which worlds my buddies are currently >> playing in, and be able to chat with them, and be able to chat with >> people outside the virtual worlds. If there are any ambitions toward >> integrating presence in virtual worlds with more traditional audio, >> video, and text communications, then SIP and XMPP-based presence would >> be worth considering rather than re-inventing these functions. >> >> Most virtual worlds act as both metaverse service providers (MSP) and >> identity providers. This is a mistake. >> >> Tightly coupling the MSP and identity provider functions is why I have >> to keep telling people that Mark McCahill is named Mysterio Sinister >> in Second Life - I can't easily be mccahill@duke.edu because Second >> Life doesn't use external federated identity providers. Then when I go >> to one of the OpenSim worlds, I need to create another account, and >> hope that nobody has signed up for Mysterio Sinister before I got there. >> >> Requiring avatars to create a new account/password at each of the >> different metaverse service providers is not a very appealing >> prospect. Why aren't we addressing the federated identity/presence >> issue now? There are a number of existing approaches that could be >> relatively easily adopted across different technologies and set the >> stage for deeper interoperability down the road. >> >> To make any real progress, we need agreement about standards for >> accepting identities provided by other virtual worlds. Even better, >> how about something that is not a virtual world (OAuth, OpenID, >> Shibboleth all come to mind) an option as an identity provider? >> Solving this problem is a prerequisite for making any real progress >> toward allowing free movement across worlds. >> >> Why aren't we talking about standards for >> >> name@identity_provider >> >> authentication which could be used across worlds? >> >> >> >> Mark McCahill >> OpenCroquet/Cobalt >> >> >> On Feb 18, 2009, at 7:34 PM, Jon Watte wrote: >>> So, what is an avatar anyway? I think it has one or more meshes >>> (that are not standard), draped over a skeleton (that is not >>> standard), with one or more textures applied (that are not >>> standard). Avatars also represent users, which have identity. >>> Avatars can move (physically, with collision detection), animate >>> (interactions, emotes), voice communicate and text chat. >>> >>> If you can send that information ([identity, mesh, texture, >>> skeleton] as set-up, and [movement, animation, interactions, voice >>> and text chat] at runtime) then do you have an interoperable avatar? >>> And, if so, what separates an avatar from another animated, movable >>> object? Could the same way that avatars are interoperating be used >>> to interoperate other simulated objects? From a remote systems' >>> point of view, there's not that much difference between a human- >>> driven avatar, and a tumbling rock -- the remote system can't be >>> expected to run the simulation for either one, so it needs to have >>> that stream of behavior to represent it. >>> >>> As far as I know Wonderland, Qwaq, Multiverse and other possible >>> adopters, the above representations maps fairly straightforward to >>> their systems, although any system will have to expect to write >>> adaption code to accept "arbitrary" external meshes as avatars. >>> >>> Sincerely, >>> >>> jw >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From lenglish5@cox.net Thu Feb 19 15:39:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E4D3A6AF8 for ; Thu, 19 Feb 2009 15:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.414 X-Spam-Level: X-Spam-Status: No, score=0.414 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76A+OdwSUGMc for ; Thu, 19 Feb 2009 15:39:39 -0800 (PST) Received: from fed1rmmtao104.cox.net (fed1rmmtao104.cox.net [68.230.241.42]) by core3.amsl.com (Postfix) with ESMTP id 36F613A689D for ; Thu, 19 Feb 2009 15:39:39 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090219233953.RBEJ16134.fed1rmmtao104.cox.net@fed1rmimpo03.cox.net>; Thu, 19 Feb 2009 18:39:53 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id Hzfs1b00c4N6T0Q04zfsnT; Thu, 19 Feb 2009 18:39:53 -0500 X-Authority-Analysis: v=1.0 c=1 a=MthLulolaBoA:10 a=r-rcRZjYqYEA:10 a=Wajolswj7cQA:10 a=DnZwyuRz77A1k-TqUjwA:9 a=zRnbhxRq9btU461gltFq5RswdMUA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <499DEDC8.5090202@cox.net> Date: Thu, 19 Feb 2009 16:39:52 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <20090219.011715.22395.1@webmail19.vgs.untd.com> <499DCD63.50201@gmail.com> <499DD18D.2050104@cox.net> <499DE02F.9050903@gmail.com> In-Reply-To: <499DE02F.9050903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 48 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 23:39:40 -0000 Jon Watte wrote: > Lawson English wrote: >> Well, the in-world meeting seemed productive to me. If you're not >> familiar with the Metanomics and Science Friday venues, you don't >> know how powerful a shared inworld/outworld experience can be even >> with minimal hardware (nothing as elaborate as what Qwaq apparently >> can do). >> > > Being that our company sells virtual world systems based around the > power of virtual world meetings, and we hold all our corporate status > meetings in our world, I would say I know very well how powerful it > is. I'm one of the biggest advocates of using virtual worlds! > However the specific case I was talking about was the perceived > attempt to frame a discussion about setting up a live video stream > from an upcoming meeting as something that's somehow groundbreaking > and new. I find that trying to sound-byte things like that end up > confusing outside observers, and obscuring the inside work that's > really going on. > > It's groundbreaking and new to: 1) try to make it work for multiple worlds at the same time 2) discuss the whole project in-world 3) figure out the details of sharing in-world chat between worlds Ideally, we should be able to TP or even walk from one world to the next while keeping our avatars' appearance as we like and not require everyone to log into SL wtih the SL avatar. You seem to prefer having some kind of window into the other world but keeping the avatar in your own. Or something. Lawson From jwatte@gmail.com Thu Feb 19 15:58:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CA4F28C232 for ; Thu, 19 Feb 2009 15:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sYiTVz-g9kx for ; Thu, 19 Feb 2009 15:58:01 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id EC93828C21C for ; Thu, 19 Feb 2009 15:58:00 -0800 (PST) Received: by gxk22 with SMTP id 22so1876279gxk.13 for ; Thu, 19 Feb 2009 15:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=TWUmNaBDi6bhTxKx7aLq28eR9YAIdFnWodONnhUVRsM=; b=wuR116IWGDmZl3leHaJTAxL9BJ6zuCxxokpCxqz0Q7w/e4TgNEvb9x93cyc8YjHPxP quvh8RoS031hMIxFnXXfXQbhm1CMzbtbdqhG3qtqRKPPy4PV/EBQN/G/+cY9pnjL04i8 cAflZF+HNBeJH9lnXK2QcmmOtvBTOKO+wMEuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xMy8itC4YOVoRiTC26/6I5AUSfrcpDjIM6GUnnfCWDhEz32sqlv7T53/gsR/A1rGcO gQsYpMLjqNWVUCdhxa8ABNd/XON9VfNDw8jTH9bKixcT0HIanOh8Q6611Fy+pyw4pyx1 u7TlfmRjXw2/YyedeOJ37MqASxHrdoS3YX0lY= Received: by 10.101.1.16 with SMTP id d16mr237212ani.153.1235087893606; Thu, 19 Feb 2009 15:58:13 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c29sm1594814anc.3.2009.02.19.15.58.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 15:58:12 -0800 (PST) Message-ID: <499DF212.7040701@gmail.com> Date: Thu, 19 Feb 2009 15:58:10 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <20090219.011715.22395.1@webmail19.vgs.untd.com> <499DCD63.50201@gmail.com> <499DD18D.2050104@cox.net> <499DE02F.9050903@gmail.com> <499DEDC8.5090202@cox.net> In-Reply-To: <499DEDC8.5090202@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 48 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 23:58:02 -0000 Lawson English wrote: > It's groundbreaking and new to: > > 1) try to make it work for multiple worlds at the same time Has been done since the '80s. > 2) discuss the whole project in-world Has been done since the '80s. Any real VW developer really needs to do this, or he's just blowing smoke. > 3) figure out the details of sharing in-world chat between worlds > Has been done since the '80s (although it started out with voice chat, not text chat). Note: there was a large and thriving virtual world, virtual reality and interactive simulation industry before 3D graphics cards became commodity hardware on consumer PCs. And, as it turns out, those communities did a lot of research and development that may now either become relevant, or serve as bad examples. Those who ignore history are doomed to repeat it. > > Ideally, we should be able to TP or even walk from one world to the > next while keeping our avatars' appearance as we like and not require > everyone to log into SL wtih the SL avatar. > > You seem to prefer having some kind of window into the other world but > keeping the avatar in your own. I'm sorry if you feel that my proposal was hard to understand, because that's not at all what the proposal is. In fact, to the user, the experience is that the user can invite someone from another world, or the user can travel to some other world, and meet other people from other worlds, and while that is happening, voice chat, emotes, objects, and other things the user is used to doing keep working as usual. The specifics of my proposal address such issues as "how do I make sure that my car actually still works when I'm visiting another world?" and "do I have to learn a new user interface if I visit another world with different capabilities?" and "will other people see my 'dancing the Riverdance' emote?" which we've run into when we've done these kinds of integrations before. Also, my proposal addresses business realities, such as what actual users with actual money are asking for, and what real problems can be solved with interoperability. It turns out that if there's money in a solution, that solution tends to be more concrete and happen sooner than if it's just a few interested people doing it out of altruism or curiosity. And, no, I don't think the solution to those questions is "everybody should use a run-time compatible physics, scripting, networking, UI and code execution environment." Sincerely, jw From infinity@lindenlab.com Thu Feb 19 16:12:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A38128C22E for ; Thu, 19 Feb 2009 16:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHoDS+0WXJ7N for ; Thu, 19 Feb 2009 16:12:03 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 471F328C138 for ; Thu, 19 Feb 2009 16:12:03 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 4B2A33DBC45B; Thu, 19 Feb 2009 16:12:17 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <499DDEED.2000109@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 16:12:16 -0800 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 00:12:04 -0000 On Feb 19, 2009, at 2:36 PM, Jon Watte wrote: > Meadhbh Hamrick (Infinity) wrote: >> * we're about application layer wire protocol >> * we're about interoperability between current or near future >> implementations > > Implementations of what? OLIVE has a gateway in use by various > customers since 2005. It uses DIS, HLA, and a variety of other > protocols, depending on what system it's talking to. I'd be happy to > talk more about that system, and how that can grow. It's a currently > implemented system in commercial use, which seems like a good place > to start. DIS and HLA are "a bit complex" and were designed to provide services that were vaguely different from what we're aiming at here. I don't think we're interested in simulating just a battlefield of tanks. i think what we're thinking about is a wire protocol that does not carry a specific semantic load and is less declarative and more proscriptive. that is to say.. DIS and HLA appear to be useful mostly to the degree that they allow different defense contractors to specify conceptual interfaces between components in an augmented reality training simulation @ the NTC. While I like the idea of extending DIS, HLA and IEEE-1278 to include PDU family for avatar dance animations, flexi hair attachments, manticore attacks and controlling attack ships off the shoulder of orion, creating such a catalog of PDU families would be pretty time consuming by itself. > Or do you want to use the Second Life system just because it's > Second Life, even if it's not currently implemented or in current > commercial use? again. we are not proposing the existing second life protocol for standardization. i think we've said that several times. we would like to develop a protocol or protocol framework that is "widely usable." >> * we're NOT blessing Second Life's existing protocol as an official >> standard >> * it's entirely possible application developers using MMOX >> protocols would need to define an "interoperability profile," which >> defines how MMOX applies to their application. >> * in other words, "we define mechanism, not policy." > > That's like saying "E-mail exchange should be done using MIME > encoded data on port 25" without specifying SMTP. That's neither > interoperable nor vendor neutral. i think you have it backwards. in the RFC1822 context, defining mechanism but not policy would mean... you define things like * an protocol interaction begins with a HELO message * you MAY include extended authentication messages * you then use MAIL FROM: and RCPT TO: to declare the sender and receiver of a message * assuming there are no errors, use DATA to declare the start of message * messages begin with headers, then the body of the message, careful using periods or the word "From" at the beginnings of lines * etc., etc. then the policy, which would include constraints on its use would be something like... * WE like to receive SMTP traffic on port 25 of the machine listed in the MX record of our root domain. * there's this thing called MIME, if you're a client, you'll probably want to understand the concept of a MIME type i think there is a long history of using SMTP and MIME in a vendor neutral and interoperable fashion. -cheers -meadhbh From belxjander@gmail.com Thu Feb 19 16:18:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D5828C138 for ; Thu, 19 Feb 2009 16:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.474 X-Spam-Level: X-Spam-Status: No, score=-1.474 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+94dvnn99Fn for ; Thu, 19 Feb 2009 16:18:55 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 06C6E3A68B4 for ; Thu, 19 Feb 2009 16:18:55 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so541414rvb.5 for ; Thu, 19 Feb 2009 16:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=+wY/xWTgWdQZbuOYMLOhEL4k0D1EY13Cm/1zbtQJMcY=; b=VEWFpxZrQ8GlEYlAu/eC9bxNWkVxPCK8J95uf1UUmIXq7AsBKnPAb8Mgq9Pd8HklfY 9VomG/14fMG7LILLnQxPkDHzAEKLq4YOA54sGhNnFu8Zaku165M6MvSWLPXQLgLlBqag js9KgKFRX9Atf7KIwUbHWeBAFFpP5csqd/u5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=hhrMrvAVDNVRdACQGEHaJYKXfRaFemCm+Bffpc0oOgB5HOwihNhvmvCsibRjEKA+uA QZnj0MWfkbqfQh8Xa7PlSzjq29QSNlJKwiwtNhyU3zDbKwFbNoukXOa1SlvkoJYZKVVB b8p3sMleacZ+q7czWtVNgUW9AL9BViGU+Sr3g= Received: by 10.141.36.10 with SMTP id o10mr65241rvj.237.1235089148908; Thu, 19 Feb 2009 16:19:08 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id k37sm3890521rvb.1.2009.02.19.16.19.06 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 16:19:08 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <499DD634.3050101@gmail.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <499DD634.3050101@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VrRlVOzEX/Donj6MDwqI" Date: Fri, 20 Feb 2009 09:13:44 +0900 Message-Id: <1235088824.7560.112.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 00:18:56 -0000 --=-VrRlVOzEX/Donj6MDwqI Content-Type: text/plain Content-Transfer-Encoding: quoted-printable boiling this down... Each user has own server that has the "room" layout imported from the materia services, and lets the user client render it... any *changes* that occur by one or more people are forwarded to the other copies, and incoming changes are applied as they arrive. I can see a "generic core" platform requirement here... a triple server for core functionality... 1: Identity Authentication and by extension "permissions", recognising the individual and recognising groups. 2: Location, Location, Location. Recognising the boundary of a server showing a region where 1 or more Identities may be "present" Recognising non-Identity "Objects" 3: Representation of Objects, Everything is presented as a 3d object or group of objects (object-linking) (an AV is simply an object group with an Identity attached) (bots in this case become independent of client operations and can run entirely on-system) and there is 2 requirements I can see for "inter operability". Allowance of "presence" based on cross-connect agreement between any 2 systems, with a "representation" object able to be mapped into the hosting system you are visiting. for those that are reading this... Im not considering the AV or anything "in the virtual world" as special case it is either a fixed part of the location (location physical map) or=20 an independent object within the space on the server providing "location". Identity is provided by the service the client logs into, and Interoperability in this case becomes the capability to "visit" a non-home location, similar to leaving the house and going to the mall or further travel in the real world. where the object can be represented is upto the allowed complexity during transfer Does anyone have any questions about this or do I need to clarify this further?=20 Because I am also taking into account that any given system is not going to share all content (who says that any object is going to be able to cross any boundary?) I began the above by trying to think of the lowest common denominator on any given service from the user view and simplify by occams razor further. the only other item to account for is some kind of messaging between systems. and I do hope that both emulation of non-native AND conversion of data options are both avoided where possible (each comes with unwanted occurences) non-native emulation would result in needing a proxy+plugin mechanism for allowing a native server to be launched on the localhost and a plugin for systemA systemB conversion (data-loss due to communications?) On Thu, 2009-02-19 at 13:59 -0800, Jon Watte wrote: > Morgaine wrote: > > Unfortunately, that's non-scalable, particularly along the complexity=20 > > axis. > > >=20 > I disagree. See below: >=20 > > It works fine in your example because you have only two parties=20 > > wishing to share a space and hence there is only one space to=20 > > simulate, but try to extrapolate from there to see where it leads. If=20 > > your organization A has N users, and those N users wish to take part=20 > > in N different worlds (which is asymptotically likely if N << total=20 > > number of worlds), then your organization A must now simulate N=20 > > different worlds. For large N, this places a colossal load on=20 > > organization A, even if the individual shared spaces are minimally=20 > > populated. To coin a common phrase by analogy, you're undertaking to=20 > > "simulate the Internet". ;-) > > >=20 > Not at all. Note that the actual simulation of each object happens on=20 > the "home" sim server of that object. Only telemetry is sent to other=20 > servers. I'm assuming forwarding telemetry is "cheap" whereas simulation=20 > of objects is "expensive" -- previous technical history shows that that=20 > is true. Thus, a virtual world service provider will undertake to=20 > provide simulation capacity for a user and N objects, and that's how=20 > many objects the user can put into the world. Some servers might be on=20 > an "all you can eat, and damn the lag" plan; others may be very metered=20 > and charge by the CPU-second. That is all up to policy, not mechanism. >=20 > If people from 8 different virtual world service providers meet in one=20 > physical space ("my room"), then there will be 8 copies of "my room"=20 > temporarily running on the greater internet, but each of those copies=20 > just simulate one user in that room. The cost of physical space ("my=20 > room") is very cheap, compared to the cost of managing an active,=20 > simulated user. Each server will connect to 7 peer servers, and send the=20 > telemetry data for the one user it simulates, and receive interactions=20 > from those 7 peers for things that affect that one user. >=20 > > What's more, very few platform optimizations will be possible since=20 > > the N worlds are all different, and this also means that the=20 > > scalability of each shared space will be severely constrained as=20 > > well. And as if that were not bad enough, the N worlds that your=20 > > users visit tomorrow will not necessarily be today's N worlds, so for=20 > > (N << total number of worlds) your local cache will need to grow=20 > > almost without limit if it's to work at all. > > >=20 > Luckily, bandwidth between well connected servers is not a problem. You=20 > can purge the cache when it gets big, and just pull down the asset when=20 > you need it. Compare to YouTube, or MSN, or any other large service=20 > provider. That's not a problem. >=20 > > Even if organization A's machinery were powerful enough to support N=20 > > radically different worlds through shared-space simulations though,=20 > > they still couldn't do it, because in the general case the simulation=20 > > code for a given world will not be available. The world simulation is=20 > > the "secret sauce" of many virtual worlds, and from a business=20 > > perspective it is quite likely to be their product differentiator and=20 > > they will be loathe to share it. But even if it were freely=20 > > available, the portability of one organization's simulation code to=20 > > another organization's machinery is far from guaranteed with today's=20 > > software technology, not to mention the management of upgrades for=20 > > something this complex across organization boundaries. > > >=20 > My proposal specifically says that simulation code stays on the home=20 > server, and only interactions (the "result" of simulation) is shared to=20 > other servers. I agree that no other system can work. >=20 > > Foreign world simulations never need to be supported. > > >=20 > I agree! If you think my proposal requires that, I don't understand how=20 > that came across. Could you find the part where you thought I was=20 > suggesting that and point it out, so I could clarify it? >=20 > Sincerely, >=20 > jw >=20 > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-VrRlVOzEX/Donj6MDwqI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJnfW4AAoJECHrKutFYVwTrL0P/38d6YwCztzwy/IOh93uJv8y U2PLzK0xeZ3ET+/Hhzv2ZM2GX25VKXQP884zaPdcD0J+WuqYlVcIlf+x6KfPtq7f zpKGwKrj7Y8AGh5CKDl5rZoZOD5JlbtaZQZ/omtDPm7f2ZfuJViINw6e12hJGvh8 dTjQAph6Sq4WEmHjWVflINtjtBol2/JAxfSw5aj6d3Tvoh4ipCJiQCmsCl/Sdtwf FT6a7+gOjKVPK77gPivmEe3lWhDh3QGzJgeecdczm8MjDR+TVfKnv+51cXdUB/yC nBo9dAIddF1rmmBJKnSHhxZA9im2qVk3087Nq1TaBJkMlC75dRlTOF8eYswWYajv vO/uG5D4ZdVbtVoep4Ny+Zif6lTv5/BbSir5DEMkRPawOs7d6kUeYHIpTLWnHqmU gu9Wwkbi9+eeRn7E/OxmCEcTgZE/izQ4U8jpzumGVCH0Aad/sMJEqjE7bjDpfMzt ZHixMmQS2LCGjxjS0R4e5KwWvOVtB8mbrGnpwhz2h/QIKxZEA23PR+VNODrYnPtL pPGtTOuL0fAnKgTZTjZvCJH6TIaBh8gZU+eBlBl4Le8EFugas4vvITHITdOZIMNP oP8QF2+/dgxtphHnWBBOvw+9hIQUPWWeSrK1Ti8wPMSAdN2qOH9v3HhCYszd8Jak bP5GWaM9EOapm3XgqBQy =c+YB -----END PGP SIGNATURE----- --=-VrRlVOzEX/Donj6MDwqI-- From markl@lindenlab.com Thu Feb 19 17:15:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84AD03A68C8 for ; Thu, 19 Feb 2009 17:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.451 X-Spam-Level: X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMQUo0IC2TFM for ; Thu, 19 Feb 2009 17:15:18 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 938003A69E3 for ; Thu, 19 Feb 2009 17:15:18 -0800 (PST) Received: from nil.lindenlab.com (nil.lindenlab.com [10.1.16.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id D00223DBC45C for ; Thu, 19 Feb 2009 17:15:31 -0800 (PST) Message-Id: <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> From: Mark Lentczner To: mmox@ietf.org In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 17:15:31 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [mmox] More LLIDL questions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:15:19 -0000 On Feb 18, 2009, at 12:39 PM, Hurliman, John wrote: > ; An LLSD value containing { member1 : true, member2 : true } comes > in. Is member3 a string or an int? > &a = { member1 : true, member2 : false, member3 : string } > &a = { member1 : false, member2 : true, member3 : int } In our LLIDL implementation, if you matched that LLSD against the LLIDL value "&a", with those variants in scope, the answer would come back INCOMPATIBLE. This is because no variant matched the value. In the case of the selectors in LLIDL, they all need to match. Had the variants been: &a = { member1: true, member3: string } &a = { member2: true, member3: int } The answer would be MIXED. This is because the actual value matched each variant with the same result: In each case, the the data had parts that were ADDITIONAL (member2 or member1), and parts that were DEFAULTED (member3). The state of having both DEFAULTED parts and ADDITIONAL parts is MIXED. Matching variants returns the best match, but in this case they were both MIXED, so the result is MIXED. Hope that was clear. Please note: The notion of returning a confidence level from a LLIDL to actual LLSD match is a function of our library, not part of the specification. This was intentional: LLSD is defined in such a way that given *any* LLSD, and code that expects any particular structure - the code can safely extract values, receiving defaults if things don't match as expected. Hence, LLIDL isn't a way of expressing a hard "go/no-go" conformance, it is a way of expressing what is expected. > ; How is a parser supposed to handle this? > &b = { $ : &b } > ; Or this? > &c = { $ : &d } > &d = { $ : &c } We could declare recursive LLIDL is illegal. It isn't too hard to detect. On the other hand, since LLSD data values can't be recursive, even if you have a recursive LLIDL description, any actual match operation is bounded. Our implementation handles recursive LLIDL and it took no extra work to do so. > ; The first variant has the type uri. The second variant has the > type string? > &e = uri > &e = "http://www.google.com/" The second doesn't have the type string, it is a selector of a specific string. Here's how our LLIDL would match these LLSDs: string "http://www.google.com/" --> MATCHED (matches the selector exactly) string "http://www.example.com/" --> CONVERTED (convertable to a uri) uri "http://www.google.com/" --> MATCHED (matches the type uri) uri "http://www.example.com/" --> MATCHED (matches the type uri) string "" --> INCOMPATIBLE (neither matches the specific selector string, nor is a reasonable conversion to uri) The notion of "reasonable conversion" is going to be implementation specific, since LLSD defines a result no matter what is converted to what. In our case, we took the notion that if the transmitted value only converts to the desired value via a defaulting, well, then, that doesn't really increase the confidence in the match. (There is some subtlety in our choices here... I can go into it more if you like.) > ; Forward-slash seems like an odd addition to 0-9+A-Z. Why this > character? > &f/ = "hello slash" As a trailer, sure, but we like using slash as a name space delimiter in our protocols for resource names, member names, fixed selector strings, and, as you indicate, selector names: %% thing/operation_x -> { id: uuid } <- { name: string, system_a/count: int, system_b/count: int, system_c: &system_c/info } &system_c/info = { name: string, count: int } &system_c/info = { name: string, count: real, extended: true } - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From john.hurliman@intel.com Thu Feb 19 17:56:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E2433A68D4 for ; Thu, 19 Feb 2009 17:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmmkuRMs5roN for ; Thu, 19 Feb 2009 17:56:50 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id 323CC3A6832 for ; Thu, 19 Feb 2009 17:56:50 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 19 Feb 2009 17:57:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,237,1233561600"; d="scan'208";a="112530737" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by azsmga001.ch.intel.com with ESMTP; 19 Feb 2009 17:57:03 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Thu, 19 Feb 2009 18:57:03 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Thu, 19 Feb 2009 18:56:59 -0700 Thread-Topic: [mmox] More LLIDL questions Thread-Index: AcmS+MGA6pIvNVijQP2vZoN/1aHwNQABOhPw Message-ID: <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> In-Reply-To: <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] More LLIDL questions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:56:51 -0000 Great, thank you for the quick responses on all of these questions. Keeping= the implementation private is a good way to test the accuracy of the draft= and determine if it explains the concepts well enough. For the most part i= t seems reasonable, but there are parts that I've scratched my head at. Gen= erating strongly typed classes in C# from LLIDL leaves a lot of unnamed ("a= nonymous", in C#-speak) variables. Last question. I found this snippet of LLIDL from the agent login draft pro= posal on the Second Life wiki: agents: [ first_name: string, last_name: string ... ] Is that valid LLIDL, or should it be: agents: [ { first_name: string, last_name: string } ... ] Allowing key:value pairs in arrays seems to defeat the purpose of the map t= ype. John >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Mark Lentczner >Sent: Thursday, February 19, 2009 5:16 PM >To: mmox@ietf.org >Subject: Re: [mmox] More LLIDL questions > >On Feb 18, 2009, at 12:39 PM, Hurliman, John wrote: >> ; An LLSD value containing { member1 : true, member2 : true } comes >> in. Is member3 a string or an int? >> &a =3D { member1 : true, member2 : false, member3 : string } >> &a =3D { member1 : false, member2 : true, member3 : int } > >In our LLIDL implementation, if you matched that LLSD against the >LLIDL value "&a", with those variants in scope, the answer would come >back INCOMPATIBLE. This is because no variant matched the value. In >the case of the selectors in LLIDL, they all need to match. > >Had the variants been: >&a =3D { member1: true, member3: string } >&a =3D { member2: true, member3: int } > >The answer would be MIXED. This is because the actual value matched >each variant with the same result: In each case, the the data had >parts that were ADDITIONAL (member2 or member1), and parts that were >DEFAULTED (member3). The state of having both DEFAULTED parts and >ADDITIONAL parts is MIXED. Matching variants returns the best match, >but in this case they were both MIXED, so the result is MIXED. > >Hope that was clear. > >Please note: The notion of returning a confidence level from a LLIDL >to actual LLSD match is a function of our library, not part of the >specification. This was intentional: LLSD is defined in such a way >that given *any* LLSD, and code that expects any particular structure >- the code can safely extract values, receiving defaults if things >don't match as expected. Hence, LLIDL isn't a way of expressing a hard >"go/no-go" conformance, it is a way of expressing what is expected. > >> ; How is a parser supposed to handle this? >> &b =3D { $ : &b } >> ; Or this? >> &c =3D { $ : &d } >> &d =3D { $ : &c } > >We could declare recursive LLIDL is illegal. It isn't too hard to >detect. On the other hand, since LLSD data values can't be recursive, >even if you have a recursive LLIDL description, any actual match >operation is bounded. Our implementation handles recursive LLIDL and >it took no extra work to do so. > >> ; The first variant has the type uri. The second variant has the >> type string? >> &e =3D uri >> &e =3D "http://www.google.com/" > >The second doesn't have the type string, it is a selector of a >specific string. Here's how our LLIDL would match these LLSDs: > string "http://www.google.com/" --> MATCHED (matches the selector >exactly) > string "http://www.example.com/" --> CONVERTED (convertable to a >uri) > uri "http://www.google.com/" --> MATCHED (matches the type uri) > uri "http://www.example.com/" --> MATCHED (matches the type uri) > string "" --> INCOMPATIBLE (neither matches the specific selector >string, nor is a reasonable conversion to uri) > >The notion of "reasonable conversion" is going to be implementation >specific, since LLSD defines a result no matter what is converted to >what. In our case, we took the notion that if the transmitted value >only converts to the desired value via a defaulting, well, then, that >doesn't really increase the confidence in the match. (There is some >subtlety in our choices here... I can go into it more if you like.) > >> ; Forward-slash seems like an odd addition to 0-9+A-Z. Why this >> character? >> &f/ =3D "hello slash" > >As a trailer, sure, but we like using slash as a name space delimiter >in our protocols for resource names, member names, fixed selector >strings, and, as you indicate, selector names: > >%% thing/operation_x >-> { id: uuid } ><- { name: string, system_a/count: int, system_b/count: int, system_c: >&system_c/info } > >&system_c/info =3D { name: string, count: int } >&system_c/info =3D { name: string, count: real, extended: true } > > - Mark > > >Mark Lentczner >Sr. Systems Architect >Technology Integration >Linden Lab > >markl@lindenlab.com > >Zero Linden >zero.linden@secondlife.com > > > > > >_______________________________________________ >mmox mailing list >mmox@ietf.org >https://www.ietf.org/mailman/listinfo/mmox >=20 From cfk@pacbell.net Thu Feb 19 19:52:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DC523A6A92 for ; Thu, 19 Feb 2009 19:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCW6J1tb6mCT for ; Thu, 19 Feb 2009 19:52:19 -0800 (PST) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id 2D3963A685E for ; Thu, 19 Feb 2009 19:52:18 -0800 (PST) Received: (qmail 46775 invoked by uid 60001); 20 Feb 2009 03:52:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=V3cCZFdtDEM642wx8P6XTEUK8/450KNDFaA8RIKkgnXZzte35kLqoFfNdjwk6FRvrcvZxGjXamVcdSQcLb7RB+ri9KGktbF6/frU3N8W7/tHM1llSvdiZjRTtpHrxWT3F/c+wS4BzFi+5SL34onMJcGT97ITHAeiop7j+2y3qQ4=; X-YMail-OSG: Avhh0ZAVM1nxdIFHjDWYtxjf7islsAMfpcVDDrRkaMs4q7DrmxYYPOOm4EaTugEAuQ-- Received: from [67.120.11.69] by web82607.mail.mud.yahoo.com via HTTP; Thu, 19 Feb 2009 19:52:32 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> Date: Thu, 19 Feb 2009 19:52:32 -0800 (PST) From: Charles Krinke To: "mmox@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-15586217-1235101952=:28734" Message-ID: <29656.28734.qm@web82607.mail.mud.yahoo.com> Subject: [mmox] LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 03:52:20 -0000 --0-15586217-1235101952=:28734 Content-Type: text/plain; charset=us-ascii In looking at the secondlife wiki at http://wiki.secondlife.com/wiki/MMOX it looks like one of the first proposals for this working group is the LLSD draft specification. Am I correct in that the gist of the LLSD specification is essentially to propose three mime formats and thats about it for now? application/llsd+xml application/llsd+json application/llsd+binary Charles --0-15586217-1235101952=:28734 Content-Type: text/html; charset=us-ascii
In looking at the secondlife wiki at http://wiki.secondlife.com/wiki/MMOX it looks like one of the first proposals for this working group is the LLSD draft specification.

Am I correct in that the gist of the LLSD specification is essentially to propose three mime formats and thats about it for now?

application/llsd+xml
application/llsd+json
application/llsd+binary

Charles
--0-15586217-1235101952=:28734-- From infinity@lindenlab.com Thu Feb 19 20:09:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F543A6B7B for ; Thu, 19 Feb 2009 20:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKy843H3l9dW for ; Thu, 19 Feb 2009 20:09:54 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 0BB0E3A6B0C for ; Thu, 19 Feb 2009 20:09:54 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 854613DBC45C; Thu, 19 Feb 2009 20:10:07 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Charles Krinke In-Reply-To: <29656.28734.qm@web82607.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2--902231836 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 20:10:05 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 04:09:55 -0000 --Apple-Mail-2--902231836 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit http://wiki.secondlife.com/wiki/MMOX is non-authoritative, but yes LLSD is one of the work items we have on the list. the objective of LLSD is to provide an abstract type system with multiple serializations. it also defines the mime types. however, to say that the LLSD draft exists only to define the serializations is akin to saying that ASN.1 exists only to provide input into DER or BER encodings. the two are linked, but each has a particular use. LLSD as an abstract type system allows us to define and reason about the semantics of structured data used in PDUs independent of an existing implementation language. the serialization rules allow us to format structured data prior to transport and later de-serialize it after receipt. the MIME type registrations allow us to identify the serialization scheme used on transports that support the use of MIME types. LLIDL (pronounced "little") defines the set of expected parameters to and responses from a resource access. LLSD was selected as the first draft to work on as it is used as a building block for other protocol interactions, some of which are published in draft form on the second life wiki. the further development of these protocols is also considered a task of the proposed working group. -cheers -meadhbh On Feb 19, 2009, at 7:52 PM, Charles Krinke wrote: > In looking at the secondlife wiki at http://wiki.secondlife.com/wiki/MMOX > it looks like one of the first proposals for this working group is > the LLSD draft specification. > > Am I correct in that the gist of the LLSD specification is > essentially to propose three mime formats and thats about it for now? > > application/llsd+xml > application/llsd+json > application/llsd+binary > > Charles > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-2--902231836 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable http://wiki.secondlife.com/w= iki/MMOX is non-authoritative, but yes LLSD is one of the work items = we have on the list.

the objective of LLSD is to = provide an abstract type system with multiple serializations. it also = defines the mime types.

however, to say that = the LLSD draft exists only to define the serializations is akin to = saying that ASN.1 exists only to provide input into DER or BER = encodings. the two are linked, but each has a particular = use.

LLSD as an abstract type system allows us = to define and reason about the semantics of structured data used in PDUs = independent of an existing implementation language. the serialization = rules allow us to format structured data prior to transport and later = de-serialize it after receipt. the MIME type registrations allow us to = identify the serialization scheme used on transports that support the = use of MIME types. LLIDL (pronounced "little") defines the set of = expected parameters to and responses from a resource = access.

LLSD was selected as the first draft to = work on as it is used as a building block for other protocol = interactions, some of which are published in draft form on the second = life wiki. the further development of these protocols is also considered = a task of the proposed working = group.

-cheers
-meadhbh

<= /div>
On Feb 19, 2009, at 7:52 PM, Charles Krinke = wrote:

In looking at = the secondlife wiki at http://wiki.secondlife.com/w= iki/MMOX it looks = like one of the first proposals for this working group is the LLSD draft = specification.

Am I correct in that the gist of the LLSD = specification is essentially to propose three mime formats and thats = about it for = now?

application/llsd+xml
application/llsd+json
application/l= lsd+binary

Charlesmmox@ietf.org
https://www.ietf.org/m= ailman/listinfo/mmox

= --Apple-Mail-2--902231836-- From infinity@lindenlab.com Thu Feb 19 20:22:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD30028C1F5 for ; Thu, 19 Feb 2009 20:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjBVhkkrBTAO for ; Thu, 19 Feb 2009 20:22:43 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id C4B7B28C13A for ; Thu, 19 Feb 2009 20:22:43 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id E5DBE3DBC45C; Thu, 19 Feb 2009 20:22:57 -0800 (PST) Message-Id: <50FD3E60-C7D4-4ACC-94BF-E05565A36D14@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: "Hurliman, John" In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 20:22:56 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] More LLIDL questions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 04:22:45 -0000 good eye john. yes, the purpose of the list is to provide an array of first_name, last_name pairs. however... yes... it is an improperly formed array. it was supposed to be [ string ... ] with the understanding that the array SHOULD contain an even number of entries, odd entries representing an avatar's first_name, even entries representing an avatars last_name. -cheers -meadhbh On Feb 19, 2009, at 5:56 PM, Hurliman, John wrote: > Great, thank you for the quick responses on all of these questions. > Keeping the implementation private is a good way to test the > accuracy of the draft and determine if it explains the concepts well > enough. For the most part it seems reasonable, but there are parts > that I've scratched my head at. Generating strongly typed classes in > C# from LLIDL leaves a lot of unnamed ("anonymous", in C#-speak) > variables. > > Last question. I found this snippet of LLIDL from the agent login > draft proposal on the Second Life wiki: > > agents: [ first_name: string, last_name: string ... ] > > Is that valid LLIDL, or should it be: > > agents: [ { first_name: string, last_name: string } ... ] > > Allowing key:value pairs in arrays seems to defeat the purpose of > the map type. > > John > >> -----Original Message----- >> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On >> Behalf Of >> Mark Lentczner >> Sent: Thursday, February 19, 2009 5:16 PM >> To: mmox@ietf.org >> Subject: Re: [mmox] More LLIDL questions >> >> On Feb 18, 2009, at 12:39 PM, Hurliman, John wrote: >>> ; An LLSD value containing { member1 : true, member2 : true } comes >>> in. Is member3 a string or an int? >>> &a = { member1 : true, member2 : false, member3 : string } >>> &a = { member1 : false, member2 : true, member3 : int } >> >> In our LLIDL implementation, if you matched that LLSD against the >> LLIDL value "&a", with those variants in scope, the answer would come >> back INCOMPATIBLE. This is because no variant matched the value. In >> the case of the selectors in LLIDL, they all need to match. >> >> Had the variants been: >> &a = { member1: true, member3: string } >> &a = { member2: true, member3: int } >> >> The answer would be MIXED. This is because the actual value matched >> each variant with the same result: In each case, the the data had >> parts that were ADDITIONAL (member2 or member1), and parts that were >> DEFAULTED (member3). The state of having both DEFAULTED parts and >> ADDITIONAL parts is MIXED. Matching variants returns the best match, >> but in this case they were both MIXED, so the result is MIXED. >> >> Hope that was clear. >> >> Please note: The notion of returning a confidence level from a LLIDL >> to actual LLSD match is a function of our library, not part of the >> specification. This was intentional: LLSD is defined in such a way >> that given *any* LLSD, and code that expects any particular structure >> - the code can safely extract values, receiving defaults if things >> don't match as expected. Hence, LLIDL isn't a way of expressing a >> hard >> "go/no-go" conformance, it is a way of expressing what is expected. >> >>> ; How is a parser supposed to handle this? >>> &b = { $ : &b } >>> ; Or this? >>> &c = { $ : &d } >>> &d = { $ : &c } >> >> We could declare recursive LLIDL is illegal. It isn't too hard to >> detect. On the other hand, since LLSD data values can't be recursive, >> even if you have a recursive LLIDL description, any actual match >> operation is bounded. Our implementation handles recursive LLIDL and >> it took no extra work to do so. >> >>> ; The first variant has the type uri. The second variant has the >>> type string? >>> &e = uri >>> &e = "http://www.google.com/" >> >> The second doesn't have the type string, it is a selector of a >> specific string. Here's how our LLIDL would match these LLSDs: >> string "http://www.google.com/" --> MATCHED (matches the selector >> exactly) >> string "http://www.example.com/" --> CONVERTED (convertable to a >> uri) >> uri "http://www.google.com/" --> MATCHED (matches the type uri) >> uri "http://www.example.com/" --> MATCHED (matches the type uri) >> string "" --> INCOMPATIBLE (neither matches the specific selector >> string, nor is a reasonable conversion to uri) >> >> The notion of "reasonable conversion" is going to be implementation >> specific, since LLSD defines a result no matter what is converted to >> what. In our case, we took the notion that if the transmitted value >> only converts to the desired value via a defaulting, well, then, that >> doesn't really increase the confidence in the match. (There is some >> subtlety in our choices here... I can go into it more if you like.) >> >>> ; Forward-slash seems like an odd addition to 0-9+A-Z. Why this >>> character? >>> &f/ = "hello slash" >> >> As a trailer, sure, but we like using slash as a name space delimiter >> in our protocols for resource names, member names, fixed selector >> strings, and, as you indicate, selector names: >> >> %% thing/operation_x >> -> { id: uuid } >> <- { name: string, system_a/count: int, system_b/count: int, >> system_c: >> &system_c/info } >> >> &system_c/info = { name: string, count: int } >> &system_c/info = { name: string, count: real, extended: true } >> >> - Mark >> >> >> Mark Lentczner >> Sr. Systems Architect >> Technology Integration >> Linden Lab >> >> markl@lindenlab.com >> >> Zero Linden >> zero.linden@secondlife.com >> >> >> >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From cfk@pacbell.net Thu Feb 19 20:34:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4343A69CB for ; Thu, 19 Feb 2009 20:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9NukkbuNect for ; Thu, 19 Feb 2009 20:34:35 -0800 (PST) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id 7FEF93A688C for ; Thu, 19 Feb 2009 20:34:35 -0800 (PST) Received: (qmail 81207 invoked by uid 60001); 20 Feb 2009 04:34:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=IdXefOvSPGbcuYnwvh4Xul9m3qR/aMAWLlUZjXR5V1m1LNEZL8gB12vEx6Rng105qlT9PWWfeq18K1zdv5q5w04o0vHdXe6bbilJGX0KZEM57Xcm+XkhylMYc/5pMo4cG+VkbaOmhz669XENq2DZNh+LjDrCakW04mkm09e8Vec=; X-YMail-OSG: My9vUl0VM1kOHZX.V7GfLfMmWTw2C70a5Wsl7OhLWmLaNLeX4SJvdZR8cohVcprrviOxv9BMz46K1BwDIKQ3.4Q6Inkd0iNRaCM8DlK.0Vmqd9AYqo6NwuQujdgBWzpzOl.J03c6KsPwogMPz7bfJwjYJquMNeGoRI.8uSqezV45yNPkAk5DfPvMXNuVMBWMPIcLBe_j20F4Po.BcpZ2KluA4Eo- Received: from [67.120.11.69] by web82607.mail.mud.yahoo.com via HTTP; Thu, 19 Feb 2009 20:34:48 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> Date: Thu, 19 Feb 2009 20:34:48 -0800 (PST) From: Charles Krinke To: "Meadhbh Hamrick \(Infinity\)" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1746896104-1235104488=:78349" Message-ID: <61320.78349.qm@web82607.mail.mud.yahoo.com> Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 04:34:36 -0000 --0-1746896104-1235104488=:78349 Content-Type: text/plain; charset=us-ascii Ok, Meadhbh: In looking at this draft *and* hoping I dont make my OpenSim peers too unhappy with me, let me ask a question. "Is there any reason why trying to approve the draft LLSD spec would preclude or pertubate either OGP, HyperGrid or other similar notions from being supported?" Charles ________________________________ From: Meadhbh Hamrick (Infinity) To: Charles Krinke Cc: "mmox@ietf.org" Sent: Thursday, February 19, 2009 8:10:05 PM Subject: Re: [mmox] LLSD http://wiki.secondlife.com/wiki/MMOX is non-authoritative, but yes LLSD is one of the work items we have on the list. the objective of LLSD is to provide an abstract type system with multiple serializations. it also defines the mime types. however, to say that the LLSD draft exists only to define the serializations is akin to saying that ASN.1 exists only to provide input into DER or BER encodings. the two are linked, but each has a particular use. LLSD as an abstract type system allows us to define and reason about the semantics of structured data used in PDUs independent of an existing implementation language. the serialization rules allow us to format structured data prior to transport and later de-serialize it after receipt. the MIME type registrations allow us to identify the serialization scheme used on transports that support the use of MIME types. LLIDL (pronounced "little") defines the set of expected parameters to and responses from a resource access. LLSD was selected as the first draft to work on as it is used as a building block for other protocol interactions, some of which are published in draft form on the second life wiki. the further development of these protocols is also considered a task of the proposed working group. -cheers -meadhbh On Feb 19, 2009, at 7:52 PM, Charles Krinke wrote: In looking at the secondlife wiki at http://wiki.secondlife.com/wiki/MMOX it looks like one of the first proposals for this working group is the LLSD draft specification. Am I correct in that the gist of the LLSD specification is essentially to propose three mime formats and thats about it for now? application/llsd+xml application/llsd+json application/llsd+binary Charles _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-1746896104-1235104488=:78349 Content-Type: text/html; charset=us-ascii
Ok, Meadhbh:

In looking at this draft *and* hoping I dont make my OpenSim peers too unhappy with me, let me ask a question.

"Is there any reason why trying to approve the draft LLSD spec would preclude or pertubate either OGP, HyperGrid or other similar notions from being supported?"

Charles

From: Meadhbh Hamrick (Infinity) <infinity@lindenlab.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: "mmox@ietf.org" <mmox@ietf.org>
Sent: Thursday, February 19, 2009 8:10:05 PM
Subject: Re: [mmox] LLSD

http://wiki.secondlife.com/wiki/MMOX is non-authoritative, but yes LLSD is one of the work items we have on the list.

the objective of LLSD is to provide an abstract type system with multiple serializations. it also defines the mime types.

however, to say that the LLSD draft exists only to define the serializations is akin to saying that ASN.1 exists only to provide input into DER or BER encodings. the two are linked, but each has a particular use.

LLSD as an abstract type system allows us to define and reason about the semantics of structured data used in PDUs independent of an existing implementation language. the serialization rules allow us to format structured data prior to transport and later de-serialize it after receipt. the MIME type registrations allow us to identify the serialization scheme used on transports that support the use of MIME types. LLIDL (pronounced "little") defines the set of expected parameters to and responses from a resource access.

LLSD was selected as the first draft to work on as it is used as a building block for other protocol interactions, some of which are published in draft form on the second life wiki. the further development of these protocols is also considered a task of the proposed working group.

-cheers
-meadhbh

On Feb 19, 2009, at 7:52 PM, Charles Krinke wrote:

In looking at the secondlife wiki at http://wiki.secondlife.com/wiki/MMOX it looks like one of the first proposals for this working group is the LLSD draft specification.

Am I correct in that the gist of the LLSD specification is essentially to propose three mime formats and thats about it for now?

application/llsd+xml
application/llsd+json
application/llsd+binary

Charles
_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox

--0-1746896104-1235104488=:78349-- From infinity@lindenlab.com Thu Feb 19 22:38:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6B13A6960 for ; Thu, 19 Feb 2009 22:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxdQnhn5FMUl for ; Thu, 19 Feb 2009 22:38:34 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 880693A672F for ; Thu, 19 Feb 2009 22:38:34 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id C2BEA3DBC45C; Thu, 19 Feb 2009 22:38:47 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Charles Krinke In-Reply-To: <61320.78349.qm@web82607.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 19 Feb 2009 22:38:46 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> <61320.78349.qm@web82607.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 06:38:35 -0000 anything that uses LLSD and wants to be considered a "standard" must =20 only provide normative references that are also "standards". essentially the deal here is we think the RFCs that will eventually =20 provide the authoritative references for OGP should be put on the IETF =20= "standards track." in fact, this is the primary raison d'=EAtre for the =20= proposed working group. if OGP is to be a "real" IETF standard, all =20 the documents it references as "normative" need to be standards as well. the alternative was to simply continue publishing our interface =20 documents on our wiki and perhaps publishing LLSD as an informational =20= RFC. however... we thought it better to use our existing OGP work as a =20= starting point, put it out in a forum where the expertise of the =20 internet engineering community could be utilized to review, comment =20 and improve it. our objective is to create a robust, flexible family =20 of protocols usable by the widest practical community. and for what it's worth, in the context of the proposed working group =20= OGP/Teleport and HyperGrid are two proposals [1] for doing similar =20 things. The two approaches _do_ seem assume different trust models, =20 and maybe the future is that both will find wide adoption. the "define =20= mechanism, not policy" mantra you sometimes hear some people repeat =20 implies that neither approach should preclude implementations from =20 implementing both. this is rather like most modern email user agents =20 implementing both,POP3 _and_ IMAP. the two protocols do essentially =20 the same thing, but there's nothing in either protocol that prevents =20 you from using either or both in the same mail client. but i ramble. the question as i read it was "would trying to approve the draft of =20 LLSD preclude or perturb further protocols?" the answer i would give =20 would be "no. it shouldn't." -cheers -meadhbh [1] - yes... actually neither are currently internet drafts, but i =20 believe John is working on something HyperGridish and OGP/Teleport was =20= listed on the draft charter of the proposed working group. On Feb 19, 2009, at 8:34 PM, Charles Krinke wrote: > Ok, Meadhbh: > > In looking at this draft *and* hoping I dont make my OpenSim peers =20 > too unhappy with me, let me ask a question. > > "Is there any reason why trying to approve the draft LLSD spec would =20= > preclude or pertubate either OGP, HyperGrid or other similar notions =20= > from being supported?" > > Charles > > From: Meadhbh Hamrick (Infinity) > To: Charles Krinke > Cc: "mmox@ietf.org" > Sent: Thursday, February 19, 2009 8:10:05 PM > Subject: Re: [mmox] LLSD > > http://wiki.secondlife.com/wiki/MMOX is non-authoritative, but yes =20 > LLSD is one of the work items we have on the list. > > the objective of LLSD is to provide an abstract type system with =20 > multiple serializations. it also defines the mime types. > > however, to say that the LLSD draft exists only to define the =20 > serializations is akin to saying that ASN.1 exists only to provide =20 > input into DER or BER encodings. the two are linked, but each has a =20= > particular use. > > LLSD as an abstract type system allows us to define and reason about =20= > the semantics of structured data used in PDUs independent of an =20 > existing implementation language. the serialization rules allow us =20 > to format structured data prior to transport and later de-serialize =20= > it after receipt. the MIME type registrations allow us to identify =20 > the serialization scheme used on transports that support the use of =20= > MIME types. LLIDL (pronounced "little") defines the set of expected =20= > parameters to and responses from a resource access. > > LLSD was selected as the first draft to work on as it is used as a =20 > building block for other protocol interactions, some of which are =20 > published in draft form on the second life wiki. the further =20 > development of these protocols is also considered a task of the =20 > proposed working group. > > -cheers > -meadhbh > > On Feb 19, 2009, at 7:52 PM, Charles Krinke wrote: > >> In looking at the secondlife wiki at = http://wiki.secondlife.com/wiki/MMOX=20 >> it looks like one of the first proposals for this working group is =20= >> the LLSD draft specification. >> >> Am I correct in that the gist of the LLSD specification is =20 >> essentially to propose three mime formats and thats about it for now? >> >> application/llsd+xml >> application/llsd+json >> application/llsd+binary >> >> Charles >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > From john.hurliman@intel.com Thu Feb 19 22:50:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E6DC3A672F for ; Thu, 19 Feb 2009 22:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.004 X-Spam-Level: X-Spam-Status: No, score=-6.004 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVE18s39NIM1 for ; Thu, 19 Feb 2009 22:50:23 -0800 (PST) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 07B853A68F7 for ; Thu, 19 Feb 2009 22:50:22 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 19 Feb 2009 22:44:15 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,239,1233561600"; d="scan'208";a="667101219" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by fmsmga001.fm.intel.com with ESMTP; 19 Feb 2009 22:54:30 -0800 Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by rrsmsx602.amr.corp.intel.com (10.31.0.33) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 19 Feb 2009 23:50:37 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Thu, 19 Feb 2009 23:50:36 -0700 From: "Hurliman, John" To: "Meadhbh Hamrick (Infinity)" Date: Thu, 19 Feb 2009 23:50:31 -0700 Thread-Topic: [mmox] More LLIDL questions Thread-Index: AcmTEuolzM7t7FGNS7WNht4/Z/BtuwAFIDiQ Message-ID: <62BFE5680C037E4DA0B0A08946C0933D50262E1E@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <50FD3E60-C7D4-4ACC-94BF-E05565A36D14@lindenlab.com> In-Reply-To: <50FD3E60-C7D4-4ACC-94BF-E05565A36D14@lindenlab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmox@ietf.org" Subject: Re: [mmox] More LLIDL questions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 06:50:24 -0000 Ah, that would work too. In fact, my reading of the draft says that [ string, string ... ] Would accomplish exactly that. >-----Original Message----- >From: Meadhbh Hamrick (Infinity) [mailto:infinity@lindenlab.com] >Sent: Thursday, February 19, 2009 8:23 PM >To: Hurliman, John >Cc: mmox@ietf.org >Subject: Re: [mmox] More LLIDL questions > >good eye john. > >yes, the purpose of the list is to provide an array of first_name, >last_name pairs. however... yes... it is an improperly formed array. >it was supposed to be > >[ string ... ] > >with the understanding that the array SHOULD contain an even number of >entries, odd entries representing an avatar's first_name, even entries >representing an avatars last_name. > >-cheers >-meadhbh > >On Feb 19, 2009, at 5:56 PM, Hurliman, John wrote: > >> Great, thank you for the quick responses on all of these questions. >> Keeping the implementation private is a good way to test the >> accuracy of the draft and determine if it explains the concepts well >> enough. For the most part it seems reasonable, but there are parts >> that I've scratched my head at. Generating strongly typed classes in >> C# from LLIDL leaves a lot of unnamed ("anonymous", in C#-speak) >> variables. >> >> Last question. I found this snippet of LLIDL from the agent login >> draft proposal on the Second Life wiki: >> >> agents: [ first_name: string, last_name: string ... ] >> >> Is that valid LLIDL, or should it be: >> >> agents: [ { first_name: string, last_name: string } ... ] >> >> Allowing key:value pairs in arrays seems to defeat the purpose of >> the map type. >> >> John >> >>> -----Original Message----- >>> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On >>> Behalf Of >>> Mark Lentczner >>> Sent: Thursday, February 19, 2009 5:16 PM >>> To: mmox@ietf.org >>> Subject: Re: [mmox] More LLIDL questions >>> >>> On Feb 18, 2009, at 12:39 PM, Hurliman, John wrote: >>>> ; An LLSD value containing { member1 : true, member2 : true } comes >>>> in. Is member3 a string or an int? >>>> &a =3D { member1 : true, member2 : false, member3 : string } >>>> &a =3D { member1 : false, member2 : true, member3 : int } >>> >>> In our LLIDL implementation, if you matched that LLSD against the >>> LLIDL value "&a", with those variants in scope, the answer would come >>> back INCOMPATIBLE. This is because no variant matched the value. In >>> the case of the selectors in LLIDL, they all need to match. >>> >>> Had the variants been: >>> &a =3D { member1: true, member3: string } >>> &a =3D { member2: true, member3: int } >>> >>> The answer would be MIXED. This is because the actual value matched >>> each variant with the same result: In each case, the the data had >>> parts that were ADDITIONAL (member2 or member1), and parts that were >>> DEFAULTED (member3). The state of having both DEFAULTED parts and >>> ADDITIONAL parts is MIXED. Matching variants returns the best match, >>> but in this case they were both MIXED, so the result is MIXED. >>> >>> Hope that was clear. >>> >>> Please note: The notion of returning a confidence level from a LLIDL >>> to actual LLSD match is a function of our library, not part of the >>> specification. This was intentional: LLSD is defined in such a way >>> that given *any* LLSD, and code that expects any particular structure >>> - the code can safely extract values, receiving defaults if things >>> don't match as expected. Hence, LLIDL isn't a way of expressing a >>> hard >>> "go/no-go" conformance, it is a way of expressing what is expected. >>> >>>> ; How is a parser supposed to handle this? >>>> &b =3D { $ : &b } >>>> ; Or this? >>>> &c =3D { $ : &d } >>>> &d =3D { $ : &c } >>> >>> We could declare recursive LLIDL is illegal. It isn't too hard to >>> detect. On the other hand, since LLSD data values can't be recursive, >>> even if you have a recursive LLIDL description, any actual match >>> operation is bounded. Our implementation handles recursive LLIDL and >>> it took no extra work to do so. >>> >>>> ; The first variant has the type uri. The second variant has the >>>> type string? >>>> &e =3D uri >>>> &e =3D "http://www.google.com/" >>> >>> The second doesn't have the type string, it is a selector of a >>> specific string. Here's how our LLIDL would match these LLSDs: >>> string "http://www.google.com/" --> MATCHED (matches the selector >>> exactly) >>> string "http://www.example.com/" --> CONVERTED (convertable to a >>> uri) >>> uri "http://www.google.com/" --> MATCHED (matches the type uri) >>> uri "http://www.example.com/" --> MATCHED (matches the type uri) >>> string "" --> INCOMPATIBLE (neither matches the specific selector >>> string, nor is a reasonable conversion to uri) >>> >>> The notion of "reasonable conversion" is going to be implementation >>> specific, since LLSD defines a result no matter what is converted to >>> what. In our case, we took the notion that if the transmitted value >>> only converts to the desired value via a defaulting, well, then, that >>> doesn't really increase the confidence in the match. (There is some >>> subtlety in our choices here... I can go into it more if you like.) >>> >>>> ; Forward-slash seems like an odd addition to 0-9+A-Z. Why this >>>> character? >>>> &f/ =3D "hello slash" >>> >>> As a trailer, sure, but we like using slash as a name space delimiter >>> in our protocols for resource names, member names, fixed selector >>> strings, and, as you indicate, selector names: >>> >>> %% thing/operation_x >>> -> { id: uuid } >>> <- { name: string, system_a/count: int, system_b/count: int, >>> system_c: >>> &system_c/info } >>> >>> &system_c/info =3D { name: string, count: int } >>> &system_c/info =3D { name: string, count: real, extended: true } >>> >>> - Mark >>> >>> >>> Mark Lentczner >>> Sr. Systems Architect >>> Technology Integration >>> Linden Lab >>> >>> markl@lindenlab.com >>> >>> Zero Linden >>> zero.linden@secondlife.com >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >=20 From jesrad@gmail.com Fri Feb 20 02:39:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8688B28C0E0 for ; Fri, 20 Feb 2009 02:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyXFNd9SoZCz for ; Fri, 20 Feb 2009 02:39:04 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 53CA428C156 for ; Fri, 20 Feb 2009 02:39:04 -0800 (PST) Received: by bwz5 with SMTP id 5so2337767bwz.13 for ; Fri, 20 Feb 2009 02:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TspyDOygwN5RRBQmWQgPYvZG8go2VAOZ/9cF0UJYyzc=; b=mg+W/m2EaulOWEFWwtH1bIFjLdH1IKjRCS3eiF1bfKJgC0L0AabYj5aLJDc1nYEnc8 D4NANogaQhMzf4RdZXfODEngFiasELPNEG/RzTi77yQeycVYcWY04OEqmk2x2HSt7EWG q4V0O5UFlQ8SiudhhGgwO3EI7jfWNJT5IR8Ms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pSKIIki69Ntn6RxIYjVqdDDaYOa0qg0gSfjUMTibc6zXvXHuG4Fyt9ISdj2jrPtfO3 QpFHUaf6sAe2cQ1lXFEUq5WaE3kNYlUJ4zBMUh/3sF6JhsdbYoknMguWHKbzNoMJu0kg aC7yK34EMmC9+df0/Un6puhR6eBD3J4DKrqwM= MIME-Version: 1.0 Received: by 10.181.216.12 with SMTP id t12mr229807bkq.122.1235126357509; Fri, 20 Feb 2009 02:39:17 -0800 (PST) In-Reply-To: <499DD3B8.80900@gmail.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <659848.26941.qm@web82607.mail.mud.yahoo.com> <499CA6DA.2010003@gmail.com> <53cd6c2e0902190338m5aad4ed2ia624e7826c17fb15@mail.gmail.com> <499DD3B8.80900@gmail.com> Date: Fri, 20 Feb 2009 11:39:17 +0100 Message-ID: <53cd6c2e0902200239w4241fe9ftd2b7de259bdd79e7@mail.gmail.com> From: Jesrad To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 10:39:05 -0000 > You're assuming that every virtual world that wants to interoperate will use > the Second Life scripting language, with the Second Life event model. This > is not unlike how VRML was specified. It didn't work out so well :-) That's not exactly what I meant: I'm saying that ANY interoperability between various VMs used for acting out the behaviour of a given VW object will require at least some uniformity, be it at the user interface or the simulator interface. Either the simulator software translates its native user inputs into compatible RPC for the target script and converts its return values, or the client does (with the grid then merely transporting the data in a uniform way). Or so I think. On Thu, Feb 19, 2009 at 10:48 PM, Jon Watte wrote: > Jesrad wrote: >> >> The problem I see here is that in this model, internal scripts for >> objects need to be accessed uniformly, too. When my car bumps into >> something and is scripted for that event, both grids need to be >> capable of calling the right event handler. >> >> > > You're assuming that every virtual world that wants to interoperate will use > the Second Life scripting language, with the Second Life event model. This > is not unlike how VRML was specified. It didn't work out so well :-) > > Sincerely, > > jw > > From jesrad@gmail.com Fri Feb 20 03:13:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA4C28C15A for ; Fri, 20 Feb 2009 03:13:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRwvydph5NA7 for ; Fri, 20 Feb 2009 03:13:24 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id A90ED28C15B for ; Fri, 20 Feb 2009 03:13:23 -0800 (PST) Received: by bwz5 with SMTP id 5so2374591bwz.13 for ; Fri, 20 Feb 2009 03:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/PsDFljX41kLdIoB7WBhnExOOeGLT0qUKbnn5ecTE14=; b=cyqoqG6hd3xs5AR2ClDO1KtCe9m1U9ctNyRZ28HcqzTuOvc6lyZFOEMOYhy56AL+YI FNzM23YUsbqxGeIG2bYUq5IigB8kd9veNwsgQXqEOBk3H+6F8Cvj8qdg5Zh6Q82q/ly/ CqJps8eUCtVfJ3DKemA39dw6kdzNqPXeNn5wQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DTV8Xxl2tqQBG+dmtHLBrUwxWcq2vYIQfhPH7/lA2lkxDhu9PZ6NjSKmEXU3DCSb3/ NMHHUK7lpAz5pnPxjtx0ilZ2IWFFHYIEI6f0ZZpd0H9AS2OHybdLXGUK9sgWEQzmjmic O0aUCHylwis1vSol2miuBeATVhz4oPDASDhFw= MIME-Version: 1.0 Received: by 10.180.249.4 with SMTP id w4mr238152bkh.162.1235128416684; Fri, 20 Feb 2009 03:13:36 -0800 (PST) In-Reply-To: <747254.34293.qm@web82602.mail.mud.yahoo.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> <747254.34293.qm@web82602.mail.mud.yahoo.com> Date: Fri, 20 Feb 2009 12:13:36 +0100 Message-ID: <53cd6c2e0902200313vb27deej1ef395441d53d287@mail.gmail.com> From: Jesrad To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 11:13:25 -0000 An example: the VW Solipsis ties its authentication service to Facebook. That lets it integrate complex social services (groups, friends, etc.) simply by adopting the Facebook Connect service. But then Facebook very recently joined the OpenID Foundation Board, so it seems they'll be taking care of that particular bit of interoperability without additional effort from the Solipsis team (and other projects that use the Connect service). It seems the market already chose OpenID as an authentication standard. The common VW operation at that level seems to be: - keep an internal user base - automatically create a new user from existing authentified IDs that sign in if they don't exist - manage a specific state for these new users from "outside" (the "no payment info on file" from SL, the "unpaid account" state from Vendetta-Online, etc.) - may or may not allow the creation of purely internal (not exported to the auth provider) IDs (this may lead to conflicting IDs ? should the outside auth service take precedence ? Is this question out of scope ?) On Thu, Feb 19, 2009 at 7:52 PM, Charles Krinke wrote: > > Dear Mark: > > Yes, that is a place where we can make progress. I am in fact "Charles > Krinke" on OSGrid, but I needed to be "Charlesk Bing" on SecondLife due to > the rules of that particular grid. > > I have a gmail account, as many other folks to and thus I believe I already > have an OpenID, so using OpenID is not unreasonable. > > I would personally suggest that we recommend at least two different > authentication methods so as not to paint ourselves into a corner down the > road a bit. > > Charles Krinke > > p.s. I would love to hear more about Croquet and how we can find ways to > interop and teleport between SecondLife, OpenSim and Croquet. > > > ________________________________ > From: Mark P. McCahill > To: mmox@ietf.org > Sent: Thursday, February 19, 2009 10:26:51 AM > Subject: [mmox] where is identity @ in all this? > > These worlds are fundamentally social environments. I would suggest starting > with interoperability for federated identity and presence. > > At a minimum I want to know which worlds my buddies are currently playing > in, and be able to chat with them, and be able to chat with people outside > the virtual worlds. If there are any ambitions toward integrating presence > in virtual worlds with more traditional audio, video, and text > communications, then SIP and XMPP-based presence would be worth considering > rather than re-inventing these functions. > > Most virtual worlds act as both metaverse service providers (MSP) and > identity providers. This is a mistake. > > Tightly coupling the MSP and identity provider functions is why I have to > keep telling people that Mark McCahill is named Mysterio Sinister in Second > Life - I can't easily be mccahill@duke.edu because Second Life doesn't use > external federated identity providers. Then when I go to one of the OpenSim > worlds, I need to create another account, and hope that nobody has signed up > for Mysterio Sinister before I got there. > > Requiring avatars to create a new account/password at each of the different > metaverse service providers is not a very appealing prospect. Why aren't we > addressing the federated identity/presence issue now? There are a number of > existing approaches that could be relatively easily adopted across different > technologies and set the stage for deeper interoperability down the road. > > To make any real progress, we need agreement about standards for accepting > identities provided by other virtual worlds. Even better, how about > something that is not a virtual world (OAuth, OpenID, Shibboleth all come to > mind) an option as an identity provider? Solving this problem is a > prerequisite for making any real progress toward allowing free movement > across worlds. > > Why aren't we talking about standards for > > name@identity_provider > > authentication which could be used across worlds? > > > > Mark McCahill > OpenCroquet/Cobalt > > > On Feb 18, 2009, at 7:34 PM, Jon Watte wrote: >> >> So, what is an avatar anyway? I think it has one or more meshes (that are >> not standard), draped over a skeleton (that is not standard), with one or >> more textures applied (that are not standard). Avatars also represent users, >> which have identity. Avatars can move (physically, with collision >> detection), animate (interactions, emotes), voice communicate and text chat. >> >> If you can send that information ([identity, mesh, texture, skeleton] as >> set-up, and [movement, animation, interactions, voice and text chat] at >> runtime) then do you have an interoperable avatar? >> And, if so, what separates an avatar from another animated, movable >> object? Could the same way that avatars are interoperating be used to >> interoperate other simulated objects? From a remote systems' point of view, >> there's not that much difference between a human-driven avatar, and a >> tumbling rock -- the remote system can't be expected to run the simulation >> for either one, so it needs to have that stream of behavior to represent it. >> >> As far as I know Wonderland, Qwaq, Multiverse and other possible adopters, >> the above representations maps fairly straightforward to their systems, >> although any system will have to expect to write adaption code to accept >> "arbitrary" external meshes as avatars. >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From cs@comlounge.net Fri Feb 20 03:55:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12DED28C267 for ; Fri, 20 Feb 2009 03:55:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_36=0.6, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XCP7WdUAvcV for ; Fri, 20 Feb 2009 03:55:22 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 6B4353A6AF7 for ; Fri, 20 Feb 2009 03:55:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 4F11B1CE03AD; Fri, 20 Feb 2009 12:55:35 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lz6sVnkWZZpp; Fri, 20 Feb 2009 12:55:34 +0100 (CET) Received: from [192.168.1.20] (p5B395503.dip.t-dialin.net [91.57.85.3]) by post.comlounge.net (Postfix) with ESMTP id C13EE1CE0004; Fri, 20 Feb 2009 12:55:31 +0100 (CET) Message-ID: <499E9A30.3090907@comlounge.net> Date: Fri, 20 Feb 2009 12:55:28 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Jesrad References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> <747254.34293.qm@web82602.mail.mud.yahoo.com> <53cd6c2e0902200313vb27deej1ef395441d53d287@mail.gmail.com> In-Reply-To: <53cd6c2e0902200313vb27deej1ef395441d53d287@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 11:55:24 -0000 Jesrad wrote: > An example: the VW Solipsis ties its authentication service to > Facebook. That lets it integrate complex social services (groups, > friends, etc.) simply by adopting the Facebook Connect service. But > then Facebook very recently joined the OpenID Foundation Board, so it > seems they'll be taking care of that particular bit of > interoperability without additional effort from the Solipsis team (and > other projects that use the Connect service). Well, first it has to be seen if FB really opens up to use standards instead of running their own thing. But the move to join the OpenID foundation if of course promising. OpenID alone is not the answer though, you can do authentication with it but you only have a limited way to handle your profile data esp. because it's then bound to your OpenID provider (e.g. using Attribute Exchange). What people discuss right now as the so called "Open Stack" is a mix of OpenID for authentication, OAuth for authorization and OpenSocial REST API for reading and writing (nobody implemented write yet though) your profile data and friend connections. PortableContacts, an extension to OpenSocial might also come into the mix. This let's you retrieve the address book of some user so that you can then match up friends (instead of asking for gmail/hotmail/... passwords). So far MySpace has implemented OAuth and OpenSocial and called it MySpaceID, see http://developer.myspace.com/community/myspace/dataavailability.aspx > It seems the market already chose OpenID as an authentication > standard. The common VW operation at that level seems to be: > - keep an internal user base > - automatically create a new user from existing authentified IDs that > sign in if they don't exist > - manage a specific state for these new users from "outside" (the "no > payment info on file" from SL, the "unpaid account" state from > Vendetta-Online, etc.) > - may or may not allow the creation of purely internal (not exported > to the auth provider) IDs (this may lead to conflicting IDs ? should > the outside auth service take precedence ? Is this question out of > scope ?) I would say that the web sort of has settled on OpenID. That does not mean that this should be the only method to provide but certainly it should be one of those you can use. How the best practice is to store openids and how to attach them to your users is still somewhat unclear but people are actively talking about it, e.g. at the Facebook OpenID UX summit which happened 2 weeks ago or so. One point of discussion was e.g. also if OpenID should be URLs or email addresses, mostly because people are more familiar with the latter. -- Christian > > On Thu, Feb 19, 2009 at 7:52 PM, Charles Krinke wrote: >> Dear Mark: >> >> Yes, that is a place where we can make progress. I am in fact "Charles >> Krinke" on OSGrid, but I needed to be "Charlesk Bing" on SecondLife due to >> the rules of that particular grid. >> >> I have a gmail account, as many other folks to and thus I believe I already >> have an OpenID, so using OpenID is not unreasonable. >> >> I would personally suggest that we recommend at least two different >> authentication methods so as not to paint ourselves into a corner down the >> road a bit. >> >> Charles Krinke >> >> p.s. I would love to hear more about Croquet and how we can find ways to >> interop and teleport between SecondLife, OpenSim and Croquet. >> >> >> ________________________________ >> From: Mark P. McCahill >> To: mmox@ietf.org >> Sent: Thursday, February 19, 2009 10:26:51 AM >> Subject: [mmox] where is identity @ in all this? >> >> These worlds are fundamentally social environments. I would suggest starting >> with interoperability for federated identity and presence. >> >> At a minimum I want to know which worlds my buddies are currently playing >> in, and be able to chat with them, and be able to chat with people outside >> the virtual worlds. If there are any ambitions toward integrating presence >> in virtual worlds with more traditional audio, video, and text >> communications, then SIP and XMPP-based presence would be worth considering >> rather than re-inventing these functions. >> >> Most virtual worlds act as both metaverse service providers (MSP) and >> identity providers. This is a mistake. >> >> Tightly coupling the MSP and identity provider functions is why I have to >> keep telling people that Mark McCahill is named Mysterio Sinister in Second >> Life - I can't easily be mccahill@duke.edu because Second Life doesn't use >> external federated identity providers. Then when I go to one of the OpenSim >> worlds, I need to create another account, and hope that nobody has signed up >> for Mysterio Sinister before I got there. >> >> Requiring avatars to create a new account/password at each of the different >> metaverse service providers is not a very appealing prospect. Why aren't we >> addressing the federated identity/presence issue now? There are a number of >> existing approaches that could be relatively easily adopted across different >> technologies and set the stage for deeper interoperability down the road. >> >> To make any real progress, we need agreement about standards for accepting >> identities provided by other virtual worlds. Even better, how about >> something that is not a virtual world (OAuth, OpenID, Shibboleth all come to >> mind) an option as an identity provider? Solving this problem is a >> prerequisite for making any real progress toward allowing free movement >> across worlds. >> >> Why aren't we talking about standards for >> >> name@identity_provider >> >> authentication which could be used across worlds? >> >> >> >> Mark McCahill >> OpenCroquet/Cobalt >> >> >> On Feb 18, 2009, at 7:34 PM, Jon Watte wrote: >>> So, what is an avatar anyway? I think it has one or more meshes (that are >>> not standard), draped over a skeleton (that is not standard), with one or >>> more textures applied (that are not standard). Avatars also represent users, >>> which have identity. Avatars can move (physically, with collision >>> detection), animate (interactions, emotes), voice communicate and text chat. >>> >>> If you can send that information ([identity, mesh, texture, skeleton] as >>> set-up, and [movement, animation, interactions, voice and text chat] at >>> runtime) then do you have an interoperable avatar? >>> And, if so, what separates an avatar from another animated, movable >>> object? Could the same way that avatars are interoperating be used to >>> interoperate other simulated objects? From a remote systems' point of view, >>> there's not that much difference between a human-driven avatar, and a >>> tumbling rock -- the remote system can't be expected to run the simulation >>> for either one, so it needs to have that stream of behavior to represent it. >>> >>> As far as I know Wonderland, Qwaq, Multiverse and other possible adopters, >>> the above representations maps fairly straightforward to their systems, >>> although any system will have to expect to write adaption code to accept >>> "arbitrary" external meshes as avatars. >>> >>> Sincerely, >>> >>> jw >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox -- 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 cs@comlounge.net 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 belxjander@gmail.com Fri Feb 20 03:56:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F2483A68C7 for ; Fri, 20 Feb 2009 03:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EM4OfMfeg9x for ; Fri, 20 Feb 2009 03:56:42 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id DC3843A6AF7 for ; Fri, 20 Feb 2009 03:56:42 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so841225rvb.49 for ; Fri, 20 Feb 2009 03:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=KV7IAwB+rBdc0hmyVRDbKF7YtCZGi6HNY37ERD3CLOs=; b=opQWbKIurAvyeqNlXThynuc/buAaQfr29ccwhfeHCJJ+rcHkV166nnCSUq9QULPtEy LKWh6WNesDGJNERqkN3RyrMncxl+RbTl0VVVh8Lblp2LR4AkwPm5Jn20+HF9F3jJf+Hv rPa16CRoV4+uyKPcN5XKF3cZNeNistcafG71Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=e+VgB6W6HQIDjU3j8xf4ykggvJ415ExbJYBhMO/AhyAeumTZGq5ym9nGlbifELAmJ5 8q3Z0PRZDiSkP5inkqhb2cec2EXstNIagDA6jgQLeM8cz/k7m8B1PW6os5V3QRToBUhz zA6AhMNeDMelU+VAVOpSlg9YUqFM+IyEAAmbU= Received: by 10.141.172.20 with SMTP id z20mr383233rvo.226.1235131015728; Fri, 20 Feb 2009 03:56:55 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id l31sm5660593rvb.5.2009.02.20.03.56.53 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 03:56:54 -0800 (PST) From: Kajikawa Jeremy To: Charles Krinke In-Reply-To: <53cd6c2e0902200313vb27deej1ef395441d53d287@mail.gmail.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> <747254.34293.qm@web82602.mail.mud.yahoo.com> <53cd6c2e0902200313vb27deej1ef395441d53d287@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Pmrdgq2DCxiQBpj2aJow" Date: Fri, 20 Feb 2009 20:51:29 +0900 Message-Id: <1235130689.7560.148.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mmox@ietf.org Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 11:56:44 -0000 --=-Pmrdgq2DCxiQBpj2aJow Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Didn't the Croquet people try to co-opt your time in getting you to develop a module for them ? :) Apart from the above, I agree with regards the use of OpenID and I am trying to expand the AgentDomain I am building to include an incorporated UserAccount service that is OpenSIM compatible and have setup an osgridsvc.appspot.com implimentation that I want to hand over to the OpenSIM group, Im also going to be pushing the code upto the repository I setup on the forge site. I hope when It is complete (usable on and off GAE using WSGI) that it is useful. Im also going to include a MySQL/SQLite to site transfer tool as well. Belxjander (Jeremy / SecondLife+OSgrid=3DFreija.Yoshikawa) On Fri, 2009-02-20 at 12:13 +0100, Jesrad wrote: > An example: the VW Solipsis ties its authentication service to > Facebook. That lets it integrate complex social services (groups, > friends, etc.) simply by adopting the Facebook Connect service. But > then Facebook very recently joined the OpenID Foundation Board, so it > seems they'll be taking care of that particular bit of > interoperability without additional effort from the Solipsis team (and > other projects that use the Connect service). >=20 > It seems the market already chose OpenID as an authentication > standard. The common VW operation at that level seems to be: > - keep an internal user base > - automatically create a new user from existing authentified IDs that > sign in if they don't exist > - manage a specific state for these new users from "outside" (the "no > payment info on file" from SL, the "unpaid account" state from > Vendetta-Online, etc.) > - may or may not allow the creation of purely internal (not exported > to the auth provider) IDs (this may lead to conflicting IDs ? should > the outside auth service take precedence ? Is this question out of > scope ?) >=20 > On Thu, Feb 19, 2009 at 7:52 PM, Charles Krinke wrote: > > > > Dear Mark: > > > > Yes, that is a place where we can make progress. I am in fact "Charles > > Krinke" on OSGrid, but I needed to be "Charlesk Bing" on SecondLife due= to > > the rules of that particular grid. > > > > I have a gmail account, as many other folks to and thus I believe I alr= eady > > have an OpenID, so using OpenID is not unreasonable. > > > > I would personally suggest that we recommend at least two different > > authentication methods so as not to paint ourselves into a corner down = the > > road a bit. > > > > Charles Krinke > > > > p.s. I would love to hear more about Croquet and how we can find ways t= o > > interop and teleport between SecondLife, OpenSim and Croquet. > > > > > > ________________________________ > > From: Mark P. McCahill > > To: mmox@ietf.org > > Sent: Thursday, February 19, 2009 10:26:51 AM > > Subject: [mmox] where is identity @ in all this? > > > > These worlds are fundamentally social environments. I would suggest sta= rting > > with interoperability for federated identity and presence. > > > > At a minimum I want to know which worlds my buddies are currently playi= ng > > in, and be able to chat with them, and be able to chat with people outs= ide > > the virtual worlds. If there are any ambitions toward integrating prese= nce > > in virtual worlds with more traditional audio, video, and text > > communications, then SIP and XMPP-based presence would be worth conside= ring > > rather than re-inventing these functions. > > > > Most virtual worlds act as both metaverse service providers (MSP) and > > identity providers. This is a mistake. > > > > Tightly coupling the MSP and identity provider functions is why I have = to > > keep telling people that Mark McCahill is named Mysterio Sinister in Se= cond > > Life - I can't easily be mccahill@duke.edu because Second Life doesn't = use > > external federated identity providers. Then when I go to one of the Ope= nSim > > worlds, I need to create another account, and hope that nobody has sign= ed up > > for Mysterio Sinister before I got there. > > > > Requiring avatars to create a new account/password at each of the diffe= rent > > metaverse service providers is not a very appealing prospect. Why aren'= t we > > addressing the federated identity/presence issue now? There are a numbe= r of > > existing approaches that could be relatively easily adopted across diff= erent > > technologies and set the stage for deeper interoperability down the roa= d. > > > > To make any real progress, we need agreement about standards for accept= ing > > identities provided by other virtual worlds. Even better, how about > > something that is not a virtual world (OAuth, OpenID, Shibboleth all co= me to > > mind) an option as an identity provider? Solving this problem is a > > prerequisite for making any real progress toward allowing free movement > > across worlds. > > > > Why aren't we talking about standards for > > > > name@identity_provider > > > > authentication which could be used across worlds? > > > > > > > > Mark McCahill > > OpenCroquet/Cobalt > > > > > > On Feb 18, 2009, at 7:34 PM, Jon Watte wrote: > >> > >> So, what is an avatar anyway? I think it has one or more meshes (that = are > >> not standard), draped over a skeleton (that is not standard), with one= or > >> more textures applied (that are not standard). Avatars also represent = users, > >> which have identity. Avatars can move (physically, with collision > >> detection), animate (interactions, emotes), voice communicate and text= chat. > >> > >> If you can send that information ([identity, mesh, texture, skeleton] = as > >> set-up, and [movement, animation, interactions, voice and text chat] a= t > >> runtime) then do you have an interoperable avatar? > >> And, if so, what separates an avatar from another animated, movable > >> object? Could the same way that avatars are interoperating be used to > >> interoperate other simulated objects? From a remote systems' point of = view, > >> there's not that much difference between a human-driven avatar, and a > >> tumbling rock -- the remote system can't be expected to run the simula= tion > >> for either one, so it needs to have that stream of behavior to represe= nt it. > >> > >> As far as I know Wonderland, Qwaq, Multiverse and other possible adopt= ers, > >> the above representations maps fairly straightforward to their systems= , > >> although any system will have to expect to write adaption code to acce= pt > >> "arbitrary" external meshes as avatars. > >> > >> Sincerely, > >> > >> jw > >> > >> _______________________________________________ > >> mmox mailing list > >> mmox@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmox > > > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-Pmrdgq2DCxiQBpj2aJow Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJnplBAAoJECHrKutFYVwTPAcP/AlfTIszuELtY4FQVdLzXjEb SB1JbOIOLeEBznAP9R2m+5AAOaC6CN2jwwBBD9yke6qFtulzvy06gb05EIGbmiSC 5ErZLE+UK0jKKNKAcUITQz/5a+CCQ5K+StBTIkB3uYrvLFEOko6XhvBFyZH2Fkgz Ii/6xoAbIr020BnCadQQGhnRxYSnoIyaW1TIg3OKjDQqP6fmQ26Hd5xUgTeUTKy0 mcNn743SHdC3kyFGVqbqvU+GSL6ZAuEaX6URqTDdaahil0QJfE+djWM2bNRlBY5g sltDuh8o6VGWqol26qjjpgpL9wSNE6SB6sd85aop4UH1hjktZdijAqbPWKho/gjv wg/tIOlN5wKEh/gp5lKKjfNbrExK92LNwqUDK/X87jCaZ9L9eLxaZwbnyf6INp6i 5sdDytx5kgvw6DC0r3zoLRWU61euCyHGtGnLIg52YO5pHow+nNNBi5lmYO2XLZ/A tkMQhYwZ+QpxVAbgaqIZ6e/Jd2h5YDdNXIq53mcarKzTQEfabk+LIaSOpb7XGCGg cAbGlQZ5VaXVfy/VVJROOwOvelOCzCSQ4KMN2mXt7hvmH62QfreAVsgwdt21X9nc Z1kg7Qfv1ZQLkraPIug7wQH/KgDRCvk3UmE8A1JxMcY9P68yskBCp7u19UQMo+Jm JOa1oxQ/E6yqcHW/o02M =MYao -----END PGP SIGNATURE----- --=-Pmrdgq2DCxiQBpj2aJow-- From cfk@pacbell.net Fri Feb 20 07:28:43 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DBF73A6B8C for ; Fri, 20 Feb 2009 07:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RAfX4KVeJVl for ; Fri, 20 Feb 2009 07:28:42 -0800 (PST) Received: from web82608.mail.mud.yahoo.com (web82608.mail.mud.yahoo.com [68.142.201.125]) by core3.amsl.com (Postfix) with SMTP id D547F3A6B91 for ; Fri, 20 Feb 2009 07:28:41 -0800 (PST) Received: (qmail 67008 invoked by uid 60001); 20 Feb 2009 15:28:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=jHEpTC9dc7umfBZdiibFH732qJac6s9UYtc3K0coxJFYYw0Z+R0Z6KkaPQlogjIMkKxqsCHa69V31wSwtVHwP1b61jtcT6Bw9C3uywsnTjq9IbquMMvD2NCNoGnZv0peZIhupXdIqJZevEy0xr2QX7WVCQL9VoDfXrUmpphhhcI=; X-YMail-OSG: dCYKhccVM1nKTiwbDFIWvIE9AJDkMGSQvE1DF0q8DTTixPF_06J7dHEZEIuSdsSM9R_QrcPETpFahERG4VWJngdQuvf1Nk.m_QosBAoaMPs.hdo.g1G2_GxDyUXpzvRDZNzk_nX4GsJPyr7dZ8b8CT9UpNFyDRIM_SDBcS2a9QjMHZx.9UvH2u1I1y2xX0.JtLCBDnNeu.pmt4almdeawIg9I3Y- Received: from [76.222.233.250] by web82608.mail.mud.yahoo.com via HTTP; Fri, 20 Feb 2009 07:28:55 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> <61320.78349.qm@web82607.mail.mud.yahoo.com> Date: Fri, 20 Feb 2009 07:28:55 -0800 (PST) From: Charles Krinke To: "Meadhbh Hamrick \(Infinity\)" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1043640084-1235143735=:66993" Message-ID: <962799.66993.qm@web82608.mail.mud.yahoo.com> Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:28:43 -0000 --0-1043640084-1235143735=:66993 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps I am being naive here, but I dont see anything in the draft propos= al other then the definition of a few variable types and three mime definit= ions which seems completely innocuous to me.=0A=0AAdmittedly, follow on dra= ft proposals will undoubtedly favor one teams bias at the expense of anothe= r teams bias, but I cannot find a reason not to support this variable defin= ition and mime definition draft.=0A=0AThere is lots of time for us all to a= rgue that our own favorite is the best for the world, but it see= ms that any of the thoughts I have heard can all be built with this variabl= e name and type standard.=0A=0ACharles=0A=0A=0A=0A=0A______________________= __________=0AFrom: Meadhbh Hamrick (Infinity) =0ATo= : Charles Krinke =0ACc: "mmox@ietf.org" =0A= Sent: Thursday, February 19, 2009 10:38:46 PM=0ASubject: Re: [mmox] LLSD=0A= =0Aanything that uses LLSD and wants to be considered a "standard" must onl= y provide normative references that are also "standards".=0A=0Aessentially = the deal here is we think the RFCs that will eventually provide the authori= tative references for OGP should be put on the IETF "standards track." in f= act, this is the primary raison d'=EAtre for the proposed working group. if= OGP is to be a "real" IETF standard, all the documents it references as "n= ormative" need to be standards as well.=0A=0Athe alternative was to simply = continue publishing our interface documents on our wiki and perhaps publish= ing LLSD as an informational RFC. however... we thought it better to use ou= r existing OGP work as a starting point, put it out in a forum where the ex= pertise of the internet engineering community could be utilized to review, = comment and improve it. our objective is to create a robust, flexible famil= y of protocols usable by the widest practical community.=0A=0Aand for what = it's worth, in the context of the proposed working group OGP/Teleport and H= yperGrid are two proposals [1] for doing similar things. The two approaches= _do_ seem assume different trust models, and maybe the future is that both= will find wide adoption. the "define mechanism, not policy" mantra you som= etimes hear some people repeat implies that neither approach should preclud= e implementations from implementing both. this is rather like most modern e= mail user agents implementing both,POP3 _and_ IMAP. the two protocols do es= sentially the same thing, but there's nothing in either protocol that preve= nts you from using either or both in the same mail client.=0A=0Abut i rambl= e.=0A=0Athe question as i read it was "would trying to approve the draft of= LLSD preclude or perturb further protocols?" the answer i would give would= be "no. it shouldn't."=0A=0A-cheers=0A-meadhbh=0A=0A[1] - yes... actually = neither are currently internet drafts, but i believe John is working on som= ething HyperGridish and OGP/Teleport was listed on the draft charter of the= proposed working group.=0A=0AOn Feb 19, 2009, at 8:34 PM, Charles Krinke w= rote:=0A=0A> Ok, Meadhbh:=0A> =0A> In looking at this draft *and* hoping I = dont make my OpenSim peers too unhappy with me, let me ask a question.=0A> = =0A> "Is there any reason why trying to approve the draft LLSD spec would p= reclude or pertubate either OGP, HyperGrid or other similar notions from be= ing supported?"=0A> =0A> Charles=0A> =0A> From: Meadhbh Hamrick (Infinity) = =0A> To: Charles Krinke =0A> Cc: "= mmox@ietf.org" =0A> Sent: Thursday, February 19, 2009 8:10:0= 5 PM=0A> Subject: Re: [mmox] LLSD=0A> =0A> http://wiki.secondlife.com/wiki/= MMOX is non-authoritative, but yes LLSD is one of the work items we have on= the list.=0A> =0A> the objective of LLSD is to provide an abstract type sy= stem with multiple serializations. it also defines the mime types.=0A> =0A>= however, to say that the LLSD draft exists only to define the serializatio= ns is akin to saying that ASN.1 exists only to provide input into DER or BE= R encodings. the two are linked, but each has a particular use.=0A> =0A> LL= SD as an abstract type system allows us to define and reason about the sema= ntics of structured data used in PDUs independent of an existing implementa= tion language. the serialization rules allow us to format structured data p= rior to transport and later de-serialize it after receipt. the MIME type re= gistrations allow us to identify the serialization scheme used on transport= s that support the use of MIME types. LLIDL (pronounced "little") defines t= he set of expected parameters to and responses from a resource access.=0A> = =0A> LLSD was selected as the first draft to work on as it is used as a bui= lding block for other protocol interactions, some of which are published in= draft form on the second life wiki. the further development of these proto= cols is also considered a task of the proposed working group.=0A> =0A> -che= ers=0A> -meadhbh=0A> =0A> On Feb 19, 2009, at 7:52 PM, Charles Krinke wrote= :=0A> =0A>> In looking at the secondlife wiki at http://wiki.secondlife.com= /wiki/MMOX it looks like one of the first proposals for this working group = is the LLSD draft specification.=0A>> =0A>> Am I correct in that the gist o= f the LLSD specification is essentially to propose three mime formats and t= hats about it for now?=0A>> =0A>> application/llsd+xml=0A>> application/lls= d+json=0A>> application/llsd+binary=0A>> =0A>> Charles=0A>> _______________= ________________________________=0A>> mmox mailing list=0A>> mmox@ietf.org= =0A>> https://www.ietf.org/mailman/listinfo/mmox=0A> =0A> --0-1043640084-1235143735=:66993 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Perhaps  I am being naive here, but I dont see anything in the= draft proposal other then the definition of a few variable types and three= mime definitions which seems completely innocuous to me.

Admittedly= , follow on draft proposals will undoubtedly favor one teams bias at the ex= pense of another teams bias, but I cannot find a reason not to support this= variable definition and mime definition draft.

There is lots of tim= e for us all to argue that our own favorite <whatever> is the best fo= r the world, but it seems that any of the thoughts I have heard can all be = built with this variable name and type standard.

Charles

=
From: Meadhbh Hamrick (Infinity) <infinity= @lindenlab.com>
To: = Charles Krinke <cfk@pacbell.net>
Cc: "mmox@ietf.org" <mmox@ietf.org>
Sent: Thursday, February 19, 2009 10:38:= 46 PM
Subject: Re: [mmo= x] LLSD

=0Aanything that uses LLSD and wants to be considered= a "standard" must only provide normative references that are also "standar= ds".

essentially the deal here is we think the RFCs that will eventu= ally provide the authoritative references for OGP should be put on the IETF= "standards track." in fact, this is the primary raison d'=EAtre for the pr= oposed working group. if OGP is to be a "real" IETF standard, all the docum= ents it references as "normative" need to be standards as well.

the = alternative was to simply continue publishing our interface documents on ou= r wiki and perhaps publishing LLSD as an informational RFC. however... we t= hought it better to use our existing OGP work as a starting point, put it o= ut in a forum where the expertise of the internet engineering community cou= ld be utilized to review, comment and improve it. our objective is to creat= e a robust, flexible family of protocols usable by the widest practical com= munity.

and for what it's worth, in the context of the proposed working group OGP/Tele= port and HyperGrid are two proposals [1] for doing similar things. The two = approaches _do_ seem assume different trust models, and maybe the future is= that both will find wide adoption. the "define mechanism, not policy" mant= ra you sometimes hear some people repeat implies that neither approach shou= ld preclude implementations from implementing both. this is rather like mos= t modern email user agents implementing both,POP3 _and_ IMAP. the two proto= cols do essentially the same thing, but there's nothing in either protocol = that prevents you from using either or both in the same mail client.
but i ramble.

the question as i read it was "would trying to approv= e the draft of LLSD preclude or perturb further protocols?" the answer i wo= uld give would be "no. it shouldn't."

-cheers
-meadhbh

[1]= - yes... actually neither are currently internet drafts, but i believe John is working on something HyperGridish and OGP/Teleport was lis= ted on the draft charter of the proposed working group.

On Feb 19, 2= 009, at 8:34 PM, Charles Krinke wrote:

> Ok, Meadhbh:
> > In looking at this draft *and* hoping I dont make my OpenSim peers to= o unhappy with me, let me ask a question.
>
> "Is there any re= ason why trying to approve the draft LLSD spec would preclude or pertubate = either OGP, HyperGrid or other similar notions from being supported?"
&g= t;
> Charles
>
> From: Meadhbh Hamrick (Infinity) <<= a ymailto=3D"mailto:infinity@lindenlab.com" href=3D"mailto:infinity@lindenl= ab.com">infinity@lindenlab.com>
> To: Charles Krinke <cfk@pacbel= l.net>
> Cc: "mmox@ietf.org" <mmox@ietf.org>
> Sent: Thursday= , February 19, 2009 8:10:05 PM
> Subject: Re: [mmox] LLSD
> > ht= tp://wiki.secondlife.com/wiki/MMOX is non-authoritative, but yes LLSD i= s one of the work items we have on the list.
>
> the objective= of LLSD is to provide an abstract type system with multiple serializations= . it also defines the mime types.
>
> however, to say that the= LLSD draft exists only to define the serializations is akin to saying that= ASN.1 exists only to provide input into DER or BER encodings. the two are = linked, but each has a particular use.
>
> LLSD as an abstract= type system allows us to define and reason about the semantics of structur= ed data used in PDUs independent of an existing implementation language. th= e serialization rules allow us to format structured data prior to transport and later de-serialize it after receipt. the MIME type registrat= ions allow us to identify the serialization scheme used on transports that = support the use of MIME types. LLIDL (pronounced "little") defines the set = of expected parameters to and responses from a resource access.
> > LLSD was selected as the first draft to work on as it is used as a bu= ilding block for other protocol interactions, some of which are published i= n draft form on the second life wiki. the further development of these prot= ocols is also considered a task of the proposed working group.
>
= > -cheers
> -meadhbh
>
> On Feb 19, 2009, at 7:52 PM,= Charles Krinke wrote:
>
>> In looking at the secondlife wi= ki at ht= tp://wiki.secondlife.com/wiki/MMOX it looks like one of the first propo= sals for this working group is the LLSD draft specification.
>>
>> Am I correct in that the gist of the LLSD specification is es= sentially to propose three mime formats and thats about it for now?
>= >
>> application/llsd+xml
>> application/llsd+json>> application/llsd+binary
>>
>> Charles
>&= gt; _______________________________________________
>> mmox mailin= g list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo= /mmox
>
>

--0-1043640084-1235143735=:66993-- From jesrad@gmail.com Fri Feb 20 07:41:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EAD13A6A26 for ; Fri, 20 Feb 2009 07:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lhYaK+TX+Fh for ; Fri, 20 Feb 2009 07:41:34 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id D50DE3A6AD2 for ; Fri, 20 Feb 2009 07:41:33 -0800 (PST) Received: by bwz5 with SMTP id 5so2674053bwz.13 for ; Fri, 20 Feb 2009 07:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=p6vUZyGsmUmtjuLSkVC8hSZ2pU7a/Wd5HdXRlxdEDs0=; b=QwzmSV0rC26vvqtug2w7zC3+OU+LRVgR2R79ucpvPiJ5FVoeruOUxiGy/pRiwtw668 h1n/dTsDxU+zVVisR4J3XPOjlVatodbrnbHG8s/tk4Gcpr6t3EdhOzVZOWo+6eezH295 vxEZuUrzrFW+EQiQRoMQ2dHdVvimIPEW7LzOw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=WpRw3lom+MOCFOYIUe0RoWOmemKOtlbs37EZY11Y+aJ3Xf0dajqAREGzCOZPeZIHZM FEpATHvgEJrY51xedLaaGqfDFaNZ2NmQxABc7usHlfIdv+JTyg3kiOlhl9yU/zjkUoDc 70CvEJ1KoVy69CM3SwHG6yc1/g4IKXfydXShQ= MIME-Version: 1.0 Received: by 10.181.239.8 with SMTP id q8mr319908bkr.109.1235144507701; Fri, 20 Feb 2009 07:41:47 -0800 (PST) In-Reply-To: <962799.66993.qm@web82608.mail.mud.yahoo.com> References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> <61320.78349.qm@web82607.mail.mud.yahoo.com> <962799.66993.qm@web82608.mail.mud.yahoo.com> Date: Fri, 20 Feb 2009 16:41:47 +0100 Message-ID: <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> From: Jesrad To: Charles Krinke , "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mmox] LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:41:36 -0000 Just to be sure: LLSD in the context of MMOX is meant to fulfill roughly the same goal as ASN.1 (http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One) does in general communications ? On Fri, Feb 20, 2009 at 4:28 PM, Charles Krinke wrote: > Perhaps I am being naive here, but I dont see anything in the draft > proposal other then the definition of a few variable types and three mime > definitions which seems completely innocuous to me. > > Admittedly, follow on draft proposals will undoubtedly favor one teams bi= as > at the expense of another teams bias, but I cannot find a reason not to > support this variable definition and mime definition draft. > > There is lots of time for us all to argue that our own favorite > is the best for the world, but it seems that any of the thoughts I have > heard can all be built with this variable name and type standard. > > Charles > > ________________________________ > From: Meadhbh Hamrick (Infinity) > To: Charles Krinke > Cc: "mmox@ietf.org" > Sent: Thursday, February 19, 2009 10:38:46 PM > Subject: Re: [mmox] LLSD > > anything that uses LLSD and wants to be considered a "standard" must only > provide normative references that are also "standards". > > essentially the deal here is we think the RFCs that will eventually provi= de > the authoritative references for OGP should be put on the IETF "standards > track." in fact, this is the primary raison d'=EAtre for the proposed wor= king > group. if OGP is to be a "real" IETF standard, all the documents it > references as "normative" need to be standards as well. > > the alternative was to simply continue publishing our interface documents= on > our wiki and perhaps publishing LLSD as an informational RFC. however... = we > thought it better to use our existing OGP work as a starting point, put i= t > out in a forum where the expertise of the internet engineering community > could be utilized to review, comment and improve it. our objective is to > create a robust, flexible family of protocols usable by the widest practi= cal > community. > > and for what it's worth, in the context of the proposed working group > OGP/Teleport and HyperGrid are two proposals [1] for doing similar things= . > The two approaches _do_ seem assume different trust models, and maybe the > future is that both will find wide adoption. the "define mechanism, not > policy" mantra you sometimes hear some people repeat implies that neither > approach should preclude implementations from implementing both. this is > rather like most modern email user agents implementing both,POP3 _and_ IM= AP. > the two protocols do essentially the same thing, but there's nothing in > either protocol that prevents you from using either or both in the same m= ail > client. > > but i ramble. > > the question as i read it was "would trying to approve the draft of LLSD > preclude or perturb further protocols?" the answer i would give would be > "no. it shouldn't." > > -cheers > -meadhbh > > [1] - yes... actually neither are currently internet drafts, but i believ= e > John is working on something HyperGridish and OGP/Teleport was listed on = the > draft charter of the proposed working group. > > On Feb 19, 2009, at 8:34 PM, Charles Krinke wrote: > >> Ok, Meadhbh: >> >> In looking at this draft *and* hoping I dont make my OpenSim peers too >> unhappy with me, let me ask a question. >> >> "Is there any reason why trying to approve the draft LLSD spec would >> preclude or pertubate either OGP, HyperGrid or other similar notions fro= m >> being supported?" >> >> Charles >> >> From: Meadhbh Hamrick (Infinity) >> To: Charles Krinke >> Cc: "mmox@ietf.org" >> Sent: Thursday, February 19, 2009 8:10:05 PM >> Subject: Re: [mmox] LLSD >> >> http://wiki.secondlife.com/wiki/MMOX is non-authoritative, but yes LLSD = is >> one of the work items we have on the list. >> >> the objective of LLSD is to provide an abstract type system with multipl= e >> serializations. it also defines the mime types. >> >> however, to say that the LLSD draft exists only to define the >> serializations is akin to saying that ASN.1 exists only to provide input >> into DER or BER encodings. the two are linked, but each has a particular >> use. >> >> LLSD as an abstract type system allows us to define and reason about the >> semantics of structured data used in PDUs independent of an existing >> implementation language. the serialization rules allow us to format >> structured data prior to transport and later de-serialize it after recei= pt. >> the MIME type registrations allow us to identify the serialization schem= e >> used on transports that support the use of MIME types. LLIDL (pronounced >> "little") defines the set of expected parameters to and responses from a >> resource access. >> >> LLSD was selected as the first draft to work on as it is used as a >> building block for other protocol interactions, some of which are publis= hed >> in draft form on the second life wiki. the further development of these >> protocols is also considered a task of the proposed working group. >> >> -cheers >> -meadhbh >> >> On Feb 19, 2009, at 7:52 PM, Charles Krinke wrote: >> >>> In looking at the secondlife wiki at http://wiki.secondlife.com/wiki/MM= OX >>> it looks like one of the first proposals for this working group is the = LLSD >>> draft specification. >>> >>> Am I correct in that the gist of the LLSD specification is essentially = to >>> propose three mime formats and thats about it for now? >>> >>> application/llsd+xml >>> application/llsd+json >>> application/llsd+binary >>> >>> Charles >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> >> > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From cfk@pacbell.net Fri Feb 20 07:52:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ABA83A6B42 for ; Fri, 20 Feb 2009 07:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLPf-9qzZMq9 for ; Fri, 20 Feb 2009 07:52:12 -0800 (PST) Received: from web82608.mail.mud.yahoo.com (web82608.mail.mud.yahoo.com [68.142.201.125]) by core3.amsl.com (Postfix) with SMTP id 83AB63A67DD for ; Fri, 20 Feb 2009 07:52:12 -0800 (PST) Received: (qmail 88161 invoked by uid 60001); 20 Feb 2009 15:52:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=OymBUZTdh1yrTss+9xo+GFYw/eursej33tNUrmUd9LsIA1W0VCQGftLehLzIPFSc4yUbWRNSYvizhbEsKPeELLGnDaQCFgxh+0q10nr0x4bb+ist3CS7kSYHGAasGRxnLaehoFLRWEEgMovqvKL+ZTGGpB7YBZwF8+n5LmXVF30=; X-YMail-OSG: jCCoB_AVM1nzzQnN9KKS7ad_6OVqFujiVijwS39NIm4zf9Ll4_QfyrLGwbnoYRhQ4MY6su7NDF1ym477QvDgtX4QOPwBSjJb4bA_fkCYkGw0Yqna2Q_qD9FgAY.2uLRgPU4SA0TXslm5ty7PXjL7jcYUH4BpxBW3MAu7lGVucEfQKSa3W1I2PW5_xLkBSPyYfrbgW7Q4zLD12Q9Q5sDPJJ6_dOA- Received: from [76.222.233.250] by web82608.mail.mud.yahoo.com via HTTP; Fri, 20 Feb 2009 07:52:26 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> <61320.78349.qm@web82607.mail.mud.yahoo.com> <962799.66993.qm@web82608.mail.mud.yahoo.com> <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> Date: Fri, 20 Feb 2009 07:52:26 -0800 (PST) From: Charles Krinke To: Jesrad , "mmox@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-635164324-1235145146=:88068" Message-ID: <215028.88068.qm@web82608.mail.mud.yahoo.com> Subject: Re: [mmox] LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:52:14 -0000 --0-635164324-1235145146=:88068 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Certainly, and that is an interesting issue in itself. =0A=0AMy assumption = is that the LL team picked the simplist place to start from in the spirit o= f gaining momentum with an IETF working group.=0A=0AI can see lots of inter= esting and spirited discussions on the horizon over all the things that hav= e been mentioned on this list in the last few days including :=0A=0A1. Iden= tification & Authorization ala OpenID and others.=0A2. The balance between = server side and client side functionality.=0A3. Avatar definition consisten= t to render an avatar with and without scripted attachments in various virt= ual worlds.=0A4. Objects moving from one virtual world to another with vari= ous associated permissions.=0A=0ABut, none of this is described in the draf= t at all. As I look at it, it seems this is a reasonable way for this group= to gain credibility with the ietf with a very basic draft and then this is= to be followed up with more structure later. =0A=0AWhether or not the vari= able and mime definitions help innovation for virtual worlds and if they ar= e, how to lay the foundation for the greatest flexibility certainly seems l= ike a more interesting and relevant discussion then whether or not joe can = drive is BatMobile through the FarGate between Croquet and Fortrerra and ex= pect all the scripted weapons to be blazing.=0A=0ACharles=0A=0A=0A=0A=0A___= _____________________________=0AFrom: Jesrad =0ATo: Charl= es Krinke ; "mmox@ietf.org" =0ASent: Friday= , February 20, 2009 7:41:47 AM=0ASubject: Re: [mmox] LLSD=0A=0AJust to be s= ure: LLSD in the context of MMOX is meant to fulfill=0Aroughly the same goa= l as ASN.1=0A(http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One) do= es in=0Ageneral communications ?=0A=0AOn Fri, Feb 20, 2009 at 4:28 PM, Char= les Krinke wrote:=0A> Perhaps I am being naive here, but= I dont see anything in the draft=0A> proposal other then the definition of= a few variable types and three mime=0A> definitions which seems completely= innocuous to me.=0A>=0A> Admittedly, follow on draft proposals will undoub= tedly favor one teams bias=0A> at the expense of another teams bias, but I = cannot find a reason not to=0A> support this variable definition and mime d= efinition draft.=0A>=0A> There is lots of time for us all to argue that our= own favorite =0A> is the best for the world, but it seems that a= ny of the thoughts I have=0A> heard can all be built with this variable nam= e and type standard.=0A>=0A> Charles=0A>=0A> ______________________________= __=0A> From: Meadhbh Hamrick (Infinity) =0A> To: Ch= arles Krinke =0A> Cc: "mmox@ietf.org" =0A> = Sent: Thursday, February 19, 2009 10:38:46 PM=0A> Subject: Re: [mmox] LLSD= =0A>=0A> anything that uses LLSD and wants to be considered a "standard" mu= st only=0A> provide normative references that are also "standards".=0A>=0A>= essentially the deal here is we think the RFCs that will eventually provid= e=0A> the authoritative references for OGP should be put on the IETF "stand= ards=0A> track." in fact, this is the primary raison d'=EAtre for the propo= sed working=0A> group. if OGP is to be a "real" IETF standard, all the docu= ments it=0A> references as "normative" need to be standards as well.=0A>=0A= > the alternative was to simply continue publishing our interface documents= on=0A> our wiki and perhaps publishing LLSD as an informational RFC. howev= er... we=0A> thought it better to use our existing OGP work as a starting p= oint, put it=0A> out in a forum where the expertise of the internet enginee= ring community=0A> could be utilized to review, comment and improve it. our= objective is to=0A> create a robust, flexible family of protocols usable b= y the widest practical=0A> community.=0A>=0A> and for what it's worth, in t= he context of the proposed working group=0A> OGP/Teleport and HyperGrid are= two proposals [1] for doing similar things.=0A> The two approaches _do_ se= em assume different trust models, and maybe the=0A> future is that both wil= l find wide adoption. the "define mechanism, not=0A> policy" mantra you som= etimes hear some people repeat implies that neither=0A> approach should pre= clude implementations from implementing both. this is=0A> rather like most = modern email user agents implementing both,POP3 _and_ IMAP.=0A> the two pro= tocols do essentially the same thing, but there's nothing in=0A> either pro= tocol that prevents you from using either or both in the same mail=0A> clie= nt.=0A>=0A> but i ramble.=0A>=0A> the question as i read it was "would tryi= ng to approve the draft of LLSD=0A> preclude or perturb further protocols?"= the answer i would give would be=0A> "no. it shouldn't."=0A>=0A> -cheers= =0A> -meadhbh=0A>=0A> [1] - yes... actually neither are currently internet = drafts, but i believe=0A> John is working on something HyperGridish and OGP= /Teleport was listed on the=0A> draft charter of the proposed working group= .=0A>=0A> On Feb 19, 2009, at 8:34 PM, Charles Krinke wrote:=0A>=0A>> Ok, M= eadhbh:=0A>>=0A>> In looking at this draft *and* hoping I dont make my Open= Sim peers too=0A>> unhappy with me, let me ask a question.=0A>>=0A>> "Is th= ere any reason why trying to approve the draft LLSD spec would=0A>> preclud= e or pertubate either OGP, HyperGrid or other similar notions from=0A>> bei= ng supported?"=0A>>=0A>> Charles=0A>>=0A>> From: Meadhbh Hamrick (Infinity)= =0A>> To: Charles Krinke =0A>> Cc= : "mmox@ietf.org" =0A>> Sent: Thursday, February 19, 2009 8:= 10:05 PM=0A>> Subject: Re: [mmox] LLSD=0A>>=0A>> http://wiki.secondlife.com= /wiki/MMOX is non-authoritative, but yes LLSD is=0A>> one of the work items= we have on the list.=0A>>=0A>> the objective of LLSD is to provide an abst= ract type system with multiple=0A>> serializations. it also defines the mim= e types.=0A>>=0A>> however, to say that the LLSD draft exists only to defin= e the=0A>> serializations is akin to saying that ASN.1 exists only to provi= de input=0A>> into DER or BER encodings. the two are linked, but each has a= particular=0A>> use.=0A>>=0A>> LLSD as an abstract type system allows us t= o define and reason about the=0A>> semantics of structured data used in PDU= s independent of an existing=0A>> implementation language. the serializatio= n rules allow us to format=0A>> structured data prior to transport and late= r de-serialize it after receipt.=0A>> the MIME type registrations allow us = to identify the serialization scheme=0A>> used on transports that support t= he use of MIME types. LLIDL (pronounced=0A>> "little") defines the set of e= xpected parameters to and responses from a=0A>> resource access.=0A>>=0A>> = LLSD was selected as the first draft to work on as it is used as a=0A>> bui= lding block for other protocol interactions, some of which are published=0A= >> in draft form on the second life wiki. the further development of these= =0A>> protocols is also considered a task of the proposed working group.=0A= >>=0A>> -cheers=0A>> -meadhbh=0A>>=0A>> On Feb 19, 2009, at 7:52 PM, Charle= s Krinke wrote:=0A>>=0A>>> In looking at the secondlife wiki at http://wiki= .secondlife.com/wiki/MMOX=0A>>> it looks like one of the first proposals fo= r this working group is the LLSD=0A>>> draft specification.=0A>>>=0A>>> Am = I correct in that the gist of the LLSD specification is essentially to=0A>>= > propose three mime formats and thats about it for now?=0A>>>=0A>>> applic= ation/llsd+xml=0A>>> application/llsd+json=0A>>> application/llsd+binary=0A= >>>=0A>>> Charles=0A>>> _______________________________________________=0A>= >> mmox mailing list=0A>>> mmox@ietf.org=0A>>> https://www.ietf.org/mailman= /listinfo/mmox=0A>>=0A>>=0A>=0A>=0A> ______________________________________= _________=0A> mmox mailing list=0A> mmox@ietf.org=0A> https://www.ietf.org/= mailman/listinfo/mmox=0A>=0A>=0A --0-635164324-1235145146=:88068 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Certainly, and that is an interesting issue in itself.

My a= ssumption is that the LL team picked the simplist place to start from in th= e spirit of gaining momentum with an IETF working group.

I can see l= ots of interesting and spirited discussions on the horizon over all the thi= ngs that have been mentioned on this list in the last few days including :<= br>
1. Identification & Authorization ala OpenID and others.
2. T= he balance between server side and client side functionality.
3. Avatar = definition consistent to render an avatar with and without scripted attachm= ents in various virtual worlds.
4. Objects moving from one virtual world= to another with various associated permissions.

But, none of this i= s described in the draft at all. As I look at it, it seems this is a reasonable way for this group to gain credibility with the ietf with a ver= y basic draft and then this is to be followed up with more structure later.=

Whether or not the variable and mime definitions help innovation f= or virtual worlds and if they are, how to lay the foundation for the greate= st flexibility certainly seems like a more interesting and relevant discuss= ion then whether or not joe can drive is BatMobile through the FarGate betw= een Croquet and Fortrerra and expect all the scripted weapons to be blazing= .

Charles

<= b>From: Jesrad <jesrad@gma= il.com>
To: Charles = Krinke <cfk@pacbell.net>; "mmox@ietf.org" <mmox@ietf.org>
Sent: Friday, February 20, 2009 7:= 41:47 AM
Subject: Re: [= mmox] LLSD

=0AJust to be sure: LLSD in the context of MMOX is= meant to fulfill
roughly the same goal as ASN.1
(http:/= /en.wikipedia.org/wiki/Abstract_Syntax_Notation_One) does in
general= communications ?

On Fri, Feb 20, 2009 at 4:28 PM, Charles Krinke &l= t;cfk= @pacbell.net> wrote:
> Perhaps  I am being naive here, bu= t I dont see anything in the draft
> proposal other then the definiti= on of a few variable types and three mime
> definitions which seems c= ompletely innocuous to me.
>
> Admittedly, follow on draft prop= osals will undoubtedly favor one teams bias
> at the expense of anoth= er teams bias, but I cannot find a reason not to
> support this varia= ble definition and mime definition draft.
>
> There is lots of = time for us all to argue that our own favorite <whatever>
> is the best for the world, but i= t seems that any of the thoughts I have
> heard can all be built with= this variable name and type standard.
>
> Charles
>
&= gt; ________________________________
> From: Meadhbh Hamrick (Infinit= y) <infinity@lindenlab.com>
> To: Charles Krinke &= lt;cf= k@pacbell.net>
> Cc: "mmox@ietf.org" <mmox@ietf.org>
> Sent:= Thursday, February 19, 2009 10:38:46 PM
> Subject: Re: [mmox] LLSD>
> anything that uses LLSD and wants to be considered a "standa= rd" must only
> provide normative references that are also "standards".
>
> essentially the deal here is we think the RFC= s that will eventually provide
> the authoritative references for OGP= should be put on the IETF "standards
> track." in fact, this is the = primary raison d'=EAtre for the proposed working
> group. if OGP is t= o be a "real" IETF standard, all the documents it
> references as "no= rmative" need to be standards as well.
>
> the alternative was = to simply continue publishing our interface documents on
> our wiki a= nd perhaps publishing LLSD as an informational RFC. however... we
> t= hought it better to use our existing OGP work as a starting point, put it> out in a forum where the expertise of the internet engineering commu= nity
> could be utilized to review, comment and improve it. our objec= tive is to
> create a robust, flexible family of protocols usable by = the widest practical
> community.
>
> and for what it's worth, in the context of the proposed working group
> OGP/Telep= ort and HyperGrid are two proposals [1] for doing similar things.
> T= he two approaches _do_ seem assume different trust models, and maybe the> future is that both will find wide adoption. the "define mechanism, n= ot
> policy" mantra you sometimes hear some people repeat implies tha= t neither
> approach should preclude implementations from implementin= g both. this is
> rather like most modern email user agents implement= ing both,POP3 _and_ IMAP.
> the two protocols do essentially the same= thing, but there's nothing in
> either protocol that prevents you fr= om using either or both in the same mail
> client.
>
> bu= t i ramble.
>
> the question as i read it was "would trying to = approve the draft of LLSD
> preclude or perturb further protocols?" t= he answer i would give would be
> "no. it shouldn't."
>
> -cheers
> -meadhbh
>
> [1] -= yes... actually neither are currently internet drafts, but i believe
&g= t; John is working on something HyperGridish and OGP/Teleport was listed on= the
> draft charter of the proposed working group.
>
> O= n Feb 19, 2009, at 8:34 PM, Charles Krinke wrote:
>
>> Ok, M= eadhbh:
>>
>> In looking at this draft *and* hoping I don= t make my OpenSim peers too
>> unhappy with me, let me ask a quest= ion.
>>
>> "Is there any reason why trying to approve the= draft LLSD spec would
>> preclude or pertubate either OGP, HyperG= rid or other similar notions from
>> being supported?"
>>=
>> Charles
>>
>> From: Meadhbh Hamrick (Infinit= y) <infinity@lindenlab.com>
>> To: Charles Krinke <cfk@pacbell.net>
>> Cc: "mmox@ietf.org" <mmox@ietf.org><= br>>> Sent: Thursday, February 19, 2009 8:10:05 PM
>> Subjec= t: Re: [mmox] LLSD
>>
>> http://wiki.secondlife.com/wiki/MMOX= is non-authoritative, but yes LLSD is
>> one of the work items we= have on the list.
>>
>> the objective of LLSD is to prov= ide an abstract type system with multiple
>> serializations. it al= so defines the mime types.
>>
>> however, to say that the= LLSD draft exists only to define the
>> serializations is akin to= saying that ASN.1 exists only to provide input
>> into DER or BER encodings. the two are linked, but each has a particular
>> use.<= br>>>
>> LLSD as an abstract type system allows us to define= and reason about the
>> semantics of structured data used in PDUs= independent of an existing
>> implementation language. the serial= ization rules allow us to format
>> structured data prior to trans= port and later de-serialize it after receipt.
>> the MIME type reg= istrations allow us to identify the serialization scheme
>> used o= n transports that support the use of MIME types. LLIDL (pronounced
>&= gt; "little") defines the set of expected parameters to and responses from = a
>> resource access.
>>
>> LLSD was selected as= the first draft to work on as it is used as a
>> building block f= or other protocol interactions, some of which are published
>> in = draft form on the second life wiki. the further development of these
>> protocols is also considered a task of the proposed work= ing group.
>>
>> -cheers
>> -meadhbh
>>=
>> On Feb 19, 2009, at 7:52 PM, Charles Krinke wrote:
>>=
>>> In looking at the secondlife wiki at http://wiki.secondlife.com/wi= ki/MMOX
>>> it looks like one of the first proposals for th= is working group is the LLSD
>>> draft specification.
>&g= t;>
>>> Am I correct in that the gist of the LLSD specificat= ion is essentially to
>>> propose three mime formats and thats = about it for now?
>>>
>>> application/llsd+xml
&= gt;>> application/llsd+json
>>> application/llsd+binary>>>
>>> Charles
>>> ____________________= ___________________________
>>> mmox mailing list
>>> mmox@ietf.org
>>> https://www.ietf.org/mailman/l= istinfo/mmox
>>
>>
>
>
> __________= _____________________________________
> mmox mailing list
> mmox@ietf.or= g
> https://www.ietf.org/mailman/listinfo/mmox
>
><= br>
--0-635164324-1235145146=:88068-- From markl@lindenlab.com Fri Feb 20 09:07:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E05028C12B for ; Fri, 20 Feb 2009 09:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hvwLdMWFITm for ; Fri, 20 Feb 2009 09:07:24 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id BD59228C175 for ; Fri, 20 Feb 2009 09:07:24 -0800 (PST) Received: from nil.lindenlab.com (nil.lindenlab.com [10.1.16.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id EB2093DBC463 for ; Fri, 20 Feb 2009 09:07:38 -0800 (PST) Message-Id: <58B39BFD-ECBB-4887-AC47-33D49E48B762@lindenlab.com> From: Mark Lentczner To: mmox@ietf.org In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D50262E1E@rrsmsx506.amr.corp.intel.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4--855579137 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 09:07:38 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <80E946E9-5C62-4E00-BE8C-A15513898F99@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <50FD3E60-C7D4-4ACC-94BF-E05565A36D14@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D50262E1E@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [mmox] More LLIDL questions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 17:07:25 -0000 --Apple-Mail-4--855579137 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Feb 19, 2009, at 5:56 PM, Hurliman, John wrote: > Last question. I found this snippet of LLIDL from the agent login > draft proposal on the Second Life wiki: Gosh, I hope this won't be the *last* question! I'm really glad you are diving into this draft to this level of detail! > agents: [ first_name: string, last_name: string ... ] This was valid in an earlier, internal form of LLIDL. The intent was, as Meadhbh said, was to describe an array of values, grouped in twos. As you pointed out, the current valid way to do this is: agents: [ string, string, ... ] The intent of the member-like names was so that the specification could name the members of the grouping, not that those members-like names appeared in the LLSD in any way. The confusion that ensued from that design seemed more than the utility it provided, so we removed it at a later stage. I think this discussion proves the point! In any event, this kind of construction probably shouldn't be encouraged in APIs. Your alternative structure is far preferable from the standpoint of extensibility and understanding: > agents: [ { first_name: string, last_name: string } ... ] - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com --Apple-Mail-4--855579137 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Feb 19, 2009, at 5:56 = PM, Hurliman, John wrote:
Last = question. I found this snippet of LLIDL from the agent login draft = proposal on the Second Life wiki:
Gosh, I = hope this won't be the *last* question! I'm really glad you are diving = into this draft to this level of detail!

agents: [ first_name: string, last_name: string ... = ]

This was valid in an earlier, = internal form of LLIDL. The intent was, as Meadhbh said, was to describe = an array of values, grouped in twos. As you pointed out, the current = valid way to do this is:

agents: [ string, string, ... = ]

The intent of the member-like names was so = that the specification could name the members of the grouping, not that = those members-like names appeared in the LLSD in any way. The confusion = that ensued from that design seemed more than the utility it provided, = so we removed it at a later stage. I think this discussion proves the = point!

In any event, this kind of construction = probably shouldn't be encouraged in APIs. Your alternative structure is = far preferable from the standpoint of extensibility and = understanding:

agents: [ { first_name: string, last_name: string } ... = ]

- = Mark


Mark = Lentczner
Sr. Systems Architect
Technology = Integration
Linden Lab


Zero Linden




= --Apple-Mail-4--855579137-- From john.hurliman@intel.com Fri Feb 20 10:24:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46D2A3A6969 for ; Fri, 20 Feb 2009 10:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o52IMsoGeEtZ for ; Fri, 20 Feb 2009 10:24:39 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 195223A68AC for ; Fri, 20 Feb 2009 10:24:38 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 20 Feb 2009 10:24:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,242,1233561600"; d="scan'208";a="112789172" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by azsmga001.ch.intel.com with ESMTP; 20 Feb 2009 10:24:53 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Fri, 20 Feb 2009 11:24:53 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Fri, 20 Feb 2009 11:24:45 -0700 Thread-Topic: [mmox] where is identity @ in all this? Thread-Index: AcmS5pAl/dLHTon1TTO5wbiAG/5HJgAndaBA Message-ID: <62BFE5680C037E4DA0B0A08946C0933D502630AC@rrsmsx506.amr.corp.intel.com> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> <62BFE5680C037E4DA0B0A08946C0933D501FE800@rrsmsx506.amr.corp.intel.com> <499DE5A4.50705@comlounge.net> In-Reply-To: <499DE5A4.50705@comlounge.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {192BED1E-70A5-4B98-A63E-31ED407E6164} x-cr-hashedpuzzle: gCQ= Am/i AzX1 BmYY C3/L C46V DYhB FDm1 GuT1 G+us Hjqn H2eI JMfj KKPU KuZ7 K2iM; 1; bQBtAG8AeABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {192BED1E-70A5-4B98-A63E-31ED407E6164}; agBvAGgAbgAuAGgAdQByAGwAaQBtAGEAbgBAAGkAbgB0AGUAbAAuAGMAbwBtAA==; Fri, 20 Feb 2009 18:24:45 GMT; UgBFADoAIABbAG0AbQBvAHgAXQAgAHcAaABlAHIAZQAgAGkAcwAgAGkAZABlAG4AdABpAHQAeQAgAEAAIABpAG4AIABhAGwAbAAgAHQAaABpAHMAPwA= acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 18:24:40 -0000 >-----Original Message----- >From: Christian Scholz [mailto:cs@comlounge.net] >Sent: Thursday, February 19, 2009 3:05 PM >To: Hurliman, John >Cc: mmox@ietf.org >Subject: Re: [mmox] where is identity @ in all this? > >Hurliman, John schrieb: >> That is the identity proposal I'm working on. OpenID + OpenID Token >Exchange* + OpenID Attribute Exchange =3D=3D VW Identity Service. >> >> * OAuth was specifically designed for a three legged scenario, and >when you start adding in more services such as content, messaging, >voice, etc. it no longer becomes feasible. OpenID Token Exchange solves >this problem nicely though. > >Can you elaborate what the specific problem with OAuth is? Is it that >you'd need to authorize each and every service as a user? (the same >problem is coming up on the web as well though if you think about data >in all sorts of places you might want to give somebody access to) > OAuth seems to be solving a different problem. OAuth is great for putting i= dentity+authorization into a token, but in many cases (at least in the virt= ual world scenario) your identity provider and the authorization provider f= or a resource are two separate domains. What is needed is a way to pass aro= und identity in a token, which is what the OpenID Token Exchange protocol d= oes. The fact that every authorized token request in OAuth flows through th= e end user is great for authorization requests and the use cases it was des= igned for, but makes it a non starter for providing a temporary identity-on= ly token between services. The use case I've drawn up for virtual worlds involves a user, an identity = provider, a content provider, and a world simulator (doesn't matter how man= y separate services this is, assume a single trust domain for now). The use= r tells the world simulator that it has an identity at http://identityprovi= der.com/user which initiates the OpenID authentication sequence. Logging in= to a world simulator is implicitly giving it access to a minimum set of you= r profile information on the identity provider and appearance data on the c= ontent provider. This is facilitated with an identity token request from th= e world simulator to the identity service, and that token is passed to the = content service. The content service can then confirm the validity of the t= oken and grant access to a minimum set of content. OAuth definitely has wider adoption than OpenID Token Exchange, and if you = see a way to make this scenario work with OAuth (without too many contortio= ns) please let me know. >And what are you planning to use Attribute Exchange (AX) for? We >discussed using this in the DataPortability Group a while back for >storing the URL to your service catalogue that way but the problem was a >bit lack of adoption. I also tried to do some tests with myopenid but it >seemed that I couldn't store new fields. > >If it's for profile retrieval the OpenSocial REST API is IMHO a better >fit as it's a) easier to implement and b) more discussed and already >adopted by e.g. myspace (and yahoo is talking about it). > I doubt any identity provider will let you start storing arbitrary data on = their server. My understanding of AX is that identity providers can map the= ir existing identity+profile information to well recognized AX fields and p= rovide whatever information they have. Avatars will likely require unique f= ields, such as the URL of appearance data. If OpenSocial provides a better = or better adopted way of doing that then it's worth investigation. It might= also mean that it's premature to standardize on one or the other. That see= ms to leave the options: 1) leave attribute retrieval out of scope (doesn't= do much to solve interoperability), 2) make up our own standard based on L= LSD/LLIDL (makes the situation even worse, and goes against the proposed go= als of the draft MMOX charter), or 3) support multiple implementations (inc= reases the complexity of the spec, and creates excess cruft once one of the= competing proposals dies out). From dyerbrookme@juno.com Fri Feb 20 10:50:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E1683A6B7C for ; Fri, 20 Feb 2009 10:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLfyTv9IVHxg for ; Fri, 20 Feb 2009 10:50:22 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id A07393A6986 for ; Fri, 20 Feb 2009 10:50:22 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail05.vgs.untd.com [10.181.12.145]) by smtpout05.vgs.untd.com with SMTP id AABE37854APTRDAA for (sender ); Fri, 20 Feb 2009 10:50:34 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkN+DrwQqgC0+0/VJzvk05ZPw== Received: (from dyerbrookme@juno.com) by webmail05.vgs.untd.com (jqueuemail) id N9U7EAHK; Fri, 20 Feb 2009 10:49:36 PST Received: from [68.161.198.3] by webmail05.vgs.untd.com with HTTP: Fri, 20 Feb 2009 18:48:55 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Fri, 20 Feb 2009 18:48:55 GMT To: jwatte@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090220.134855.24682.1@webmail05.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 12:6:1819465472 X-MAIL-INFO: 40e5d56dd57d797919452d6d458d4138686809c9bdacf1688c8c898c9c5d5de15d78e958a17919006dcc75bd0c0105adddadd981a9d1f8d1d8d9d9dd3848f8387168293939313cb57cb8390505580575eded15eda85c9cb9d9ddc8f8f5ecdcddc9d1e9fc7d21080965450c450001012dbd1d0cbdf9b8b51c1cec4da5785d1ce9e9a1e9556c6ccd6c0879b9cc012d410c7dad292d4945a8ddd948c875f898599888c9c9c871685971e85da5ededad9989d131eda8a805a8f528280d2838dccc5cc9c8f159d919f1e83879bd0c0c X-UNTD-Peer-Info: 10.181.12.145|webmail05.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 18:50:25 -0000 >However, we do have customers who are asking for interoperability, and = are prepared to pay for it. That's why I'm here. If you're thinking of i= nteroperability only in the sense of the Second Life grid, using Second = Life protocols, serving Second Life customers, I don't think that's some= thing the IETF should care much about. Jon, in your other posts you seem to make a hard distinction between "bu= siness users" which are large corporations, and other users which you se= em to imply have no money, or only small wallets to buy dresses. But col= lectively, the users of Second Life, including all the content-creators = and merchants, represent *as powerful a financial force* for a platform = provider as their original venture capitalists and as their best big ent= erprise customers. In Second Life, those small businesses inworld scorne= d by some as "socializers" collectively pay more of the tier (server mai= ntenance fees) than any other category of customer, and therefore make u= p the provider's bottom line. = The mass of *these* users and their tier have not spoken in favour of in= teroperability as the issue hasn't even been put to them, nor the implic= ations outlined. You as Forterra may have big clients who care about int= eroperability, but they have other ways to protect = their content (firewalls, centralized content clearance, teams of lawyer= s) and have different motivations for "interoperability" than the averag= e world user. >As I said, that's up to each platform vendor. The important thing is to= enable the metadata to travel with the content, and to empower the = sending side to make determinations about: a) who they interoperate with b) what specific content will and won't interoperate based on local poli= cy. How Linden Labs decides to apply policy to content created by Linden= Lab users is totally separate from how the interoperability specificati= on should treat interoperable content, and should not be subject of disc= ussion on this list (just like I won't discuss my customer specifics on = this list). You're assuming that Linden Lab simply won't let pass through its gates = an object that is not marked for transfer. But Linden Lab's entire world= has been reverse-engineered in OpenSim! (yes, based on the reverse-engi= neering of libsecondlife originally). And Linden = Lab already has stood by while Second Inventory, a system that enables c= opying all your inventory and holding it offline, has functioned, with p= eople then re-uploading the content to the OpenSim reverse-engineered pl= atform. There, we are to expect that the permissions will "hold" but tha= t grid has no permissions and a decided copyleftist outlook on these mat= ters. Already copying of entire islands and builds, not to mention indiv= idual content like trees and clothing, are sprouting up all over the Ope= nSim grids, which have spawned dozens of sub-grids. This is not some the= oretical matter. SI says they only enable downloading of inventory for w= hich you have permissions, = yet the uploading into the next grid takes place in an environment with = no c/m/d. In the There.com/Forterra context, customer content is cleared through a= centralized clearing house and must be approved by the company before i= t can be uploaded; customers are in a subordinate role. In Second Life, = content-makers and scripters and animators appear as equals to the platf= orm provider when it comes to content generation, and in fact have produ= ced the lion's share of the world's content, unlike other worlds where t= he platform providers make all the content. Therefore this isn't just so= me "customer specifics" that has to be routed through the company, as yo= u prefer. If Linden Lab and its AWG members (including IBM) do not wish to defend = c/m/d going forward into interoperability, then in a sense, they've decl= ared on behalf of the extremist position to remove it inworld: http://jira.secondlife.com/browse/VWR-2909 Could the members of this list comment on their dual positions, supporti= ng c/m/d tacitly inworld in SL, but not for the Metaverse? >I think you have misunderstood my proposal. My proposal is that the cop= y semantics should be explicitly part of the metadata, and should be enf= orced on the sending side, according to the EULA of that sending = side. If an object is marked "do not copy" then the sending side won't = send it, and the object won't interoperate. Exactly how each producer = implements that is beside the scope of any standard, though. For = example, if Linden Labs decides to apply a default policy of = "interoperable" to all existing content, or to apply a default policy of= "not interoperable," is entirely outside of the scope of any standard o= r standards discussion. It's a Linden-specific matter. That's what *you* say as you theorize it; it's not what Linden Lab has s= aid. Linden Lab has been asked by users whether a flag can be placed on = objects indicating a creator's wishes to let an object port to another g= rid or not, and has remained silent on that prospect: http://jira.secondlife.com/browse/MISC-1272 A further quest for clarification also has no answer: http://jira.secondlife.com/browse/MISC-1277 Let you or Dan Olivares think that somehow the 30-40 people voting on th= is "doesn't represent anything" (something that isn't an avowed generic = concern of IETF in its own governance regime), look at other JIRAs such = as a popular one calling for action against texture theft to understand = the magnitide of the concern about this by people who = make real money, not play money: http://jira.secondlife.com/browse/SVC-676 (1003 votes) >In fact, I am arguing that we should enable exactly what you're = describing! I don't understand how you belive I'm not. I think it's very simple: you have to clarify whether you are for puttin= g copy/mod/transfer permissions on objects or not. In There.com, this issue is solved by not having such things appear on t= he object at all, because the solution is to have a centralized clearing= house for content. Private customers on private grids that Forterra han= dles don't have this issue because they have firewalls and military clea= rances and such. But we're in the open Metaverse. So the issue is how, in an open world, where user content is generated o= n demand, going forward into interoperability with other grids, these pe= rmissions once established by Linden Lab can be respected -- and respect= ed not by telling everybody to call their lawyers, file a DMCA, or put i= n a notecard with a CC license, but implemented with a = technical solution, even an imperfect one. It depends on whether you mean c/m/d in the metadata, and whether you ar= e putting the onus for prevention of non-permed content to go to other g= rids on the original grid operator. What if the original sending grid op= erator doesn't care, or is hacked, then are = you not willing to put any responsibility on the receiving grid? = ____________________________________________________________ Free information - Scholarships for college, university or tech school.= Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEakCWUCwpioOh44oxV2Z8= dg6el4A6DgYwceHqeIAvEH5WQdSgno0/ From yesha.sivan@gmail.com Wed Feb 18 12:49:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27063A6959 for ; Wed, 18 Feb 2009 12:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98KIMlPt6PDi for ; Wed, 18 Feb 2009 12:49:43 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 159E73A67AD for ; Wed, 18 Feb 2009 12:49:42 -0800 (PST) Received: by bwz5 with SMTP id 5so245166bwz.13 for ; Wed, 18 Feb 2009 12:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=36KQjU4H9Yb9cxWNnDG6UiXgRhIaTqo0X4qT0U64AHY=; b=OiNjA2X1CyM7yPehIVrCVDct3paCrHEunEQVll1LxHWBb5d4aGb8kFBj0XWR2N/5LD +whHBlco66yaiUPvkJYRQORy2iMxS6Shyn56Vl/mDTttn7k6jDmkLZJX+3K5Ap98DTPY nShgVexXq82B/y9jXJBYMwPSoOrrQvfRZRTXM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=mcAgsrELyrvYGaOtBYLmxzbjyjf+k+Qy1DEGxmMJxPgZEczB9AEvNTEp6FL94gpyi8 6efq7bAl+BQfzBjz4cv0FC2YjPPMUvvzL+5M5CyD5otU+xU33QMRGsvIfLNH4JKIGVlt lu9F2PY3YYQV6nXSlM7F+UT3VA9509/yG7rGU= MIME-Version: 1.0 Sender: yesha.sivan@gmail.com Received: by 10.102.234.18 with SMTP id g18mr5029837muh.102.1234990193293; Wed, 18 Feb 2009 12:49:53 -0800 (PST) In-Reply-To: References: Date: Wed, 18 Feb 2009 22:49:52 +0200 X-Google-Sender-Auth: 859fd84b2752fb0b Message-ID: <3e3ef2f00902181249q47b56d2bw4b1aa57d053ba1b2@mail.gmail.com> From: Yesha Sivan To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636416d11c5ba840463378fb0 X-Mailman-Approved-At: Fri, 20 Feb 2009 10:53:00 -0800 Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 20:50:42 -0000 --001636416d11c5ba840463378fb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Friends (real and virtual, current and future): My name is Yesha Sivan and I'm the technical coordinator of the Metaverse1 EU based group (www.metaverse1.org) -- we are the leading team behind MPEG-V. I have worked on standards for virtual worlds (and real worlds) for 2 years now -- mainly taking the approach that we need a formal official process. MPEG was our choice. In my academic life I teach courses in software design (and virtual worlds), as well as MBA (and virtual worlds), and... fashion (and virtual worlds). I can actually teach any XX and virtual worlds course and I will have lots of fun with it. In my business life I work for Metaverse Labs which is a consulting firm (mainly working with VCs and policy makers, as well as on strategy issues for IT). In SL I'm Dera Kit (but not enough in-world as I want or should). Blog: www.dryesha.com In virtual worlds I'm best known for the "3D3C" theory (3D, Community, Creation, Commerce) which I have spoken/written in many places. One of the latest places (and also some other good quality materials) is here: http://www.dryesha.com/2008/09/cutter-journal-finding-real-world-value.html For my older work on standards see: http://www.dryesha.com/2000/12/yeshas-five-dimentions-of-standards.html I also want to invite people to write papers for a special issue of the Journal of Virtual Worlds -- I'm co-editing about Virtual Worlds: Technology, Economy, and Standards. http://www.dryesha.com/2009/01/cfp-virtual-worlds-technology-economy.html Looking forward to the work here... --Yesha Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual Worlds. On Wed, Feb 18, 2009 at 12:33 AM, Mark Lentczner wrote: > Friends - > > As if the internet weren't already full of multiple monikers for everyone, > many of us have only met in virtual worlds. I suspect that I've met some of > you in person, via e-mail, and in Second Life, and that I don't know that > all three of you are the same! > > Having so many multiple personalities shakes my own sense of self, so I > thought I'd start a thread of introductions. I'll go first: > > I'm Mark Lentczner. I'm the Sr. Systems Architect at Linden Lab. I've been > working on Second Life for over three years, mostly on evolving the > architecture of this growing virtual world. Many of you know me from AWG > meetings and my office hours as Zero Linden. > > Work Identities: > e-mail: markl (at) lindenlab (dot) com > web: > https://wiki.secondlife.com/wiki/User:Zero_Linden > Second Life: Zero Linden > > Personal Identities: > web: http://www.ozonehouse.com/mark/ > Second Life: Zarf Vantongerloo > > > - Mark > > Mark Lentczner > Sr. Systems Architect > Technology Integration > Linden Lab > > markl@lindenlab.com > > Zero Linden > zero.linden@secondlife.com > > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --001636416d11c5ba840463378fb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Friends (real and virtual, current and future):

My = name is Yesha Sivan and I'm the technical coordinator of the Metaverse1= EU based group (www.metaverse1.org) -- we are the leading team behind MPEG-V.

I have worked on standards for virtual worlds (and real worlds) for 2 y= ears now -- mainly taking the approach that we need a formal official proce= ss. MPEG was our choice.

In my academic life I teach courses in soft= ware design (and virtual worlds), as well as MBA (and virtual worlds), and.= .. fashion (and virtual worlds).  I can actually teach any XX and virt= ual worlds course and I will have lots of fun with it.

In my business life I work for Metaverse Labs which is a consulting fir= m (mainly working with VCs and policy makers, as well as on strategy issues= for IT).

In SL I'm Dera Kit (but not enough in-world as I want = or should).

Blog: www.dryesha.com

In = virtual worlds I'm best known for the "3D3C" theory (3D, Com= munity, Creation, Commerce) which I have spoken/written in many places. One= of the latest places (and also some other good quality materials) is here:=
http://www.dryesha.com/2008/09/cutter-journal-finding-real-wor= ld-value.html

For my older work on standards see:
http://www.dryesha.com/2000/12/yeshas-five-dimentions-of-standards= .html

I also want to invite people to write papers for a special issue of the= Journal of Virtual Worlds -- I'm co-editing
about Virtual Worlds: T= echnology, Economy, and Standards.
http://www.dryesha.com/200= 9/01/cfp-virtual-worlds-technology-economy.html

Looking forward to the work here...

--Yesha

Dr. Yesha Y. Sivan, http://www.dryesha.= com; Connecting Real and Virtual Worlds.


On Wed, Feb 18, 2009 at 12:33 AM, Mark L= entczner <markl= @lindenlab.com> wrote:
Friends -

As if the internet weren't already full of multiple monikers for everyo= ne, many of us have only met in virtual worlds. I suspect that I've met= some of you in person, via e-mail, and in Second Life, and that I don'= t know that all three of you are the same!

Having so many multiple personalities shakes my own sense of self, so I tho= ught I'd start a thread of introductions. I'll go first:

I'm Mark Lentczner. I'm the Sr. Systems Architect at Linden Lab. I&= #39;ve been working on Second Life for over three years, mostly on evolving= the architecture of this growing virtual world. Many of you know me from A= WG meetings and my office hours as Zero Linden.

Work Identities:
       e-mail:           &nbs= p;     markl (at) lindenlab (dot) com
       web:             =        https://wiki.secondlife.com/wiki/User:Zero_= Linden
       Second Life:          =  Zero Linden

Personal Identities:
       web:             =        http://www.ozonehouse.com/mark/
       Second Life:          =  Zarf Vantongerloo


       - Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

markl@lindenlab.co= m

Zero Linden
zero.linden= @secondlife.com





_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--001636416d11c5ba840463378fb0-- From yesha.sivan@gmail.com Thu Feb 19 11:47:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA48C28C108 for ; Thu, 19 Feb 2009 11:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yLgHLZzU2ay for ; Thu, 19 Feb 2009 11:47:19 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.188]) by core3.amsl.com (Postfix) with ESMTP id 4082E28C10B for ; Thu, 19 Feb 2009 11:47:19 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w9so555963mue.9 for ; Thu, 19 Feb 2009 11:47:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=jSL9cBzr5staMNhgylx0nfCb9acV3f0ZKRurEHk21Y0=; b=qT/SYVYMt/B4Gtfm7H+yWKjRewt+RHuEfrIb36fGuuN49gfkrn9QoX/VK4cWMmH9FW fhVBQfxoWuY/K0MbYlDw9JpcMk/I6LP7ZBe2cBFUKfFDMTSWqwvTm2+Z+keSnloCb2m0 xBQSXWphK96gTSsM/Up8Eu+9phrbw7Fh6b7Nc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=PKPQX8rsmarKicL6O7NUZbMmrgBjVrAm8x7ZY7CZNynynmOWMta6jWozJWzVrNJkRY Vw/3c/W80oHK6IXKT7k2gScw1rYtbcrKunFVv3MR6xRsFoTeUmjKYoq6leVUDvG5tcMs TI+B5P2LSPBaAl4+cckQllo0w8phKKJU+ZHR8= MIME-Version: 1.0 Sender: yesha.sivan@gmail.com Received: by 10.103.91.2 with SMTP id t2mr942302mul.47.1235072851167; Thu, 19 Feb 2009 11:47:31 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2009 21:47:30 +0200 X-Google-Sender-Auth: 6e9d66ef7b1e0a9a Message-ID: <3e3ef2f00902191147n487c28f0o56cf5845ff4aa404@mail.gmail.com> From: Yesha Sivan To: mmox@ietf.org Content-Type: multipart/alternative; boundary=00163662e56990c8ef04634ace28 X-Mailman-Approved-At: Fri, 20 Feb 2009 10:53:02 -0800 Subject: Re: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 19:47:20 -0000 --00163662e56990c8ef04634ace28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Friends (real and virtual, current and future): My name is Yesha Sivan and I'm the technical coordinator of the Metaverse1 EU based group (www.metaverse1.org) -- we are the leading team behind MPEG-V . I have worked on standards for virtual worlds (and real worlds) for 2 years now -- mainly taking the approach that we need a formal official process. MPEG was our choice. In my academic life I teach courses in software design (and virtual worlds), as well as MBA (and virtual worlds), and... fashion (and virtual worlds). I can actually teach any topic and virtual worlds course and I will have lots of fun with it. In my business life I work for Metaverse Labs which is a consulting firm (mainly working with VCs and policy makers, as well as on strategy issues for IT). In SL I'm Dera Kit (but not enough in-world as I want or should). Blog: www.dryesha.com In virtual worlds I'm best known for the "3D3C" theory (3D, Community, Creation, Commerce) which I have spoken/written in many places. One of the latest places is here: (it has other virtual worlds and enterprise it related papers) http://www.dryesha.com/2008/09/cutter-journal-finding-real-world-value.html For my older work on standards see: http://www.dryesha.com/2000/12/yeshas-five-dimentions-of-standards.html I also want to invite people to write papers for a special issue of the Journal of Virtual Worlds -- I'm co-editing about Virtual Worlds: Technology, Economy, and Standards. http://www.dryesha.com/2009/01/cfp-virtual-worlds-technology-economy.html Looking forward to the work here... --Yesha Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual Worlds. --00163662e56990c8ef04634ace28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Friends (real and virtual, current and future):

My = name is Yesha Sivan and I'm the technical coordinator of the Metaverse1= EU based group (w= ww.metaverse1.org) -- we are the leading team behind MPEG-V.

I have worked on standards for virtual worlds (and real worlds) for 2 years now -- mainly taking the approach that we need a formal official process. MPEG was our choice.
In my academic life I teach courses in software design (and virtual worlds), as well as MBA (and virtual worlds), and... fashion (and virtual worlds).  I can actually teach any topic and virtual worlds co= urse and I will have lots of fun with it.

In my business life I work for Metaverse Labs which is a consulting firm (mainly working with VCs and policy makers, as well as on strategy issues for IT).

In SL I'm Dera Kit (but not enough in-world as I= want or should).

Blog: www.dryesha= .com

In virtual worlds I'm best known for the "3D3C" theory (3D, Comm= unity, Creation, Commerce) which I have spoken/written in many places. One of the latest places  is here: (it has other virtual worlds and enterpris= e it related papers)
http://www.dryesha.com/2008/09/cutter-journa= l-finding-real-world-value.html

For my older work on standards see:
http://www.dryesha.com/2000/12/yeshas-five-dimen= tions-of-standards.html

I also want to invite people to write papers for a special issue of the= Journal of Virtual Worlds -- I'm co-editing
about Virtual Worlds: T= echnology, Economy, and Standards.
http://w= ww.dryesha.com/2009/01/cfp-virtual-worlds-technology-economy.html

Looking forward to the work here...

--Yesha

Dr. Yesha Y. Sivan, = http://www.dryesha.com; Connecting Real and Virtual Worlds.
--00163662e56990c8ef04634ace28-- From cfk@pacbell.net Fri Feb 20 11:11:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5409F3A69BC for ; Fri, 20 Feb 2009 11:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU-qSyGReShI for ; Fri, 20 Feb 2009 11:11:01 -0800 (PST) Received: from web82608.mail.mud.yahoo.com (web82608.mail.mud.yahoo.com [68.142.201.125]) by core3.amsl.com (Postfix) with SMTP id A010B3A68BB for ; Fri, 20 Feb 2009 11:11:01 -0800 (PST) Received: (qmail 66656 invoked by uid 60001); 20 Feb 2009 19:11:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=IEPnd6GxLsUKpIL8IaM9tfZh/wxJHBATrn6iDJ+VoqkdCtCE3Ki1oadmLQ4J/LLrNQ0cyb8DeZaKLZvTOc7ZbmiXiohMe2rsGLRoLnSOgv54HcMXN86iKVCSucyDJkVvU4X2JYizer6HKOydjJ1j1lZjnd6UYItQ8CV9R/oDJwE=; X-YMail-OSG: XHupOZoVM1m0iIeDtyZ8rUFR6zk7h4gbjJwr_EYFYPIl64eszSWQInQpojyUQjytyJXxeaQMwpq2KI_BdrldfCfBetQpFUvw6USvSwe1wvW1dtaVAimOKeU.iAbpluvSOSFbA5la.qNel17P_zSXyzOI Received: from [76.222.233.250] by web82608.mail.mud.yahoo.com via HTTP; Fri, 20 Feb 2009 11:11:15 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <20090220.134855.24682.1@webmail05.vgs.untd.com> Date: Fri, 20 Feb 2009 11:11:15 -0800 (PST) From: Charles Krinke To: "dyerbrookme@juno.com" , jwatte@gmail.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1608979506-1235157075=:65544" Message-ID: <932783.65544.qm@web82608.mail.mud.yahoo.com> Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:11:02 -0000 --0-1608979506-1235157075=:65544 Content-Type: text/plain; charset=us-ascii Dear David and Meadhbh: I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms. It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with. Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage? Charles Krinke --0-1608979506-1235157075=:65544 Content-Type: text/html; charset=us-ascii
Dear David and Meadhbh:

I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms.

It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with.

Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage?

Charles Krinke
--0-1608979506-1235157075=:65544-- From infinity@lindenlab.com Fri Feb 20 11:11:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C89B028C12B for ; Fri, 20 Feb 2009 11:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGF3LLHgxUBs for ; Fri, 20 Feb 2009 11:11:15 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 602DF3A68BB for ; Fri, 20 Feb 2009 11:11:15 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 078D63DBC455; Fri, 20 Feb 2009 11:11:30 -0800 (PST) Message-Id: <88DFFC67-0B59-4D65-86FB-8776899B794A@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jesrad In-Reply-To: <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 11:11:29 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com><80E946E9-5C62-4E00-BE8C-A15513898F99@lindenla b.com><62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com><29656.28734.qm@web82607.mail.mud.yahoo.com><61320.78349.qm@web82607.mail.mud.yahoo.com><962799.66993.qm@web82608.mail.mud.yahoo.com> <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:11:16 -0000 hey jesrad... conceptually ASN.1 and LLSD are similar, but LLSD is probably more =20 appropriate for accessing RESTful accesses over a HTTP(S)-like =20 transport. specifically... * LLSD was designed to be "less declarative" than ASN.1 . which is to =20= say, all LLSD components are optional, so it is never a transport-=20 layer error to not include a "required" parameter. * LLSD (including LLIDL) is considerably smaller. * the focus of LLSD is actually on the application layer, not on the =20 transport syntax; but yes... we spend an awful lot of space in the =20 draft talking about serializations, so this focus is sorta obscured =20 there. * LLSD is implementable by mortals in a tractable amount of time and =20 without the use of complicated third-party tools (ASN.1 compilers, etc.) * LLSD uses more consistent serializations (when compared with BER or =20= DER) so to recap ... LLSD and ASN.1 are similar, but LLSD was designed to transport =20 structured data that accepted extra parameters (or missing parameters) =20= in a PDU without the need to recompile and deploy new PDU parsers. -cheers -meadhbh On Feb 20, 2009, at 7:41 AM, Jesrad wrote: > Just to be sure: LLSD in the context of MMOX is meant to fulfill > roughly the same goal as ASN.1 > (http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One) does in > general communications ? > > On Fri, Feb 20, 2009 at 4:28 PM, Charles Krinke =20 > wrote: >> Perhaps I am being naive here, but I dont see anything in the draft >> proposal other then the definition of a few variable types and =20 >> three mime >> definitions which seems completely innocuous to me. >> >> Admittedly, follow on draft proposals will undoubtedly favor one =20 >> teams bias >> at the expense of another teams bias, but I cannot find a reason =20 >> not to >> support this variable definition and mime definition draft. >> >> There is lots of time for us all to argue that our own favorite =20 >> >> is the best for the world, but it seems that any of the thoughts I =20= >> have >> heard can all be built with this variable name and type standard. >> >> Charles >> >> ________________________________ >> From: Meadhbh Hamrick (Infinity) >> To: Charles Krinke >> Cc: "mmox@ietf.org" >> Sent: Thursday, February 19, 2009 10:38:46 PM >> Subject: Re: [mmox] LLSD >> >> anything that uses LLSD and wants to be considered a "standard" =20 >> must only >> provide normative references that are also "standards". >> >> essentially the deal here is we think the RFCs that will eventually =20= >> provide >> the authoritative references for OGP should be put on the IETF =20 >> "standards >> track." in fact, this is the primary raison d'=EAtre for the proposed = =20 >> working >> group. if OGP is to be a "real" IETF standard, all the documents it >> references as "normative" need to be standards as well. >> >> the alternative was to simply continue publishing our interface =20 >> documents on >> our wiki and perhaps publishing LLSD as an informational RFC. =20 >> however... we >> thought it better to use our existing OGP work as a starting point, =20= >> put it >> out in a forum where the expertise of the internet engineering =20 >> community >> could be utilized to review, comment and improve it. our objective =20= >> is to >> create a robust, flexible family of protocols usable by the widest =20= >> practical >> community. >> >> and for what it's worth, in the context of the proposed working group >> OGP/Teleport and HyperGrid are two proposals [1] for doing similar =20= >> things. >> The two approaches _do_ seem assume different trust models, and =20 >> maybe the >> future is that both will find wide adoption. the "define mechanism, =20= >> not >> policy" mantra you sometimes hear some people repeat implies that =20 >> neither >> approach should preclude implementations from implementing both. =20 >> this is >> rather like most modern email user agents implementing both,POP3 =20 >> _and_ IMAP. >> the two protocols do essentially the same thing, but there's =20 >> nothing in >> either protocol that prevents you from using either or both in the =20= >> same mail >> client. >> >> but i ramble. >> >> the question as i read it was "would trying to approve the draft of =20= >> LLSD >> preclude or perturb further protocols?" the answer i would give =20 >> would be >> "no. it shouldn't." >> >> -cheers >> -meadhbh >> >> [1] - yes... actually neither are currently internet drafts, but i =20= >> believe >> John is working on something HyperGridish and OGP/Teleport was =20 >> listed on the >> draft charter of the proposed working group. >> >> On Feb 19, 2009, at 8:34 PM, Charles Krinke wrote: >> >>> Ok, Meadhbh: >>> >>> In looking at this draft *and* hoping I dont make my OpenSim peers =20= >>> too >>> unhappy with me, let me ask a question. >>> >>> "Is there any reason why trying to approve the draft LLSD spec would >>> preclude or pertubate either OGP, HyperGrid or other similar =20 >>> notions from >>> being supported?" >>> >>> Charles >>> >>> From: Meadhbh Hamrick (Infinity) >>> To: Charles Krinke >>> Cc: "mmox@ietf.org" >>> Sent: Thursday, February 19, 2009 8:10:05 PM >>> Subject: Re: [mmox] LLSD >>> >>> http://wiki.secondlife.com/wiki/MMOX is non-authoritative, but yes =20= >>> LLSD is >>> one of the work items we have on the list. >>> >>> the objective of LLSD is to provide an abstract type system with =20 >>> multiple >>> serializations. it also defines the mime types. >>> >>> however, to say that the LLSD draft exists only to define the >>> serializations is akin to saying that ASN.1 exists only to provide =20= >>> input >>> into DER or BER encodings. the two are linked, but each has a =20 >>> particular >>> use. >>> >>> LLSD as an abstract type system allows us to define and reason =20 >>> about the >>> semantics of structured data used in PDUs independent of an existing >>> implementation language. the serialization rules allow us to format >>> structured data prior to transport and later de-serialize it after =20= >>> receipt. >>> the MIME type registrations allow us to identify the serialization =20= >>> scheme >>> used on transports that support the use of MIME types. LLIDL =20 >>> (pronounced >>> "little") defines the set of expected parameters to and responses =20= >>> from a >>> resource access. >>> >>> LLSD was selected as the first draft to work on as it is used as a >>> building block for other protocol interactions, some of which are =20= >>> published >>> in draft form on the second life wiki. the further development of =20= >>> these >>> protocols is also considered a task of the proposed working group. >>> >>> -cheers >>> -meadhbh >>> >>> On Feb 19, 2009, at 7:52 PM, Charles Krinke wrote: >>> >>>> In looking at the secondlife wiki at = http://wiki.secondlife.com/wiki/MMOX >>>> it looks like one of the first proposals for this working group =20 >>>> is the LLSD >>>> draft specification. >>>> >>>> Am I correct in that the gist of the LLSD specification is =20 >>>> essentially to >>>> propose three mime formats and thats about it for now? >>>> >>>> application/llsd+xml >>>> application/llsd+json >>>> application/llsd+binary >>>> >>>> Charles >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>> >>> >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From RGehorsam@forterrainc.com Fri Feb 20 11:14:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE293A68BB for ; Fri, 20 Feb 2009 11:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czxgDzVt4YVE for ; Fri, 20 Feb 2009 11:14:14 -0800 (PST) Received: from smtp.forterrainc.com (smtp.forterrainc.com [208.64.184.34]) by core3.amsl.com (Postfix) with ESMTP id 21E303A6840 for ; Fri, 20 Feb 2009 11:14:10 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2009 11:14:20 -0800 Message-ID: <9A27EF31A4DF2C4C8BB45D661B13BA87053504DB@MERCURY.forterrainc.com> In-Reply-To: <20090220.134855.24682.1@webmail05.vgs.untd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mmox] mmox Digest, Vol 1, Issue 45 thread-index: AcmTjEM3w7TeMCt0Ro+JgdIe0zlr1AAAU/pQ References: <20090220.134855.24682.1@webmail05.vgs.untd.com> From: "Robert Gehorsam" To: , Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:14:16 -0000 >> In the There.com/Forterra context, customer content is cleared through a centralized clearing house and must be approved by the company before it can be uploaded; customers are in a subordinate role. This assertion contains an incorrect assumption. It is true that in the There service, content goes through a central clearing house. Let's be clear: Forterra is a different company, with a substantially different technology, different market, different business model and different operation than Makena, the company that operates There. The common thread is the underlying IP which describes the technical architecture, but the actual code base is now quite different. Forterra does not own the servers on which its customers develop and operate their services and applications. Each customer (and its authorized end-users) are free to develop and deploy any content they want, and we play no role in that, even if a customer wants us to host their servers. We're happy to provide studio services to help people develop content, or provide pre-existing content packs for them as well, but that's just at customer request.. Same is true for functionality. In Forterra's model -- customers and end-users are actually in the drivers seat. Hope this helps. Robert -- by way of introduction, I'm part of the management of Forterra. I'm not a programmer or technologist, work mostly on the business and strategy side. But the interoperability issue has been central to what we see as the evolution of vw's, so I'm happy to follow the conversation and contribute wherever it makes sense. Robert Gehorsam President Forterra Systems 48 Wall Street, 11th floor | New York, NY |10005 212 918 4564 (o) | 212 918 4937 (f) | 917 817 8107 (m) rgehorsam@forterrainc.com www.forterrainc.com =20 -----Original Message----- From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of dyerbrookme@juno.com Sent: Friday, February 20, 2009 1:49 PM To: jwatte@gmail.com Cc: mmox@ietf.org; dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45 >However, we do have customers who are asking for interoperability, and are prepared to pay for it. That's why I'm here. If you're thinking of interoperability only in the sense of the Second Life grid, using Second Life protocols, serving Second Life customers, I don't think that's something the IETF should care much about. Jon, in your other posts you seem to make a hard distinction between "business users" which are large corporations, and other users which you seem to imply have no money, or only small wallets to buy dresses. But collectively, the users of Second Life, including all the content-creators and merchants, represent *as powerful a financial force* for a platform provider as their original venture capitalists and as their best big enterprise customers. In Second Life, those small businesses inworld scorned by some as "socializers" collectively pay more of the tier (server maintenance fees) than any other category of customer, and therefore make up the provider's bottom line.=20 The mass of *these* users and their tier have not spoken in favour of interoperability as the issue hasn't even been put to them, nor the implications outlined. You as Forterra may have big clients who care about interoperability, but they have other ways to protect their content (firewalls, centralized content clearance, teams of lawyers) and have different motivations for "interoperability" than the average world user. >As I said, that's up to each platform vendor. The important thing is to >enable the metadata to travel with the content, and to empower the sending side to make determinations about: a) who they interoperate with b) what specific content will and won't interoperate based on local policy. How Linden Labs decides to apply policy to content created by Linden Lab users is totally separate from how the interoperability specification should treat interoperable content, and should not be subject of discussion on this list (just like I won't discuss my customer specifics on this list). You're assuming that Linden Lab simply won't let pass through its gates an object that is not marked for transfer. But Linden Lab's entire world has been reverse-engineered in OpenSim! (yes, based on the reverse-engineering of libsecondlife originally). And Linden Lab already has stood by while Second Inventory, a system that enables copying all your inventory and holding it offline, has functioned, with people then re-uploading the content to the OpenSim reverse-engineered platform. There, we are to expect that the permissions will "hold" but that grid has no permissions and a decided copyleftist outlook on these matters. Already copying of entire islands and builds, not to mention individual content like trees and clothing, are sprouting up all over the OpenSim grids, which have spawned dozens of sub-grids. This is not some theoretical matter. SI says they only enable downloading of inventory for which you have permissions, yet the uploading into the next grid takes place in an environment with no c/m/d. In the There.com/Forterra context, customer content is cleared through a centralized clearing house and must be approved by the company before it can be uploaded; customers are in a subordinate role. In Second Life, content-makers and scripters and animators appear as equals to the platform provider when it comes to content generation, and in fact have produced the lion's share of the world's content, unlike other worlds where the platform providers make all the content. Therefore this isn't just some "customer specifics" that has to be routed through the company, as you prefer. If Linden Lab and its AWG members (including IBM) do not wish to defend c/m/d going forward into interoperability, then in a sense, they've declared on behalf of the extremist position to remove it inworld: http://jira.secondlife.com/browse/VWR-2909 Could the members of this list comment on their dual positions, supporting c/m/d tacitly inworld in SL, but not for the Metaverse? >I think you have misunderstood my proposal. My proposal is that the=20 >copy semantics should be explicitly part of the metadata, and should be >enforced on the sending side, according to the EULA of that sending side. If an object is marked "do not copy" then the sending side won't send it, and the object won't interoperate. Exactly how each producer implements that is beside the scope of any standard, though. For example, if Linden Labs decides to apply a default policy of "interoperable" to all existing content, or to apply a default policy of "not interoperable," is entirely outside of the scope of any standard or standards discussion. It's a Linden-specific matter. That's what *you* say as you theorize it; it's not what Linden Lab has said. Linden Lab has been asked by users whether a flag can be placed on objects indicating a creator's wishes to let an object port to another grid or not, and has remained silent on that prospect: http://jira.secondlife.com/browse/MISC-1272 A further quest for clarification also has no answer: http://jira.secondlife.com/browse/MISC-1277 Let you or Dan Olivares think that somehow the 30-40 people voting on this "doesn't represent anything" (something that isn't an avowed generic concern of IETF in its own governance regime), look at other JIRAs such as a popular one calling for action against texture theft to understand the magnitide of the concern about this by people who make real money, not play money: http://jira.secondlife.com/browse/SVC-676 (1003 votes) >In fact, I am arguing that we should enable exactly what you're describing! I don't understand how you belive I'm not. I think it's very simple: you have to clarify whether you are for putting copy/mod/transfer permissions on objects or not. In There.com, this issue is solved by not having such things appear on the object at all, because the solution is to have a centralized clearing house for content. Private customers on private grids that Forterra handles don't have this issue because they have firewalls and military clearances and such. But we're in the open Metaverse. So the issue is how, in an open world, where user content is generated on demand, going forward into interoperability with other grids, these permissions once established by Linden Lab can be respected -- and respected not by telling everybody to call their lawyers, file a DMCA, or put in a notecard with a CC license, but implemented with a=20 technical solution, even an imperfect one. It depends on whether you mean c/m/d in the metadata, and whether you are putting the onus for prevention of non-permed content to go to other grids on the original grid operator. What if the original sending grid operator doesn't care, or is hacked, then are=20 you not willing to put any responsibility on the receiving grid?=20 ____________________________________________________________ Free information - Scholarships for college, university or tech school. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEakCWUCwpioOh44oxV2Z8 dg6el4A6DgYwceHqeIAvEH5WQdSgno0/ _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox From dyerbrookme@juno.com Fri Feb 20 11:15:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04DE43A6868 for ; Fri, 20 Feb 2009 11:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dIugUJLzqBs for ; Fri, 20 Feb 2009 11:15:15 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 3A8903A6840 for ; Fri, 20 Feb 2009 11:15:15 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail05.vgs.untd.com [10.181.12.145]) by smtpout02.vgs.untd.com with SMTP id AABE38AKVAY7RR6S for (sender ); Fri, 20 Feb 2009 11:14:59 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNv8gC9QLDhmHxNCegWHErbg== Received: (from dyerbrookme@juno.com) by webmail05.vgs.untd.com (jqueuemail) id N9U8TTDS; Fri, 20 Feb 2009 11:14:28 PST Received: from [68.161.198.3] by webmail05.vgs.untd.com with HTTP: Fri, 20 Feb 2009 19:13:48 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Fri, 20 Feb 2009 19:13:48 GMT To: cfk@pacbell.net X-Mailer: Webmail Version 4.0 Message-Id: <20090220.141348.24682.2@webmail05.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 1:1:1882152980 X-UNTD-Peer-Info: 10.181.12.145|webmail05.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, jwatte@gmail.com, dyerbrookme@juno.com Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:15:16 -0000 I think that's an excellent idea for a business-like list. My real name in real life is Catherine A. Fitzpatrick and I reside in Ne= w York City. My avatar's name in Second Life is Prokofy Neva and I also = have an alt named Dyerbrook Parvenu, hence my email address for online l= ists which you see here. = ____________________________________________________________ Internet Advertising that Works. Click Now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTI2T9QtjYQcEQ3ttJRVD7r= wZJ6ErPWnf9Ww781jY9AQCbR85HfHhO/ From RGehorsam@forterrainc.com Fri Feb 20 11:27:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 665AE28C1D6 for ; Fri, 20 Feb 2009 11:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3wGxQlG7LxO for ; Fri, 20 Feb 2009 11:27:10 -0800 (PST) Received: from smtp.forterrainc.com (smtp.forterrainc.com [208.64.184.34]) by core3.amsl.com (Postfix) with ESMTP id A51953A67B4 for ; Fri, 20 Feb 2009 11:27:10 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99391.2D639814" Date: Fri, 20 Feb 2009 11:25:57 -0800 Message-ID: <9A27EF31A4DF2C4C8BB45D661B13BA87053504E3@MERCURY.forterrainc.com> In-Reply-To: <932783.65544.qm@web82608.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mmox] Real Names thread-index: AcmTjyRJ3FXiyKTVTqWMEuVnDz2y0wAAbhRQ References: <20090220.134855.24682.1@webmail05.vgs.untd.com> <932783.65544.qm@web82608.mail.mud.yahoo.com> From: "Robert Gehorsam" To: "Charles Krinke" , , Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:27:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99391.2D639814 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Charles, =20 I agree. =20 =20 I just use my real name anyway, real world and online (except in mmogs or SL where i can't.) =20 Robert Gehorsam ________________________________ From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of Charles Krinke Sent: Friday, February 20, 2009 2:11 PM To: dyerbrookme@juno.com; jwatte@gmail.com Cc: mmox@ietf.org; dyerbrookme@juno.com Subject: [mmox] Real Names Dear David and Meadhbh: I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms. It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with. Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage? Charles Krinke ------_=_NextPart_001_01C99391.2D639814 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Charles,
 
I agree. 
 
I just use my real name anyway, real world and online = (except=20 in mmogs or SL where i can't.)
 
Robert Gehorsam

From: mmox-bounces@ietf.org=20 [mailto:mmox-bounces@ietf.org] On Behalf Of Charles=20 Krinke
Sent: Friday, February 20, 2009 2:11 PM
To:=20 dyerbrookme@juno.com; jwatte@gmail.com
Cc: mmox@ietf.org;=20 dyerbrookme@juno.com
Subject: [mmox] Real = Names

Dear David=20 and Meadhbh:

I'm confused about some of the posts from email = addresses=20 that are either unsigned or from pseudonyms.

It seems entirely = reasonable=20 to me that real names be used in this mailing list to avoid wasting all = our time=20 and so that we know who whe are speaking with.

Is there some way = in an=20 IETF mailing list or by peer pressure to get this to a more businesslike = stage?

Charles Krinke
------_=_NextPart_001_01C99391.2D639814-- From infinity@lindenlab.com Fri Feb 20 11:31:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC283A6BEC for ; Fri, 20 Feb 2009 11:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.586 X-Spam-Level: X-Spam-Status: No, score=-3.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4BDI5BGfr91 for ; Fri, 20 Feb 2009 11:31:07 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 5ED9F3A688F for ; Fri, 20 Feb 2009 11:31:07 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 6F5B51414001; Fri, 20 Feb 2009 11:31:22 -0800 (PST) Message-Id: <19BA980F-90EE-408C-8C48-766A415EC0B9@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Charles Krinke In-Reply-To: <932783.65544.qm@web82608.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-3--846955512 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 11:31:22 -0800 References: <20090220.134855.24682.1@webmail05.vgs.untd.com> <932783.65544.qm@web82608.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org, jwatte@gmail.com, "dyerbrookme@juno.com" Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:31:08 -0000 --Apple-Mail-3--846955512 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit word from our IETF superiors is pseudonymous participation in the mailing list is acceptable. though it's worth reminding people that pseudonymity does not shield list members or their sponsoring organizations from the IPR disclosure requirements. also... IETF policy is that internet drafts must be submitted using an authors legal name. in terms of peer pressure? well... there's nothing to keep you from trying. historically, the IETF and the AWG seem to have a "more relaxed" working style than other groups i've seen. -cheers -meadhbh On Feb 20, 2009, at 11:11 AM, Charles Krinke wrote: > Dear David and Meadhbh: > > I'm confused about some of the posts from email addresses that are > either unsigned or from pseudonyms. > > It seems entirely reasonable to me that real names be used in this > mailing list to avoid wasting all our time and so that we know who > whe are speaking with. > > Is there some way in an IETF mailing list or by peer pressure to get > this to a more businesslike stage? > > Charles Krinke > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-3--846955512 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable word from our IETF superiors is = pseudonymous participation in the mailing list is = acceptable.

though it's worth reminding people that = pseudonymity does not shield list members or their sponsoring = organizations from the IPR disclosure = requirements.

also... IETF policy is that =  internet drafts must be submitted using an authors legal = name.

in terms of peer pressure? well... = there's nothing to keep you from trying. historically, the IETF and the = AWG seem to have a "more relaxed" working style than other groups i've = seen.

-cheers
-meadhbh

On Feb 20, 2009, at 11:11 AM, Charles Krinke wrote:

Dear David = and Meadhbh:

I'm confused about some of the posts from email = addresses that are either unsigned or from pseudonyms.

It seems = entirely reasonable to me that real names be used in this mailing list = to avoid wasting all our time and so that we know who whe are speaking = with.

Is there some way in an IETF mailing list or by peer = pressure to get this to a more businesslike stage?

Charles = Krinke
_______________________________________________
mmox = mailing list
mmox@ietf.org
https://www.ietf.org/m= ailman/listinfo/mmox

= --Apple-Mail-3--846955512-- From dwl@us.ibm.com Fri Feb 20 11:33:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D2828C206; Fri, 20 Feb 2009 11:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.631 X-Spam-Level: X-Spam-Status: No, score=-5.631 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYjg6B+Mn7LL; Fri, 20 Feb 2009 11:33:16 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id EA95028C1D6; Fri, 20 Feb 2009 11:33:15 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1KJV8wv023913; Fri, 20 Feb 2009 14:31:08 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1KJXUqY182740; Fri, 20 Feb 2009 14:33:30 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1KJWIwJ031545; Fri, 20 Feb 2009 14:32:19 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1KJWIt8031537; Fri, 20 Feb 2009 14:32:18 -0500 In-Reply-To: <932783.65544.qm@web82608.mail.mud.yahoo.com> To: Charles Krinke MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Fri, 20 Feb 2009 14:33:30 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/20/2009 14:33:29, Serialize complete at 02/20/2009 14:33:29 Content-Type: multipart/alternative; boundary="=_alternative 006B6FF085257563_=" Cc: mmox-bounces@ietf.org, mmox@ietf.org, jwatte@gmail.com, "dyerbrookme@juno.com" Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:33:17 -0000 This is a multipart message in MIME format. --=_alternative 006B6FF085257563_= Content-Type: text/plain; charset="US-ASCII" Well, I actually asked this one directly. People are free to do what they like, tho, every utterance is assumed to be made by the underlying human in the context of the "note well" constraints http://www.ietf.org/NOTEWELL.html In particular,the NOTEWELL brings attention to : http://www.ietf.org/rfc/rfc5378.txt http://www.ietf.org/rfc/rfc3979.txt and the bug fix update in http://www.ietf.org/rfc/rfc4879.txt My clear example, has been to sign everything with both names... - David W. Levine ~ Zha Ewry (ISL) Charles Krinke Sent by: mmox-bounces@ietf.org 02/20/2009 02:11 PM To "dyerbrookme@juno.com" , jwatte@gmail.com cc mmox@ietf.org, dyerbrookme@juno.com Subject [mmox] Real Names Dear David and Meadhbh: I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms. It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with. Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage? Charles Krinke_______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --=_alternative 006B6FF085257563_= Content-Type: text/html; charset="US-ASCII"
Well, I actually asked this one directly. People are free to do what they like, tho, every utterance is assumed to be made by the underlying human in the context of the
"note well" constraints http://www.ietf.org/NOTEWELL.html  In particular,the NOTEWELL brings attention to :http://www.ietf.org/rfc/rfc5378.txt  http://www.ietf.org/rfc/rfc3979.txt
and the bug fix update in http://www.ietf.org/rfc/rfc4879.txt  

My clear example, has been to sign everything with both names...

- David W. Levine
~ Zha Ewry (ISL)



Charles Krinke <cfk@pacbell.net>
Sent by: mmox-bounces@ietf.org

02/20/2009 02:11 PM

To
"dyerbrookme@juno.com" <dyerbrookme@juno.com>, jwatte@gmail.com
cc
mmox@ietf.org, dyerbrookme@juno.com
Subject
[mmox] Real Names





Dear David and Meadhbh:

I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms.

It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with.

Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage?

Charles Krinke_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--=_alternative 006B6FF085257563_=-- From jwatte@gmail.com Fri Feb 20 11:48:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A903A69CF for ; Fri, 20 Feb 2009 11:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROK27HxpXZTf for ; Fri, 20 Feb 2009 11:48:32 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id CB09F3A6868 for ; Fri, 20 Feb 2009 11:48:31 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so870046yxm.49 for ; Fri, 20 Feb 2009 11:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=w2ko8zl+KGygTIfdFAh2jHZZxM/XklQOpVOvKuy9m3Y=; b=oKeuew+ojHeG5gR36MLNpwoPRLFBp8mKVW1QaH9Pm9U/uyVP0JdS04idMuizWFsDx2 u1YYUPx3bqxd//tszybWQmSET6U6Yrwu+L/FEU5w+EE9ak8CS3yw5RLBWjRmR0BhewiO jX/XGWTgbBhUDFPHk+0NwNBSNp4ILyoe0s9RU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MC+uB1dSBpAAkFPsJYNRKfViok0OU2LC0SmzXT5rxWYtVduTifEvCWC+J42afQR/RU NjfJvEEdo2D83qYxh8PB8e7uZroiyzyboK+oZn3BXzNSAk5lUt5JoNMKPR1Cn4ZBVgCe T9FnE+s+tm6ZvVa1FQA89LhV0hXdpAlZoetCw= Received: by 10.100.253.7 with SMTP id a7mr1749402ani.103.1235159325587; Fri, 20 Feb 2009 11:48:45 -0800 (PST) Received: from ?192.168.168.110? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d38sm6637668and.29.2009.02.20.11.48.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 11:48:44 -0800 (PST) Message-ID: <499F091A.8010201@gmail.com> Date: Fri, 20 Feb 2009 11:48:42 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke References: <20090220.134855.24682.1@webmail05.vgs.untd.com> <932783.65544.qm@web82608.mail.mud.yahoo.com> In-Reply-To: <932783.65544.qm@web82608.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:48:32 -0000 Charles, I would support a "real names only" policy. I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration. Sincerely, jw Charles Krinke wrote: > Dear David and Meadhbh: > > I'm confused about some of the posts from email addresses that are > either unsigned or from pseudonyms. > > It seems entirely reasonable to me that real names be used in this > mailing list to avoid wasting all our time and so that we know who whe > are speaking with. > > Is there some way in an IETF mailing list or by peer pressure to get > this to a more businesslike stage? > > Charles Krinke From jwatte@gmail.com Fri Feb 20 11:58:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9F53A68C0 for ; Fri, 20 Feb 2009 11:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZr-VIePPuJb for ; Fri, 20 Feb 2009 11:58:50 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id ED7223A6359 for ; Fri, 20 Feb 2009 11:58:49 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so873836yxm.49 for ; Fri, 20 Feb 2009 11:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pcBUtMkiCMJ1lHgLflHn3qZb8GmGjjgJS52aa5Diqtk=; b=s5xupvkA5WPXCTYJys9V306htgyb7k7/fwnI67hp2lxZGgNfCtU0GFzkAeVHhHjntZ 7+FRyahdU4ThzQQMM4bmEkuJVrPBRpyFlDpumFhD8Sn21Cd8OcwNg5aFF8Ln4YBHTHCY yupOACJphLz7Ij7RkLu2ghoZV5kjriLpa5XqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xCCoQfE5EYnQEZ86KLI2S+O3zmaDYq16Yb53KSpRYFlD1PCV5XsVbsA8otvltFaSiF Io7hAw0qelxxtcrDwphRHOTzrmK0kfHLBf/+PBovxiXa0MXZgDEGsInhQ+bCJBT/exIo U/uS3etZFKuI5o+tvFfhS1iLWqORROLYAhUwU= Received: by 10.100.11.3 with SMTP id 3mr1759687ank.123.1235159944378; Fri, 20 Feb 2009 11:59:04 -0800 (PST) Received: from ?192.168.168.110? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d38sm4558663and.49.2009.02.20.11.59.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 11:59:03 -0800 (PST) Message-ID: <499F0B85.8060807@gmail.com> Date: Fri, 20 Feb 2009 11:59:01 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:58:51 -0000 Meadhbh Hamrick (Infinity) wrote: > DIS and HLA are "a bit complex" and were designed to provide services > that were vaguely different from what we're aiming at here. I don't > think we're interested in simulating just a battlefield of tanks. i > think what we're thinking about is a wire protocol that does not carry > a specific semantic load and is less declarative and more > proscriptive. that is to say.. DIS Agreed. That's why I think that the final solution will not be strictly based on DIS (and clearly not on HLA). However, I mention these protocols, because DIS has been extremely successful, and solves pretty much the same problem we're trying to solve, but in a narrower scope. Meanwhile, HLA has had a rocky history trying to solve the same problem; largely exactly /because /it is "mechanism, not policy" (or, in your words, proscriptive, not declarative). In HLA, you can theoretically support a number of object models (known as FOMs). This leads to virutal systems that are supposedly interoperable, not actually being able to interoperate, because semantics were left as an exercise for the reader. I think that learning from this past is crucial for any future virutal worlds standards effort. > >> Or do you want to use the Second Life system just because it's Second >> Life, even if it's not currently implemented or in current commercial >> use? > > again. > > we are not proposing the existing second life protocol for > standardization. i think we've said that several times. > > we would like to develop a protocol or protocol framework that is > "widely usable." > Me too! However, a number of people on this list have said that they believe the forums' goal is to standardize OGP and LLSD. I'd like everyone to agree that that's *not* the goal, and then stop talking about it. Sincerely, jw From missannotoole@yahoo.com Fri Feb 20 12:09:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815DA3A6858 for ; Fri, 20 Feb 2009 12:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id reJL029Md0YV for ; Fri, 20 Feb 2009 12:09:04 -0800 (PST) Received: from web59106.mail.re1.yahoo.com (web59106.mail.re1.yahoo.com [66.196.101.17]) by core3.amsl.com (Postfix) with SMTP id 7703F3A688F for ; Fri, 20 Feb 2009 12:09:04 -0800 (PST) Received: (qmail 94461 invoked by uid 60001); 20 Feb 2009 20:09:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1235160559; bh=Lya9VUW6maEWxiA/VmpBarNQK044zL/2visojV2ezwQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=dBh6X0t982oC1+MFWzg3I7XtmNoIKxm3icFrZZMcOJHP1trs00REX9g9yyB25lSfGydzPL84INzKym+LBnhHqCX60dOgNafpNxwpLVWQWJQ2SvfDCqxrutK38oN7nQyB0D5e3Qz12aTjw4ZqToWWrSMArGaIgp3C5ky24AM7Hz8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=0YFfr/NDCrtFl4MQtJITbhgtsrCqMGOCYbNwhabDo2TacHvnEF6LbxkLn7YsviSmeGjV8+J9+1tF6f/ouxxGROWli009wvw1z92dkLo70KxeniIz/lpEAo6be1kuDGdVNHAiJanOWYTgP5P2yM67lGTSqwYsZswuqVtWMSO14Cs=; Message-ID: <152190.94244.qm@web59106.mail.re1.yahoo.com> X-YMail-OSG: fUbQ.HwVM1liK_awx3bz4b1JJ7b9pzdx5JbOO60jVlcERFb0uHkzH5Mw1Tf3TGP_91K4Zkd5XnmTivSW4hB43Jf2lHFMAZL6VmCkqJL42i1IA3BqEqyqmeqW8.qYZ5GGMmxeeyyemIQ76FbUK1NKkddFf0467aa7px4FHrNAJgG7L4tAL1dlpqOkKWfraoZH5mq7l2zNs8rzUC3666v_rv3EmuGqAjdfwBOwp4tpn3pTaDU- Received: from [97.102.254.236] by web59106.mail.re1.yahoo.com via HTTP; Fri, 20 Feb 2009 12:09:18 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <20090220.134855.24682.1@webmail05.vgs.untd.com> <932783.65544.qm@web82608.mail.mud.yahoo.com> <499F091A.8010201@gmail.com> Date: Fri, 20 Feb 2009 12:09:18 -0800 (PST) From: Ann Otoole To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-116357129-1235160558=:94244" Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:09:05 -0000 --0-116357129-1235160558=:94244 Content-Type: text/plain; charset=us-ascii This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset. I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done. ________________________________ From: Jon Watte To: Charles Krinke Cc: mmox@ietf.org; "dyerbrookme@juno.com" Sent: Friday, February 20, 2009 2:48:42 PM Subject: Re: [mmox] Real Names Charles, I would support a "real names only" policy. I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration. Sincerely, jw Charles Krinke wrote: > Dear David and Meadhbh: > > I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms. > > It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with. > > Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage? > > Charles Krinke _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-116357129-1235160558=:94244 Content-Type: text/html; charset=us-ascii
This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset.

I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done.

From: Jon Watte <jwatte@gmail.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: mmox@ietf.org; "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Sent: Friday, February 20, 2009 2:48:42 PM
Subject: Re: [mmox] Real Names


Charles,

I would support a "real names only" policy.

I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration.

Sincerely,

jw


Charles Krinke wrote:
> Dear David and Meadhbh:
>
> I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms.
>
> It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with.
>
> Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage?
>
> Charles Krinke

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox

--0-116357129-1235160558=:94244-- From jwatte@gmail.com Fri Feb 20 12:09:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEB563A68AB for ; Fri, 20 Feb 2009 12:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wtIinONI+eD for ; Fri, 20 Feb 2009 12:09:06 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id A5A053A67BD for ; Fri, 20 Feb 2009 12:09:06 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so548782ana.4 for ; Fri, 20 Feb 2009 12:09:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DVtsOjD8bw4SXlEAeB/XdL+oE3g3bckELqXYoEL9mxg=; b=XIWL92RqSxrtshW0NQrIsgMMfpTG7uQ2VB0sG3VY+KuM+FdXmOr8mo+lqPPTEUL15j /zzC3p9Bva0qE9sVSXfEMUA4R1xn2EraJDjNxxpEe0U2pPWyE+zi5r/OVXPOIf7rQUBZ BkpFVJgSnSyK90BXhJw39C2vk5VTRqFnUQf7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=rXuckkVIU3rL6JAqv0iN8iMo7BqtfElicCsJpuXC0+DcTtJN7Xl00+18r7TOY4k3WN UmoKdtb2e9DXWsxXBCf53qstfjmePRLZYfAcxaQzlYnL76L0KVoQYu7+NwMGiMqxYgtw dcquk+7Gaplcif0N3oGYYX10HpLzUiXWYcMJs= Received: by 10.100.96.10 with SMTP id t10mr1849504anb.32.1235160561033; Fri, 20 Feb 2009 12:09:21 -0800 (PST) Received: from ?192.168.168.110? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c28sm6826575anc.45.2009.02.20.12.09.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 12:09:20 -0800 (PST) Message-ID: <499F0DEE.7090107@gmail.com> Date: Fri, 20 Feb 2009 12:09:18 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "dyerbrookme@juno.com" , "mmox@ietf.org" References: <20090220.134403.24682.0@webmail05.vgs.untd.com> In-Reply-To: <20090220.134403.24682.0@webmail05.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:09:07 -0000 dyerbrookme@juno.com wrote: > You're assuming that Linden Lab simply won't let pass through its gates an object that is not marked for transfer. But Linden Lab's entire world has been reverse-engineered in You seem to be having a beef with Linden Labs. It seems like you don't trust Linden Labs to actually enforce any policy that would be specified in an interoperability standard. Surely there are more appropriate forums for you to discuss these Second Life specific things with Linden Labs people. I think a rule of thumb for /this particular list/ should be that if the issue discussed is not applicable at least to eight different technology vendors (for example: Multiverse, Kaneva, Areae, Forterra, Linden Labs, Qwaq, Second Life and OpenSim), then it doesn't belong on this list. >> In fact, I am arguing that we should enable exactly what you're >> > describing! I don't understand how you belive I'm not. > > I think it's very simple: you have to clarify whether you are for putting copy/mod/transfer permissions on objects or not. > I believe I have clearly stated that it is my position that all content should contain metadata, and one piece of that metadata is copy/reuse/cache/storage rights. The specific forms of those copy/reuse/cache/storage may be c/m/t, or more likely something a little richer to cater for situations like copylefted content that has "sticky" semantics. Sincerely, jw From RGehorsam@forterrainc.com Fri Feb 20 12:14:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DF93A6835 for ; Fri, 20 Feb 2009 12:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-MrqmTqebrA for ; Fri, 20 Feb 2009 12:14:28 -0800 (PST) Received: from smtp.forterrainc.com (smtp.forterrainc.com [208.64.184.34]) by core3.amsl.com (Postfix) with ESMTP id 6DC803A6359 for ; Fri, 20 Feb 2009 12:14:23 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99397.FC0D4966" Date: Fri, 20 Feb 2009 12:15:33 -0800 Message-ID: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C7C@MERCURY.forterrainc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mmox] Real Names thread-index: AcmTl0BmwnuCPWZ8R7Kk2HDnymBHxwAAI3cZ From: "Robert Gehorsam" To: , Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:14:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99397.FC0D4966 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5uIC0NCg0KSSB0aGluayB0aGUgcG9pbnQgaXMgdGhhdCBoYXZpbmcgcmVhbCBuYW1lcyBhbmQg YXNzb2NpYXRpb25zIHdpdGggdGhvc2UgbmFtZXMgYXQgdGhlIHJpZ2h0IHBvaW50IGluIHRpbWUg aW4gYSBzdGFuZGFyZHMtZm9ybWluZyBwcm9jZXNzIGVuYWJsZXMgdHJ1c3QgYW5kIGFuIHVuZGVy c3RhbmRpbmcgb2YgZWFjaCBwYXJ0eSdzIGludGVyZXN0cy4gIEZyb20gdGhhdCBwZXJzcGVjdGl2 ZSwgZWFjaCBwYXJ0eSBjYW4gbWFrZSBhIGp1ZGdlbWVudCBhYm91dCB0aGUgc3RhdGVtZW50cyBv ZiBvdGhlcnMsICJnb29kIiAiYmFkIiAidXNlZnVsIiAidXNlbGVzcyIgLXdoYXRldmVyLi4gVGhp cyBub3QgYWJvdXQgImdyZWVkIiBvciBnZXR0aW5nIHJpZCBvZiBTTCBpbiBhbnkgd2F5LiAgQXUg Y29udHJhaXJlLCB0aGUgZGlzY3Vzc2lvbiBpcyBhYm91dCBncmVhdGVyIGluY2x1c2lvbiBpbiBp bnRlcm9wZXJhYmlsaXR5IGRlZmluaXRpb25zLg0KDQpSb2JlcnQNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IG1tb3gtYm91bmNlc0BpZXRmLm9yZyA8bW1veC1ib3VuY2VzQGll dGYub3JnPg0KVG86IG1tb3hAaWV0Zi5vcmcgPG1tb3hAaWV0Zi5vcmc+DQpTZW50OiBGcmkgRmVi IDIwIDEyOjA5OjE4IDIwMDkNClN1YmplY3Q6IFJlOiBbbW1veF0gUmVhbCBOYW1lcw0KDQpUaGlz IGlzIG5vdCBhYm91dCB5b3VyIG1lZXRpbmcgcm9vbXMgSm9uLiBZb3UgYXJlIGNsZWFybHkgdHJ5 aW5nIHRvIHNob3ZlIFNlY29uZCBMaWZlIG91dCBvZiB0aGUgd2F5IGFuZCB0aHVzIEZvcnRlcnJh IG5lZWRzIHRvIGJlIGV4Y2x1ZGVkIGZyb20gdGhlIG91dHNldC4NCg0KSSBtb3ZlIHdlIHJlbW92 ZSBjb3Jwb3JhdGlvbnMgZnJvbSB0aGUgcHJvY2VzcyB0aGF0IGhhdmUgYmxhdGFudGx5IGRlY2xh cmVkIGEgcHVyZSBncmVlZCBtb3RpdmF0aW9uIGFzIEpvbi9Gb3J0ZXJyYSBoYXMgYWxyZWFkeSBk b25lLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IEpvbiBX YXR0ZSA8andhdHRlQGdtYWlsLmNvbT4NClRvOiBDaGFybGVzIEtyaW5rZSA8Y2ZrQHBhY2JlbGwu bmV0Pg0KQ2M6IG1tb3hAaWV0Zi5vcmc7ICJkeWVyYnJvb2ttZUBqdW5vLmNvbSIgPGR5ZXJicm9v a21lQGp1bm8uY29tPg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyMCwgMjAwOSAyOjQ4OjQyIFBN DQpTdWJqZWN0OiBSZTogW21tb3hdIFJlYWwgTmFtZXMNCg0KDQpDaGFybGVzLA0KDQpJIHdvdWxk IHN1cHBvcnQgYSAicmVhbCBuYW1lcyBvbmx5IiBwb2xpY3kuDQoNCkkgdGhpbmsgdGhlIGJ1c2lu ZXNzbGlrZSBzdGFnZSB3aWxsIGhhcHBlbiBpZiBhIGRldGVybWluYXRpb24gb2Ygd2hvIGFjdHVh bGx5IGhhcyBhIGJ1c2luZXNzIGludGVyZXN0IGluIGludGVyb3BlcmFiaWxpdHkgaXMgbWFkZS4g SSBkb24ndCBrbm93IHdoYXQgdGhlIElFVEYgcnVsZSBvbiAib2JzZXJ2ZXJzIiBhcmUgLS0gcGFy dGllcyB3aG8gaGF2ZSBhbiBpbnRlcmVzdCwgYnV0IGRvbid0IGFjdHVhbGx5IGhhdmUgYSBidXNp bmVzcyBkaXJlY3RseSBpbnZvbHZlZCBpbiBpbXBsZW1lbnRpbmcgdGhlIHRlY2hub2xvZ3kgdW5k ZXIgY29uc2lkZXJhdGlvbi4NCg0KU2luY2VyZWx5LA0KDQpqdw0KDQoNCkNoYXJsZXMgS3Jpbmtl IHdyb3RlOg0KPiBEZWFyIERhdmlkIGFuZCBNZWFkaGJoOg0KPiANCj4gSSdtIGNvbmZ1c2VkIGFi b3V0IHNvbWUgb2YgdGhlIHBvc3RzIGZyb20gZW1haWwgYWRkcmVzc2VzIHRoYXQgYXJlIGVpdGhl ciB1bnNpZ25lZCBvciBmcm9tIHBzZXVkb255bXMuDQo+IA0KPiBJdCBzZWVtcyBlbnRpcmVseSBy ZWFzb25hYmxlIHRvIG1lIHRoYXQgcmVhbCBuYW1lcyBiZSB1c2VkIGluIHRoaXMgbWFpbGluZyBs aXN0IHRvIGF2b2lkIHdhc3RpbmcgYWxsIG91ciB0aW1lIGFuZCBzbyB0aGF0IHdlIGtub3cgd2hv IHdoZSBhcmUgc3BlYWtpbmcgd2l0aC4NCj4gDQo+IElzIHRoZXJlIHNvbWUgd2F5IGluIGFuIElF VEYgbWFpbGluZyBsaXN0IG9yIGJ5IHBlZXIgcHJlc3N1cmUgdG8gZ2V0IHRoaXMgdG8gYSBtb3Jl IGJ1c2luZXNzbGlrZSBzdGFnZT8NCj4gDQo+IENoYXJsZXMgS3JpbmtlDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptbW94IG1haWxpbmcgbGlzdA0K bW1veEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbW94 DQoNCg0K ------_=_NextPart_001_01C99397.FC0D4966 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTIuMjQiPg0KPFRJVExFPlJlOiBbbW1veF0g UmVhbCBOYW1lczwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwhLS0gQ29udmVydGVkIGZyb20g dGV4dC9wbGFpbiBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9Mj5Bbm4gLTxCUj4NCjxCUj4N CkkgdGhpbmsgdGhlIHBvaW50IGlzIHRoYXQgaGF2aW5nIHJlYWwgbmFtZXMgYW5kIGFzc29jaWF0 aW9ucyB3aXRoIHRob3NlIG5hbWVzIGF0IHRoZSByaWdodCBwb2ludCBpbiB0aW1lIGluIGEgc3Rh bmRhcmRzLWZvcm1pbmcgcHJvY2VzcyBlbmFibGVzIHRydXN0IGFuZCBhbiB1bmRlcnN0YW5kaW5n IG9mIGVhY2ggcGFydHkncyBpbnRlcmVzdHMuJm5ic3A7IEZyb20gdGhhdCBwZXJzcGVjdGl2ZSwg ZWFjaCBwYXJ0eSBjYW4gbWFrZSBhIGp1ZGdlbWVudCBhYm91dCB0aGUgc3RhdGVtZW50cyBvZiBv dGhlcnMsICZxdW90O2dvb2QmcXVvdDsgJnF1b3Q7YmFkJnF1b3Q7ICZxdW90O3VzZWZ1bCZxdW90 OyAmcXVvdDt1c2VsZXNzJnF1b3Q7IC13aGF0ZXZlci4uIFRoaXMgbm90IGFib3V0ICZxdW90O2dy ZWVkJnF1b3Q7IG9yIGdldHRpbmcgcmlkIG9mIFNMIGluIGFueSB3YXkuJm5ic3A7IEF1IGNvbnRy YWlyZSwgdGhlIGRpc2N1c3Npb24gaXMgYWJvdXQgZ3JlYXRlciBpbmNsdXNpb24gaW4gaW50ZXJv cGVyYWJpbGl0eSBkZWZpbml0aW9ucy48QlI+DQo8QlI+DQpSb2JlcnQ8QlI+DQo8QlI+DQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4NCkZyb206IG1tb3gtYm91bmNlc0BpZXRmLm9yZyAm bHQ7bW1veC1ib3VuY2VzQGlldGYub3JnJmd0OzxCUj4NClRvOiBtbW94QGlldGYub3JnICZsdDtt bW94QGlldGYub3JnJmd0OzxCUj4NClNlbnQ6IEZyaSBGZWIgMjAgMTI6MDk6MTggMjAwOTxCUj4N ClN1YmplY3Q6IFJlOiBbbW1veF0gUmVhbCBOYW1lczxCUj4NCjxCUj4NClRoaXMgaXMgbm90IGFi b3V0IHlvdXIgbWVldGluZyByb29tcyBKb24uIFlvdSBhcmUgY2xlYXJseSB0cnlpbmcgdG8gc2hv dmUgU2Vjb25kIExpZmUgb3V0IG9mIHRoZSB3YXkgYW5kIHRodXMgRm9ydGVycmEgbmVlZHMgdG8g YmUgZXhjbHVkZWQgZnJvbSB0aGUgb3V0c2V0LjxCUj4NCjxCUj4NCkkgbW92ZSB3ZSByZW1vdmUg Y29ycG9yYXRpb25zIGZyb20gdGhlIHByb2Nlc3MgdGhhdCBoYXZlIGJsYXRhbnRseSBkZWNsYXJl ZCBhIHB1cmUgZ3JlZWQgbW90aXZhdGlvbiBhcyBKb24vRm9ydGVycmEgaGFzIGFscmVhZHkgZG9u ZS48QlI+DQo8QlI+DQo8QlI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4N CjxCUj4NCkZyb206IEpvbiBXYXR0ZSAmbHQ7andhdHRlQGdtYWlsLmNvbSZndDs8QlI+DQpUbzog Q2hhcmxlcyBLcmlua2UgJmx0O2Nma0BwYWNiZWxsLm5ldCZndDs8QlI+DQpDYzogbW1veEBpZXRm Lm9yZzsgJnF1b3Q7ZHllcmJyb29rbWVAanVuby5jb20mcXVvdDsgJmx0O2R5ZXJicm9va21lQGp1 bm8uY29tJmd0OzxCUj4NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjAsIDIwMDkgMjo0ODo0MiBQ TTxCUj4NClN1YmplY3Q6IFJlOiBbbW1veF0gUmVhbCBOYW1lczxCUj4NCjxCUj4NCjxCUj4NCkNo YXJsZXMsPEJSPg0KPEJSPg0KSSB3b3VsZCBzdXBwb3J0IGEgJnF1b3Q7cmVhbCBuYW1lcyBvbmx5 JnF1b3Q7IHBvbGljeS48QlI+DQo8QlI+DQpJIHRoaW5rIHRoZSBidXNpbmVzc2xpa2Ugc3RhZ2Ug d2lsbCBoYXBwZW4gaWYgYSBkZXRlcm1pbmF0aW9uIG9mIHdobyBhY3R1YWxseSBoYXMgYSBidXNp bmVzcyBpbnRlcmVzdCBpbiBpbnRlcm9wZXJhYmlsaXR5IGlzIG1hZGUuIEkgZG9uJ3Qga25vdyB3 aGF0IHRoZSBJRVRGIHJ1bGUgb24gJnF1b3Q7b2JzZXJ2ZXJzJnF1b3Q7IGFyZSAtLSBwYXJ0aWVz IHdobyBoYXZlIGFuIGludGVyZXN0LCBidXQgZG9uJ3QgYWN0dWFsbHkgaGF2ZSBhIGJ1c2luZXNz IGRpcmVjdGx5IGludm9sdmVkIGluIGltcGxlbWVudGluZyB0aGUgdGVjaG5vbG9neSB1bmRlciBj b25zaWRlcmF0aW9uLjxCUj4NCjxCUj4NClNpbmNlcmVseSw8QlI+DQo8QlI+DQpqdzxCUj4NCjxC Uj4NCjxCUj4NCkNoYXJsZXMgS3JpbmtlIHdyb3RlOjxCUj4NCiZndDsgRGVhciBEYXZpZCBhbmQg TWVhZGhiaDo8QlI+DQomZ3Q7PEJSPg0KJmd0OyBJJ20gY29uZnVzZWQgYWJvdXQgc29tZSBvZiB0 aGUgcG9zdHMgZnJvbSBlbWFpbCBhZGRyZXNzZXMgdGhhdCBhcmUgZWl0aGVyIHVuc2lnbmVkIG9y IGZyb20gcHNldWRvbnltcy48QlI+DQomZ3Q7PEJSPg0KJmd0OyBJdCBzZWVtcyBlbnRpcmVseSBy ZWFzb25hYmxlIHRvIG1lIHRoYXQgcmVhbCBuYW1lcyBiZSB1c2VkIGluIHRoaXMgbWFpbGluZyBs aXN0IHRvIGF2b2lkIHdhc3RpbmcgYWxsIG91ciB0aW1lIGFuZCBzbyB0aGF0IHdlIGtub3cgd2hv IHdoZSBhcmUgc3BlYWtpbmcgd2l0aC48QlI+DQomZ3Q7PEJSPg0KJmd0OyBJcyB0aGVyZSBzb21l IHdheSBpbiBhbiBJRVRGIG1haWxpbmcgbGlzdCBvciBieSBwZWVyIHByZXNzdXJlIHRvIGdldCB0 aGlzIHRvIGEgbW9yZSBidXNpbmVzc2xpa2Ugc3RhZ2U/PEJSPg0KJmd0OzxCUj4NCiZndDsgQ2hh cmxlcyBLcmlua2U8QlI+DQo8QlI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxCUj4NCm1tb3ggbWFpbGluZyBsaXN0PEJSPg0KbW1veEBpZXRmLm9yZzxC Uj4NCjxBIEhSRUY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW1veCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbW94PC9BPjxCUj4NCjxCUj4N CjxCUj4NCjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C99397.FC0D4966-- From jwatte@gmail.com Fri Feb 20 12:21:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D377F3A695F for ; Fri, 20 Feb 2009 12:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBubMsOkbbyR for ; Fri, 20 Feb 2009 12:21:31 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id B316F3A6959 for ; Fri, 20 Feb 2009 12:21:31 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so881958yxm.49 for ; Fri, 20 Feb 2009 12:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=PqclhO2DQQe9VOyTArZvO/EAH8srA7S8H5ms+d4dP0s=; b=HhdNNCwgFV+946Ij/PDsndA5xNAYELhEa6Rerl2At503lpEVvFMgchLEig0g8qADex a83iaDE/2bPFEP69XmAw5bsqxQLtH1HEClxp6+lNeYsiccrGJcz5PvVOvdJuj5O5/0uW 9p1ebbUWbojVfwmB66ep+EmzbdSxIscQuuZMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BufDl2R+aX4Cjm+QpEczrpnXIDvwGewCIckazqqlbqQ7WRC8qwAjeBAbrTidQ1rXGh l1/WQrDo3/p2neBI8ukk2zy9UiG/i0ijoFTNsRbcGidzgEWMFqeITHbj7S8hetVQt9AF frLpJildgAZxGmaQTqpBQYlaMuaDVOnY6s4uU= Received: by 10.101.1.16 with SMTP id d16mr1777345ani.153.1235161305849; Fri, 20 Feb 2009 12:21:45 -0800 (PST) Received: from ?192.168.168.110? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c9sm5091737ana.33.2009.02.20.12.21.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 12:21:45 -0800 (PST) Message-ID: <499F10D7.5080605@gmail.com> Date: Fri, 20 Feb 2009 12:21:43 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com><80E946E9-5C62-4E00-BE8C-A15513898F99@lindenla b.com><62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com><29656.28734.qm@web82607.mail.mud.yahoo.com><61320.78349.qm@web82607.mail.mud.yahoo.com><962799.66993.qm@web82608.mail.mud.yahoo.com> <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> <88DFFC67-0B59-4D65-86FB-8776899B794A@lindenlab.com> In-Reply-To: <88DFFC67-0B59-4D65-86FB-8776899B794A@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: [mmox] LLSD and content schema X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:21:32 -0000 Meadhbh Hamrick (Infinity) wrote: > * LLSD is implementable by mortals in a tractable amount of time and > without the use of complicated third-party tools (ASN.1 compilers, etc.) I don't see the LLSD interface compiler as any different in conceptual complexity than an ASN.1 compiler. I did bring up the question of ASN.1 before, and was told by you that you felt it was "too buggy," which I think is not fair or accurate. However, I believe ASN.1 and also LLSD have a problem that I'd like to see addressed in a standard: they use implicit schema. If I want to send a piece of data from point A to point B, and the points don't both exactly know what the data is, that's fine -- but, in that case, you typically want to use something a little more open-ended and more generally standardized, like XML. The benefit of XML is that there are tons of tools that already support it (as there are with ASN.1, btw); XML also allows well-formed documents to be verified using XSD schema. If you need large binary blob support (textures, etc), those can be included by reference uri. I think XML is appropriate for those cases, and LLSD doesn't quite fit the bill in that case. If I want to send a piece of data from point A to point B, and point A and point B know exactly what this data will be, then data type information does not need to be sent as part of the serialization. In fact, including data type information is redundant and consumes network bandwidth unnecessarily. Thus, I would assume that any communication where size matters (such as for entity property update streams) will be done using negotiated (bilaterally understood) schema, with the following properties: 1) Only data elements, not names or types, are sent. 2) Specfic properties are addressed using short Ids that are translated in schema. 3) If certain properties are always sent together (say, position x y z and orientation x y z w) then schema allows for an "aggregate property" to be declared, such that only a single name (Id) is needed to identify that entire tuple. I have written an illustrative proposal up for this that may help clarify the issue, at the following URLs: http://www.interopworld.com/node/29 http://www.interopworld.com/node/28 Sincerely, jw From cfk@pacbell.net Fri Feb 20 12:26:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038133A66B4 for ; Fri, 20 Feb 2009 12:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao6MvWfdDMvP for ; Fri, 20 Feb 2009 12:26:25 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id D13463A690E for ; Fri, 20 Feb 2009 12:26:24 -0800 (PST) Received: (qmail 25205 invoked by uid 60001); 20 Feb 2009 20:26:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=xyb7PeCkkeGuYksWpavJguf4o9O6enl4rI929KTxuVF9ehW4Fh0xxFNJJWP3HVCHqs6g8Uw4iiUfvi9H2OUm5qxjUdBWzWGLrJNRNCd3uz5w+JRu5Yah8Yfn3AclcJW03eenHIKEh7aQph3sp50YrUZ1RxHBF+grE9wwXhNOFo4=; X-YMail-OSG: vc8xx0MVM1keYsYtRYp3Isf3gFiyOINbeX4kG5lc4S5a_LXBwq8BMlG.sXexEpeROFzFySOFUc8Bh2Q_ZQ__MuZ0hH6CA5XnBadDTWru.zNA.vTOYt8VqQ5C6M5kJOZK.o.Wl0dnwPQ3ENXTXk_9lrV.2xL4Kb9IRKO40wRnHQVEr8WxFsobyKvgVk2JnnWs8kysQXYhkmo8qcjRmATEeTLfXKmQJJBxO4Ts Received: from [76.222.233.250] by web82602.mail.mud.yahoo.com via HTTP; Fri, 20 Feb 2009 12:26:38 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C7C@MERCURY.forterrainc.com> Date: Fri, 20 Feb 2009 12:26:38 -0800 (PST) From: Charles Krinke To: Robert Gehorsam , missannotoole@yahoo.com, mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1944969410-1235161598=:24514" Message-ID: <945772.24514.qm@web82602.mail.mud.yahoo.com> Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:26:26 -0000 --0-1944969410-1235161598=:24514 Content-Type: text/plain; charset=us-ascii My motivation in bringing this up in the first place was to at least have a clue to whom I am speaking. In saying "business-like", I mean a "polite, fruitful interchange of useful information", which has nothing to do with whether companyX has more (or less) customers, plans, aspirations, bathrooms or virtual regions then another. Charles ________________________________ From: Robert Gehorsam To: missannotoole@yahoo.com; mmox@ietf.org Sent: Friday, February 20, 2009 12:15:33 PM Subject: Re: [mmox] Real Names Re: [mmox] Real Names Ann - I think the point is that having real names and associations with those names at the right point in time in a standards-forming process enables trust and an understanding of each party's interests. From that perspective, each party can make a judgement about the statements of others, "good" "bad" "useful" "useless" -whatever.. This not about "greed" or getting rid of SL in any way. Au contraire, the discussion is about greater inclusion in interoperability definitions. Robert -----Original Message----- From: mmox-bounces@ietf.org To: mmox@ietf.org Sent: Fri Feb 20 12:09:18 2009 Subject: Re: [mmox] Real Names This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset. I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done. ________________________________ From: Jon Watte To: Charles Krinke Cc: mmox@ietf.org; "dyerbrookme@juno.com" Sent: Friday, February 20, 2009 2:48:42 PM Subject: Re: [mmox] Real Names Charles, I would support a "real names only" policy. I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration. Sincerely, jw Charles Krinke wrote: > Dear David and Meadhbh: > > I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms. > > It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with. > > Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage? > > Charles Krinke _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-1944969410-1235161598=:24514 Content-Type: text/html; charset=us-ascii
My motivation in bringing this up in the first place was to at least have a clue to whom I am speaking.

In saying "business-like", I mean a "polite, fruitful interchange of useful information", which has nothing to do with whether companyX has more (or less) customers, plans, aspirations, bathrooms or virtual regions then another.

Charles

From: Robert Gehorsam <RGehorsam@forterrainc.com>
To: missannotoole@yahoo.com; mmox@ietf.org
Sent: Friday, February 20, 2009 12:15:33 PM
Subject: Re: [mmox] Real Names

Re: [mmox] Real Names

Ann -

I think the point is that having real names and associations with those names at the right point in time in a standards-forming process enables trust and an understanding of each party's interests.  From that perspective, each party can make a judgement about the statements of others, "good" "bad" "useful" "useless" -whatever.. This not about "greed" or getting rid of SL in any way.  Au contraire, the discussion is about greater inclusion in interoperability definitions.

Robert

-----Original Message-----
From: mmox-bounces@ietf.org <mmox-bounces@ietf.org>
To: mmox@ietf.org <mmox@ietf.org>
Sent: Fri Feb 20 12:09:18 2009
Subject: Re: [mmox] Real Names

This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset.

I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done.


________________________________

From: Jon Watte <jwatte@gmail.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: mmox@ietf.org; "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Sent: Friday, February 20, 2009 2:48:42 PM
Subject: Re: [mmox] Real Names


Charles,

I would support a "real names only" policy.

I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration.

Sincerely,

jw


Charles Krinke wrote:
> Dear David and Meadhbh:
>
> I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms.
>
> It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with.
>
> Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage?
>
> Charles Krinke

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox

--0-1944969410-1235161598=:24514-- From RGehorsam@forterrainc.com Fri Feb 20 12:44:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D2923A66B4 for ; Fri, 20 Feb 2009 12:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kq585LIiFmUy for ; Fri, 20 Feb 2009 12:44:58 -0800 (PST) Received: from smtp.forterrainc.com (smtp.forterrainc.com [208.64.184.34]) by core3.amsl.com (Postfix) with ESMTP id 32E7A3A63EC for ; Fri, 20 Feb 2009 12:44:58 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9939C.4239BD12" Date: Fri, 20 Feb 2009 12:46:07 -0800 Message-ID: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C7E@MERCURY.forterrainc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mmox] Real Names thread-index: AcmTmaq0A2pXtOHpQ++vhJLp9/hXfwAAmeS3 From: "Robert Gehorsam" To: , , Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:44:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9939C.4239BD12 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tcGxldGVseSBhZ3JlZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IENo YXJsZXMgS3JpbmtlIDxjZmtAcGFjYmVsbC5uZXQ+DQpUbzogUm9iZXJ0IEdlaG9yc2FtOyBtaXNz YW5ub3Rvb2xlQHlhaG9vLmNvbSA8bWlzc2Fubm90b29sZUB5YWhvby5jb20+OyBtbW94QGlldGYu b3JnIDxtbW94QGlldGYub3JnPg0KU2VudDogRnJpIEZlYiAyMCAxMjoyNjozOCAyMDA5DQpTdWJq ZWN0OiBSZTogW21tb3hdIFJlYWwgTmFtZXMNCg0KTXkgbW90aXZhdGlvbiBpbiBicmluZ2luZyB0 aGlzIHVwIGluIHRoZSBmaXJzdCBwbGFjZSB3YXMgdG8gYXQgbGVhc3QgaGF2ZSBhIGNsdWUgdG8g d2hvbSBJIGFtIHNwZWFraW5nLg0KDQpJbiBzYXlpbmcgImJ1c2luZXNzLWxpa2UiLCBJIG1lYW4g YSAicG9saXRlLCBmcnVpdGZ1bCBpbnRlcmNoYW5nZSBvZiB1c2VmdWwgaW5mb3JtYXRpb24iLCB3 aGljaCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHdoZXRoZXIgY29tcGFueVggaGFzIG1vcmUgKG9y IGxlc3MpIGN1c3RvbWVycywgcGxhbnMsIGFzcGlyYXRpb25zLCBiYXRocm9vbXMgb3IgdmlydHVh bCByZWdpb25zIHRoZW4gYW5vdGhlci4NCg0KQ2hhcmxlcw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkZyb206IFJvYmVydCBHZWhvcnNhbSA8UkdlaG9yc2FtQGZvcnRl cnJhaW5jLmNvbT4NClRvOiBtaXNzYW5ub3Rvb2xlQHlhaG9vLmNvbTsgbW1veEBpZXRmLm9yZw0K U2VudDogRnJpZGF5LCBGZWJydWFyeSAyMCwgMjAwOSAxMjoxNTozMyBQTQ0KU3ViamVjdDogUmU6 IFttbW94XSBSZWFsIE5hbWVzDQoNCg0KDQpBbm4gLQ0KDQpJIHRoaW5rIHRoZSBwb2ludCBpcyB0 aGF0IGhhdmluZyByZWFsIG5hbWVzIGFuZCBhc3NvY2lhdGlvbnMgd2l0aCB0aG9zZSBuYW1lcyBh dCB0aGUgcmlnaHQgcG9pbnQgaW4gdGltZSBpbiBhIHN0YW5kYXJkcy1mb3JtaW5nIHByb2Nlc3Mg ZW5hYmxlcyB0cnVzdCBhbmQgYW4gdW5kZXJzdGFuZGluZyBvZiBlYWNoIHBhcnR5J3MgaW50ZXJl c3RzLiAgRnJvbSB0aGF0IHBlcnNwZWN0aXZlLCBlYWNoIHBhcnR5IGNhbiBtYWtlIGEganVkZ2Vt ZW50IGFib3V0IHRoZSBzdGF0ZW1lbnRzIG9mIG90aGVycywgImdvb2QiICJiYWQiICJ1c2VmdWwi ICJ1c2VsZXNzIiAtd2hhdGV2ZXIuLiBUaGlzIG5vdCBhYm91dCAiZ3JlZWQiIG9yIGdldHRpbmcg cmlkIG9mIFNMIGluIGFueSB3YXkuICBBdSBjb250cmFpcmUsIHRoZSBkaXNjdXNzaW9uIGlzIGFi b3V0IGdyZWF0ZXIgaW5jbHVzaW9uIGluIGludGVyb3BlcmFiaWxpdHkgZGVmaW5pdGlvbnMuDQoN ClJvYmVydA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbW1veC1ib3VuY2Vz QGlldGYub3JnIDxtbW94LWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogbW1veEBpZXRmLm9yZyA8bW1v eEBpZXRmLm9yZz4NClNlbnQ6IEZyaSBGZWIgMjAgMTI6MDk6MTggMjAwOQ0KU3ViamVjdDogUmU6 IFttbW94XSBSZWFsIE5hbWVzDQoNClRoaXMgaXMgbm90IGFib3V0IHlvdXIgbWVldGluZyByb29t cyBKb24uIFlvdSBhcmUgY2xlYXJseSB0cnlpbmcgdG8gc2hvdmUgU2Vjb25kIExpZmUgb3V0IG9m IHRoZSB3YXkgYW5kIHRodXMgRm9ydGVycmEgbmVlZHMgdG8gYmUgZXhjbHVkZWQgZnJvbSB0aGUg b3V0c2V0Lg0KDQpJIG1vdmUgd2UgcmVtb3ZlIGNvcnBvcmF0aW9ucyBmcm9tIHRoZSBwcm9jZXNz IHRoYXQgaGF2ZSBibGF0YW50bHkgZGVjbGFyZWQgYSBwdXJlIGdyZWVkIG1vdGl2YXRpb24gYXMg Sm9uL0ZvcnRlcnJhIGhhcyBhbHJlYWR5IGRvbmUuDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KRnJvbTogSm9uIFdhdHRlIDxqd2F0dGVAZ21haWwuY29tPg0KVG86IENo YXJsZXMgS3JpbmtlIDxjZmtAcGFjYmVsbC5uZXQ+DQpDYzogbW1veEBpZXRmLm9yZzsgImR5ZXJi cm9va21lQGp1bm8uY29tIiA8ZHllcmJyb29rbWVAanVuby5jb20+DQpTZW50OiBGcmlkYXksIEZl YnJ1YXJ5IDIwLCAyMDA5IDI6NDg6NDIgUE0NClN1YmplY3Q6IFJlOiBbbW1veF0gUmVhbCBOYW1l cw0KDQoNCkNoYXJsZXMsDQoNCkkgd291bGQgc3VwcG9ydCBhICJyZWFsIG5hbWVzIG9ubHkiIHBv bGljeS4NCg0KSSB0aGluayB0aGUgYnVzaW5lc3NsaWtlIHN0YWdlIHdpbGwgaGFwcGVuIGlmIGEg ZGV0ZXJtaW5hdGlvbiBvZiB3aG8gYWN0dWFsbHkgaGFzIGEgYnVzaW5lc3MgaW50ZXJlc3QgaW4g aW50ZXJvcGVyYWJpbGl0eSBpcyBtYWRlLiBJIGRvbid0IGtub3cgd2hhdCB0aGUgSUVURiBydWxl IG9uICJvYnNlcnZlcnMiIGFyZSAtLSBwYXJ0aWVzIHdobyBoYXZlIGFuIGludGVyZXN0LCBidXQg ZG9uJ3QgYWN0dWFsbHkgaGF2ZSBhIGJ1c2luZXNzIGRpcmVjdGx5IGludm9sdmVkIGluIGltcGxl bWVudGluZyB0aGUgdGVjaG5vbG9neSB1bmRlciBjb25zaWRlcmF0aW9uLg0KDQpTaW5jZXJlbHks DQoNCmp3DQoNCg0KQ2hhcmxlcyBLcmlua2Ugd3JvdGU6DQo+IERlYXIgRGF2aWQgYW5kIE1lYWRo Ymg6DQo+DQo+IEknbSBjb25mdXNlZCBhYm91dCBzb21lIG9mIHRoZSBwb3N0cyBmcm9tIGVtYWls IGFkZHJlc3NlcyB0aGF0IGFyZSBlaXRoZXIgdW5zaWduZWQgb3IgZnJvbSBwc2V1ZG9ueW1zLg0K Pg0KPiBJdCBzZWVtcyBlbnRpcmVseSByZWFzb25hYmxlIHRvIG1lIHRoYXQgcmVhbCBuYW1lcyBi ZSB1c2VkIGluIHRoaXMgbWFpbGluZyBsaXN0IHRvIGF2b2lkIHdhc3RpbmcgYWxsIG91ciB0aW1l IGFuZCBzbyB0aGF0IHdlIGtub3cgd2hvIHdoZSBhcmUgc3BlYWtpbmcgd2l0aC4NCj4NCj4gSXMg dGhlcmUgc29tZSB3YXkgaW4gYW4gSUVURiBtYWlsaW5nIGxpc3Qgb3IgYnkgcGVlciBwcmVzc3Vy ZSB0byBnZXQgdGhpcyB0byBhIG1vcmUgYnVzaW5lc3NsaWtlIHN0YWdlPw0KPg0KPiBDaGFybGVz IEtyaW5rZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbW1veCBtYWlsaW5nIGxpc3QNCm1tb3hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbW1veA0KDQoNCg0KDQo= ------_=_NextPart_001_01C9939C.4239BD12 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTIuMjQiPg0KPFRJVExFPlJlOiBbbW1veF0g UmVhbCBOYW1lczwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwhLS0gQ29udmVydGVkIGZyb20g dGV4dC9wbGFpbiBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9Mj5Db21wbGV0ZWx5IGFncmVl LjxCUj4NCjxCUj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPg0KRnJvbTogQ2hhcmxl cyBLcmlua2UgJmx0O2Nma0BwYWNiZWxsLm5ldCZndDs8QlI+DQpUbzogUm9iZXJ0IEdlaG9yc2Ft OyBtaXNzYW5ub3Rvb2xlQHlhaG9vLmNvbSAmbHQ7bWlzc2Fubm90b29sZUB5YWhvby5jb20mZ3Q7 OyBtbW94QGlldGYub3JnICZsdDttbW94QGlldGYub3JnJmd0OzxCUj4NClNlbnQ6IEZyaSBGZWIg MjAgMTI6MjY6MzggMjAwOTxCUj4NClN1YmplY3Q6IFJlOiBbbW1veF0gUmVhbCBOYW1lczxCUj4N CjxCUj4NCk15IG1vdGl2YXRpb24gaW4gYnJpbmdpbmcgdGhpcyB1cCBpbiB0aGUgZmlyc3QgcGxh Y2Ugd2FzIHRvIGF0IGxlYXN0IGhhdmUgYSBjbHVlIHRvIHdob20gSSBhbSBzcGVha2luZy48QlI+ DQo8QlI+DQpJbiBzYXlpbmcgJnF1b3Q7YnVzaW5lc3MtbGlrZSZxdW90OywgSSBtZWFuIGEgJnF1 b3Q7cG9saXRlLCBmcnVpdGZ1bCBpbnRlcmNoYW5nZSBvZiB1c2VmdWwgaW5mb3JtYXRpb24mcXVv dDssIHdoaWNoIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggd2hldGhlciBjb21wYW55WCBoYXMgbW9y ZSAob3IgbGVzcykgY3VzdG9tZXJzLCBwbGFucywgYXNwaXJhdGlvbnMsIGJhdGhyb29tcyBvciB2 aXJ0dWFsIHJlZ2lvbnMgdGhlbiBhbm90aGVyLjxCUj4NCjxCUj4NCkNoYXJsZXM8QlI+DQo8QlI+ DQo8QlI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4NCjxCUj4NCkZyb206 IFJvYmVydCBHZWhvcnNhbSAmbHQ7UkdlaG9yc2FtQGZvcnRlcnJhaW5jLmNvbSZndDs8QlI+DQpU bzogbWlzc2Fubm90b29sZUB5YWhvby5jb207IG1tb3hAaWV0Zi5vcmc8QlI+DQpTZW50OiBGcmlk YXksIEZlYnJ1YXJ5IDIwLCAyMDA5IDEyOjE1OjMzIFBNPEJSPg0KU3ViamVjdDogUmU6IFttbW94 XSBSZWFsIE5hbWVzPEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KQW5uIC08QlI+DQo8QlI+DQpJIHRo aW5rIHRoZSBwb2ludCBpcyB0aGF0IGhhdmluZyByZWFsIG5hbWVzIGFuZCBhc3NvY2lhdGlvbnMg d2l0aCB0aG9zZSBuYW1lcyBhdCB0aGUgcmlnaHQgcG9pbnQgaW4gdGltZSBpbiBhIHN0YW5kYXJk cy1mb3JtaW5nIHByb2Nlc3MgZW5hYmxlcyB0cnVzdCBhbmQgYW4gdW5kZXJzdGFuZGluZyBvZiBl YWNoIHBhcnR5J3MgaW50ZXJlc3RzLiZuYnNwOyBGcm9tIHRoYXQgcGVyc3BlY3RpdmUsIGVhY2gg cGFydHkgY2FuIG1ha2UgYSBqdWRnZW1lbnQgYWJvdXQgdGhlIHN0YXRlbWVudHMgb2Ygb3RoZXJz LCAmcXVvdDtnb29kJnF1b3Q7ICZxdW90O2JhZCZxdW90OyAmcXVvdDt1c2VmdWwmcXVvdDsgJnF1 b3Q7dXNlbGVzcyZxdW90OyAtd2hhdGV2ZXIuLiBUaGlzIG5vdCBhYm91dCAmcXVvdDtncmVlZCZx dW90OyBvciBnZXR0aW5nIHJpZCBvZiBTTCBpbiBhbnkgd2F5LiZuYnNwOyBBdSBjb250cmFpcmUs IHRoZSBkaXNjdXNzaW9uIGlzIGFib3V0IGdyZWF0ZXIgaW5jbHVzaW9uIGluIGludGVyb3BlcmFi aWxpdHkgZGVmaW5pdGlvbnMuPEJSPg0KPEJSPg0KUm9iZXJ0PEJSPg0KPEJSPg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08QlI+DQpGcm9tOiBtbW94LWJvdW5jZXNAaWV0Zi5vcmcgJmx0O21t b3gtYm91bmNlc0BpZXRmLm9yZyZndDs8QlI+DQpUbzogbW1veEBpZXRmLm9yZyAmbHQ7bW1veEBp ZXRmLm9yZyZndDs8QlI+DQpTZW50OiBGcmkgRmViIDIwIDEyOjA5OjE4IDIwMDk8QlI+DQpTdWJq ZWN0OiBSZTogW21tb3hdIFJlYWwgTmFtZXM8QlI+DQo8QlI+DQpUaGlzIGlzIG5vdCBhYm91dCB5 b3VyIG1lZXRpbmcgcm9vbXMgSm9uLiBZb3UgYXJlIGNsZWFybHkgdHJ5aW5nIHRvIHNob3ZlIFNl Y29uZCBMaWZlIG91dCBvZiB0aGUgd2F5IGFuZCB0aHVzIEZvcnRlcnJhIG5lZWRzIHRvIGJlIGV4 Y2x1ZGVkIGZyb20gdGhlIG91dHNldC48QlI+DQo8QlI+DQpJIG1vdmUgd2UgcmVtb3ZlIGNvcnBv cmF0aW9ucyBmcm9tIHRoZSBwcm9jZXNzIHRoYXQgaGF2ZSBibGF0YW50bHkgZGVjbGFyZWQgYSBw dXJlIGdyZWVkIG1vdGl2YXRpb24gYXMgSm9uL0ZvcnRlcnJhIGhhcyBhbHJlYWR5IGRvbmUuPEJS Pg0KPEJSPg0KPEJSPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+DQo8QlI+ DQpGcm9tOiBKb24gV2F0dGUgJmx0O2p3YXR0ZUBnbWFpbC5jb20mZ3Q7PEJSPg0KVG86IENoYXJs ZXMgS3JpbmtlICZsdDtjZmtAcGFjYmVsbC5uZXQmZ3Q7PEJSPg0KQ2M6IG1tb3hAaWV0Zi5vcmc7 ICZxdW90O2R5ZXJicm9va21lQGp1bm8uY29tJnF1b3Q7ICZsdDtkeWVyYnJvb2ttZUBqdW5vLmNv bSZndDs8QlI+DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDIwLCAyMDA5IDI6NDg6NDIgUE08QlI+ DQpTdWJqZWN0OiBSZTogW21tb3hdIFJlYWwgTmFtZXM8QlI+DQo8QlI+DQo8QlI+DQpDaGFybGVz LDxCUj4NCjxCUj4NCkkgd291bGQgc3VwcG9ydCBhICZxdW90O3JlYWwgbmFtZXMgb25seSZxdW90 OyBwb2xpY3kuPEJSPg0KPEJSPg0KSSB0aGluayB0aGUgYnVzaW5lc3NsaWtlIHN0YWdlIHdpbGwg aGFwcGVuIGlmIGEgZGV0ZXJtaW5hdGlvbiBvZiB3aG8gYWN0dWFsbHkgaGFzIGEgYnVzaW5lc3Mg aW50ZXJlc3QgaW4gaW50ZXJvcGVyYWJpbGl0eSBpcyBtYWRlLiBJIGRvbid0IGtub3cgd2hhdCB0 aGUgSUVURiBydWxlIG9uICZxdW90O29ic2VydmVycyZxdW90OyBhcmUgLS0gcGFydGllcyB3aG8g aGF2ZSBhbiBpbnRlcmVzdCwgYnV0IGRvbid0IGFjdHVhbGx5IGhhdmUgYSBidXNpbmVzcyBkaXJl Y3RseSBpbnZvbHZlZCBpbiBpbXBsZW1lbnRpbmcgdGhlIHRlY2hub2xvZ3kgdW5kZXIgY29uc2lk ZXJhdGlvbi48QlI+DQo8QlI+DQpTaW5jZXJlbHksPEJSPg0KPEJSPg0Kanc8QlI+DQo8QlI+DQo8 QlI+DQpDaGFybGVzIEtyaW5rZSB3cm90ZTo8QlI+DQomZ3Q7IERlYXIgRGF2aWQgYW5kIE1lYWRo Ymg6PEJSPg0KJmd0OzxCUj4NCiZndDsgSSdtIGNvbmZ1c2VkIGFib3V0IHNvbWUgb2YgdGhlIHBv c3RzIGZyb20gZW1haWwgYWRkcmVzc2VzIHRoYXQgYXJlIGVpdGhlciB1bnNpZ25lZCBvciBmcm9t IHBzZXVkb255bXMuPEJSPg0KJmd0OzxCUj4NCiZndDsgSXQgc2VlbXMgZW50aXJlbHkgcmVhc29u YWJsZSB0byBtZSB0aGF0IHJlYWwgbmFtZXMgYmUgdXNlZCBpbiB0aGlzIG1haWxpbmcgbGlzdCB0 byBhdm9pZCB3YXN0aW5nIGFsbCBvdXIgdGltZSBhbmQgc28gdGhhdCB3ZSBrbm93IHdobyB3aGUg YXJlIHNwZWFraW5nIHdpdGguPEJSPg0KJmd0OzxCUj4NCiZndDsgSXMgdGhlcmUgc29tZSB3YXkg aW4gYW4gSUVURiBtYWlsaW5nIGxpc3Qgb3IgYnkgcGVlciBwcmVzc3VyZSB0byBnZXQgdGhpcyB0 byBhIG1vcmUgYnVzaW5lc3NsaWtlIHN0YWdlPzxCUj4NCiZndDs8QlI+DQomZ3Q7IENoYXJsZXMg S3JpbmtlPEJSPg0KPEJSPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188QlI+DQptbW94IG1haWxpbmcgbGlzdDxCUj4NCm1tb3hAaWV0Zi5vcmc8QlI+DQo8 QSBIUkVGPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tb3giPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW1veDwvQT48QlI+DQo8QlI+DQo8QlI+ DQo8QlI+DQo8QlI+DQo8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= ------_=_NextPart_001_01C9939C.4239BD12-- From missannotoole@yahoo.com Fri Feb 20 13:00:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DCEF28C0E6 for ; Fri, 20 Feb 2009 13:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgkfIv9s5am3 for ; Fri, 20 Feb 2009 13:00:56 -0800 (PST) Received: from web59105.mail.re1.yahoo.com (web59105.mail.re1.yahoo.com [66.196.101.16]) by core3.amsl.com (Postfix) with SMTP id E649E3A69E9 for ; Fri, 20 Feb 2009 13:00:55 -0800 (PST) Received: (qmail 76038 invoked by uid 60001); 20 Feb 2009 21:01:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1235163669; bh=vVyxA5WYZ4GJ1QzsKOidT3fuHH0k2s84Q9xlTD2aO9E=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=JijK0pfhURRxlEiyx7qw/Cm+7cG77kcNQYnC4OR+GuRna1uBQrrMLredl1ZmXGwZa8OvmtJcUKGNm9+2YdPfBDeRUCnsiFhT2psCjk7nWd4thTI+5Gq7GPXUahHrugW5Jvfkimv5JPG9wg/Qr9XV0pvGBIJe0RDXObdEQ97zSFw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=Sf/Q0QS70RKCohinLFoi/vLttqnE/NkgrgkJjCdFDNQ56wFctF5FTtnrcT/NcaL9brGt1OStBTAQzjMuXxCT9wKC3+5dh5t3HNyu1tpzlS+AT197ZbnOkcDkSsO+2/+HuXx+4kLSS149xlagNItE4p7wtAwLecEZXiCRvxllQ3s=; Message-ID: <898815.75906.qm@web59105.mail.re1.yahoo.com> X-YMail-OSG: .Cz0838VM1ntHKWgYtD4zC2e3pWGQmNFkCcGtbj4yw3ROqNpmVAMGtirbKLN7.FShIXu6jrpiHq7y0dvKBIPqJL68HyBkgo7xarGHLRzfrXrVJ73DSTwnm77k.ViujKuMsdkfNopaV7jv9_3qp2ivRUT.x9oEWMTkB9DrXqWvKQhJjEmLUjrZkhYUHMwTAdt6RDVwQ8HYZtKaC_Tb_6gJGGOSqMZduhDBtRgyYYG9g1GC95oAoqqI0I4 Received: from [97.102.254.236] by web59105.mail.re1.yahoo.com via HTTP; Fri, 20 Feb 2009 13:01:09 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C7C@MERCURY.forterrainc.com> <945772.24514.qm@web82602.mail.mud.yahoo.com> Date: Fri, 20 Feb 2009 13:01:09 -0800 (PST) From: Ann Otoole To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1321425361-1235163669=:75906" Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:00:57 -0000 --0-1321425361-1235163669=:75906 Content-Type: text/plain; charset=us-ascii I see it more for what it is: 1. A veiled attempt to deny access to "Prokofy Neva". 2. An attempt to gender bias the activities. 3, A blatant attempt to deny access and participation to educational institutions and to private interests that may or may not have a future stake in this sector. Basically this is about a grab for power that appears to be led by a beneficiary of the former Bush administration who may now see their contracts dry up as the focus is changed. This effort should not be about corporations trying to "drive a stake in the ground from the outset" for the purpose of "preventing future expenses in technology development while securing future revenue streams". If an interest wishes to remain anonymous while observing or participating then they will and there is nothing you can do about it. So you should immediately cease and desist from paranoid activities that will ultimately taint your organization's participation with the preamble inserted of "The following text serves the financial goals of (insert corporation here) and may or may not actually have any relevance other than a profit motivation via forcing an industry onto their platform while securing future revenue streams for said corporation". Good way to kill a standards effort out of the gate. Now can we get back to the discussion? I posed a question/suggestion that spurred an excellent debate. Is it that you do not wish to have debates outside of how the Forterra OLIVE platform works? Linden Lab has promoted the open source community and a lot of excellent work was accomplished in that manner without any government funded corporations grabbing control. Perhaps we need to migrate this effort to the academic sector where it can be conducted in an unbiased manner. ________________________________ From: Charles Krinke To: Robert Gehorsam ; missannotoole@yahoo.com; mmox@ietf.org Sent: Friday, February 20, 2009 3:26:38 PM Subject: Re: [mmox] Real Names My motivation in bringing this up in the first place was to at least have a clue to whom I am speaking. In saying "business-like", I mean a "polite, fruitful interchange of useful information", which has nothing to do with whether companyX has more (or less) customers, plans, aspirations, bathrooms or virtual regions then another. Charles ________________________________ From: Robert Gehorsam To: missannotoole@yahoo.com; mmox@ietf.org Sent: Friday, February 20, 2009 12:15:33 PM Subject: Re: [mmox] Real Names Re: [mmox] Real Names Ann - I think the point is that having real names and associations with those names at the right point in time in a standards-forming process enables trust and an understanding of each party's interests. From that perspective, each party can make a judgement about the statements of others, "good" "bad" "useful" "useless" -whatever.. This not about "greed" or getting rid of SL in any way. Au contraire, the discussion is about greater inclusion in interoperability definitions. Robert -----Original Message----- From: mmox-bounces@ietf.org To: mmox@ietf.org Sent: Fri Feb 20 12:09:18 2009 Subject: Re: [mmox] Real Names This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset. I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done. ________________________________ From: Jon Watte To: Charles Krinke Cc: mmox@ietf.org; "dyerbrookme@juno.com" Sent: Friday, February 20, 2009 2:48:42 PM Subject: Re: [mmox] Real Names Charles, I would support a "real names only" policy. I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration. Sincerely, jw Charles Krinke wrote: > Dear David and Meadhbh: > > I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms. > > It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with. > > Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage? > > Charles Krinke _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-1321425361-1235163669=:75906 Content-Type: text/html; charset=us-ascii
I see it more for what it is:
1. A veiled attempt to deny access to "Prokofy Neva".
2. An attempt to gender bias the activities.
3, A blatant attempt to deny access and participation to educational institutions and to private interests that may or may not have a future stake in this sector.

Basically this is about a grab for power that appears to be led by a beneficiary of the former Bush administration who may now see their contracts dry up as the focus is changed.
This effort should not be about corporations trying to "drive a stake in the ground from the outset" for the purpose of "preventing future expenses in technology development while securing future revenue streams".

If an interest wishes to remain anonymous while observing or participating then they will and there is nothing you can do about it. So you should immediately cease and desist from paranoid activities that will ultimately taint your organization's participation with the preamble inserted of "The following text serves the financial goals of (insert corporation here) and may or may not actually have any relevance other than a profit motivation via forcing an industry onto their platform while securing future revenue streams for said corporation".

Good way to kill a standards effort out of the gate.

Now can we get back to the discussion? I posed a question/suggestion that spurred an excellent debate. Is it that you do not wish to have debates outside of how the Forterra OLIVE platform works?

Linden Lab has promoted the open source community and a lot of excellent work was accomplished in that manner without any government funded corporations grabbing control.

Perhaps we need to migrate this effort to the academic sector where it can be conducted in an unbiased manner.
From: Charles Krinke <cfk@pacbell.net>
To: Robert Gehorsam <RGehorsam@forterrainc.com>; missannotoole@yahoo.com; mmox@ietf.org
Sent: Friday, February 20, 2009 3:26:38 PM
Subject: Re: [mmox] Real Names

My motivation in bringing this up in the first place was to at least have a clue to whom I am speaking.

In saying "business-like", I mean a "polite, fruitful interchange of useful information", which has nothing to do with whether companyX has more (or less) customers, plans, aspirations, bathrooms or virtual regions then another.

Charles

From: Robert Gehorsam <RGehorsam@forterrainc.com>
To: missannotoole@yahoo.com; mmox@ietf.org
Sent: Friday, February 20, 2009 12:15:33 PM
Subject: Re: [mmox] Real Names

Re: [mmox] Real Names

Ann -

I think the point is that having real names and associations with those names at the right point in time in a standards-forming process enables trust and an understanding of each party's interests.  From that perspective, each party can make a judgement about the statements of others, "good" "bad" "useful" "useless" -whatever.. This not about "greed" or getting rid of SL in any way.  Au contraire, the discussion is about greater inclusion in interoperability definitions.

Robert

-----Original Message-----
From: mmox-bounces@ietf.org <mmox-bounces@ietf.org>
To: mmox@ietf.org <mmox@ietf.org>
Sent: Fri Feb 20 12:09:18 2009
Subject: Re: [mmox] Real Names

This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset.

I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done.


________________________________

From: Jon Watte <jwatte@gmail.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: mmox@ietf.org; "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Sent: Friday, February 20, 2009 2:48:42 PM
Subject: Re: [mmox] Real Names


Charles,

I would support a "real names only" policy.

I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration.

Sincerely,

jw


Charles Krinke wrote:
> Dear David and Meadhbh:
>
> I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms.
>
> It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with.
>
> Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage?
>
> Charles Krinke

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox


--0-1321425361-1235163669=:75906-- From cfk@pacbell.net Fri Feb 20 13:02:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45F283A6A10 for ; Fri, 20 Feb 2009 13:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaOFA+jzFLVQ for ; Fri, 20 Feb 2009 13:02:45 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id E17923A63D3 for ; Fri, 20 Feb 2009 13:02:44 -0800 (PST) Received: (qmail 56685 invoked by uid 60001); 20 Feb 2009 21:02:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=HraSgzejwXP/Lk2DUoy/Eqrv/3FRXEpUE+9sAbFZRoUyBeNfP19VUT/GL9MlhQ89a1P4T96lVzh1iaWCPB/SIN3sNkPyrrao9Y7hCDCV/fvKC5OvvWdlplb8XQ8FKKLU3v7mzc2L7U7yWchJSGaKxgCXWVflJgofABm+D1g02BA=; X-YMail-OSG: ILnOVIAVM1lL94bnKfji4MZabWg_zhk_8XMlOgjhcN7gYa.3hQoHuCsyMrSfif5W_A-- Received: from [76.222.233.250] by web82602.mail.mud.yahoo.com via HTTP; Fri, 20 Feb 2009 13:02:59 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C7E@MERCURY.forterrainc.com> Date: Fri, 20 Feb 2009 13:02:59 -0800 (PST) From: Charles Krinke To: Robert Gehorsam , missannotoole@yahoo.com, mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1915586953-1235163779=:56011" Message-ID: <811127.56011.qm@web82602.mail.mud.yahoo.com> Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:02:46 -0000 --0-1915586953-1235163779=:56011 Content-Type: text/plain; charset=us-ascii Thank you kindly, sir. I can certainly see that various groups all have a slightly differing perception of what the protocol communications that allow virtual worlds to interop are. In fact, I can see that within team members of my own group. I can also see that there are a number of hot buttons in policies and how differing virtual worlds "should" operate with respect to objects traversing world boundaries like customs at port entry/exit points. But, I also believe, that to the extent we can find agreement on at least some interoperability and all be willing to adjust our software to accomodate each other a little bit, we can avoid becoming OBE (OvertakenByEvents). Certainly, all the groups represented here, which are certainly not even all the groups have their own teams working at varying speeds on their own visions. Some of those team members read this mailing list and are adjusting their software development strategy as this situation evolves. So, perhaps we might get further a bit faster if we were to concentrate on defining our "group charter" instead of stating our positions as absolutes. I work in a group, also, and interface with a number of world class programmers who will not accept any illogical statements at all. So, we all have our groups that we represent, and we will be judged by our success in finding a consensus that lets us get past "position statements", "memo wars", "circular meetings" and the like and actually create something useful. Charles Krinke ________________________________ From: Robert Gehorsam To: cfk@pacbell.net; missannotoole@yahoo.com; mmox@ietf.org Sent: Friday, February 20, 2009 12:46:07 PM Subject: Re: [mmox] Real Names Re: [mmox] Real Names Completely agree. -----Original Message----- From: Charles Krinke To: Robert Gehorsam; missannotoole@yahoo.com ; mmox@ietf.org Sent: Fri Feb 20 12:26:38 2009 Subject: Re: [mmox] Real Names My motivation in bringing this up in the first place was to at least have a clue to whom I am speaking. In saying "business-like", I mean a "polite, fruitful interchange of useful information", which has nothing to do with whether companyX has more (or less) customers, plans, aspirations, bathrooms or virtual regions then another. Charles ________________________________ From: Robert Gehorsam To: missannotoole@yahoo.com; mmox@ietf.org Sent: Friday, February 20, 2009 12:15:33 PM Subject: Re: [mmox] Real Names Ann - I think the point is that having real names and associations with those names at the right point in time in a standards-forming process enables trust and an understanding of each party's interests. From that perspective, each party can make a judgement about the statements of others, "good" "bad" "useful" "useless" -whatever.. This not about "greed" or getting rid of SL in any way. Au contraire, the discussion is about greater inclusion in interoperability definitions. Robert -----Original Message----- From: mmox-bounces@ietf.org To: mmox@ietf.org Sent: Fri Feb 20 12:09:18 2009 Subject: Re: [mmox] Real Names This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset. I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done. ________________________________ From: Jon Watte To: Charles Krinke Cc: mmox@ietf.org; "dyerbrookme@juno.com" Sent: Friday, February 20, 2009 2:48:42 PM Subject: Re: [mmox] Real Names Charles, I would support a "real names only" policy. I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration. Sincerely, jw Charles Krinke wrote: > Dear David and Meadhbh: > > I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms. > > It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with. > > Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage? > > Charles Krinke _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-1915586953-1235163779=:56011 Content-Type: text/html; charset=us-ascii
Thank you kindly, sir.

I can certainly see that various groups all have a slightly differing perception of what the protocol communications that allow virtual worlds to interop are. In fact, I can see that within team members of my own group.

I can also see that there are a number of hot buttons in policies and how differing virtual worlds "should" operate with respect to objects traversing world boundaries like customs at port entry/exit points.

But, I also believe, that to the extent we can find agreement on at least some interoperability and all be willing to adjust our software to accomodate each other a little bit, we can avoid becoming OBE (OvertakenByEvents).

Certainly, all the groups represented here, which are certainly not even all the groups have their own teams working at varying speeds on their own visions. Some of those team members read this mailing list and are adjusting their software development strategy as this situation evolves.

So, perhaps we might get further a bit faster if we were to concentrate on defining our "group charter" instead of stating our positions as absolutes. I work in a group, also, and interface with a number of world class programmers who will not accept any illogical statements at all.

So, we all have our groups that we represent, and we will be judged by our success in finding a consensus that lets us get past "position statements", "memo wars", "circular meetings" and the like and actually create something useful.

Charles Krinke

From: Robert Gehorsam <RGehorsam@forterrainc.com>
To: cfk@pacbell.net; missannotoole@yahoo.com; mmox@ietf.org
Sent: Friday, February 20, 2009 12:46:07 PM
Subject: Re: [mmox] Real Names

Re: [mmox] Real Names

Completely agree.

-----Original Message-----
From: Charles Krinke <cfk@pacbell.net>
To: Robert Gehorsam; missannotoole@yahoo.com <missannotoole@yahoo.com>; mmox@ietf.org <mmox@ietf.org>
Sent: Fri Feb 20 12:26:38 2009
Subject: Re: [mmox] Real Names

My motivation in bringing this up in the first place was to at least have a clue to whom I am speaking.

In saying "business-like", I mean a "polite, fruitful interchange of useful information", which has nothing to do with whether companyX has more (or less) customers, plans, aspirations, bathrooms or virtual regions then another.

Charles


________________________________

From: Robert Gehorsam <RGehorsam@forterrainc.com>
To: missannotoole@yahoo.com; mmox@ietf.org
Sent: Friday, February 20, 2009 12:15:33 PM
Subject: Re: [mmox] Real Names



Ann -

I think the point is that having real names and associations with those names at the right point in time in a standards-forming process enables trust and an understanding of each party's interests.  From that perspective, each party can make a judgement about the statements of others, "good" "bad" "useful" "useless" -whatever.. This not about "greed" or getting rid of SL in any way.  Au contraire, the discussion is about greater inclusion in interoperability definitions.

Robert

-----Original Message-----
From: mmox-bounces@ietf.org <mmox-bounces@ietf.org>
To: mmox@ietf.org <mmox@ietf.org>
Sent: Fri Feb 20 12:09:18 2009
Subject: Re: [mmox] Real Names

This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset.

I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done.


________________________________

From: Jon Watte <jwatte@gmail.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: mmox@ietf.org; "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Sent: Friday, February 20, 2009 2:48:42 PM
Subject: Re: [mmox] Real Names


Charles,

I would support a "real names only" policy.

I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration.

Sincerely,

jw


Charles Krinke wrote:
> Dear David and Meadhbh:
>
> I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms.
>
> It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with.
>
> Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage?
>
> Charles Krinke

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox

--0-1915586953-1235163779=:56011-- From missannotoole@yahoo.com Fri Feb 20 13:22:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3732228C171 for ; Fri, 20 Feb 2009 13:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVsHnSyb7OtD for ; Fri, 20 Feb 2009 13:22:40 -0800 (PST) Received: from web59103.mail.re1.yahoo.com (web59103.mail.re1.yahoo.com [66.196.101.14]) by core3.amsl.com (Postfix) with SMTP id 07C7D28C16E for ; Fri, 20 Feb 2009 13:22:39 -0800 (PST) Received: (qmail 32712 invoked by uid 60001); 20 Feb 2009 21:22:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1235164974; bh=3tCe2eU0956dA9oNfZLk6xeG566Om/BT1VcVV0FLx50=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=WoMqFBXec4f1E3lG1XLhE/sBjJZdp2/9TmOIOPFsbkmwyPt8oCw6X92o7WOCw6fWV1BshsstKXq9YqEYYoFUsJ2Ft173YxPbNxm8i9oa8FLM9SzfEsuYjatDI61Z2TmaCM++ZJiFyG5UbBm6DYIe8TH5P/yOgAxlQFGVHOgIFBc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=gzRgwUe0zAVFebmVyunOgm6bWbVauxGX1jat1cDnodGB3mU0+8fOu22hi9VjfIForD0j9wuqxaOsTBu5g9chTb+T4ttHZB2bkHVBO8gFPqGDyQHp4w5G0pU8YuIQbXq//T+SFuYFim5gS++8evx2DBms1ONKTS3zehoFxZvT5R0=; Message-ID: <833718.32681.qm@web59103.mail.re1.yahoo.com> X-YMail-OSG: utrWJjIVM1lPEAFWaf3ne.qvwsFHTjRr_GqcvSuUNMS7Lz_G03uIWW1l7km53nkrF4dGiaMVT61aD1s2xHmNLORDMFn.xNYLZYIsriYrNljcCwBZb94qikpjP.fVTR0OehAoua35fX8php9JMulCe.YZTiJZ_hNRZe2e9LJGTjjmUxSefBrIWHZZnfWMBxoFrCxrHMBWEyAYZY0_ZmaV0vGkbSUDGDcouAXE6Lbwzh4W5HE- Received: from [97.102.254.236] by web59103.mail.re1.yahoo.com via HTTP; Fri, 20 Feb 2009 13:22:54 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <20090220.134403.24682.0@webmail05.vgs.untd.com> <499F0DEE.7090107@gmail.com> Date: Fri, 20 Feb 2009 13:22:54 -0800 (PST) From: Ann Otoole To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-71023426-1235164974=:32681" Subject: Re: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:22:41 -0000 --0-71023426-1235164974=:32681 Content-Type: text/plain; charset=us-ascii The first order of business should be to set up a metadata repository that commences with at least two top level topics of Legal and Technical. Under Legal would come the interests pertaining to intellectual property. The child elements can have pointers intermixed while the metadata is fully fleshed out under it's main elements. The technical implementation aspects of the various elements is a ways down the road as I see it. ________________________________ From: Jon Watte To: "dyerbrookme@juno.com" ; "mmox@ietf.org" Sent: Friday, February 20, 2009 3:09:18 PM Subject: [mmox] Content metadata through interoperability dyerbrookme@juno.com wrote: > You're assuming that Linden Lab simply won't let pass through its gates an object that is not marked for transfer. But Linden Lab's entire world has been reverse-engineered in You seem to be having a beef with Linden Labs. It seems like you don't trust Linden Labs to actually enforce any policy that would be specified in an interoperability standard. Surely there are more appropriate forums for you to discuss these Second Life specific things with Linden Labs people. I think a rule of thumb for /this particular list/ should be that if the issue discussed is not applicable at least to eight different technology vendors (for example: Multiverse, Kaneva, Areae, Forterra, Linden Labs, Qwaq, Second Life and OpenSim), then it doesn't belong on this list. >> In fact, I am arguing that we should enable exactly what you're > describing! I don't understand how you belive I'm not. > > I think it's very simple: you have to clarify whether you are for putting copy/mod/transfer permissions on objects or not. > I believe I have clearly stated that it is my position that all content should contain metadata, and one piece of that metadata is copy/reuse/cache/storage rights. The specific forms of those copy/reuse/cache/storage may be c/m/t, or more likely something a little richer to cater for situations like copylefted content that has "sticky" semantics. Sincerely, jw _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-71023426-1235164974=:32681 Content-Type: text/html; charset=us-ascii
The first order of business should be to set up a metadata repository that commences with at least two top level topics of Legal and Technical. Under Legal would come the interests pertaining to intellectual property. The child elements can have pointers intermixed while the metadata is fully fleshed out under it's main elements. The technical implementation aspects of the various elements is a ways down the road as I see it.

From: Jon Watte <jwatte@gmail.com>
To: "dyerbrookme@juno.com" <dyerbrookme@juno.com>; "mmox@ietf.org" <mmox@ietf.org>
Sent: Friday, February 20, 2009 3:09:18 PM
Subject: [mmox] Content metadata through interoperability

dyerbrookme@juno.com wrote:
> You're assuming that Linden Lab simply won't let pass through its gates an object that is not marked for transfer. But Linden Lab's entire world has been reverse-engineered in

You seem to be having a beef with Linden Labs. It seems like you don't trust Linden Labs to actually enforce any policy that would be specified in an interoperability standard. Surely there are more appropriate forums for you to discuss these Second Life specific things with Linden Labs people.

I think a rule of thumb for /this particular list/ should be that if the issue discussed is not applicable at least to eight different technology vendors (for example: Multiverse, Kaneva, Areae, Forterra, Linden Labs, Qwaq, Second Life and OpenSim), then it doesn't belong on this list.


>> In fact, I am arguing that we should enable exactly what you're   
> describing! I don't understand how you belive I'm not.
>
> I think it's very simple: you have to clarify whether you are for putting copy/mod/transfer permissions on objects or not.
> 

I believe I have clearly stated that it is my position that all content should contain metadata, and one piece of that metadata is copy/reuse/cache/storage rights. The specific forms of those copy/reuse/cache/storage may be c/m/t, or more likely something a little richer to cater for situations like copylefted content that has "sticky" semantics.

Sincerely,

jw

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox

--0-71023426-1235164974=:32681-- From infinity@lindenlab.com Fri Feb 20 13:28:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210CE28C188 for ; Fri, 20 Feb 2009 13:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcHbNbu+8lOk for ; Fri, 20 Feb 2009 13:28:04 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id E876928C19B for ; Fri, 20 Feb 2009 13:28:04 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 07B573DBC460; Fri, 20 Feb 2009 13:28:20 -0800 (PST) Message-Id: <0DFB1F56-5D87-446C-9742-FF5D9376E8C6@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Ann Otoole In-Reply-To: <898815.75906.qm@web59105.mail.re1.yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4--839937870 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 13:28:19 -0800 References: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C7C@MERCURY.forterrainc.com> <945772.24514.qm@web82602.mail.mud.yahoo.com> <898815.75906.qm@web59105.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:28:11 -0000 --Apple-Mail-4--839937870 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit let us please all calm down. ann... we are not denying access to prok. while i disagree with her on a great number of points, i will defend her right to make them. that being said, this _is_ a forum for technical discussions related to the proposed draft charter and work items. i think we can agree that the "political environment" surrounding a particular virtual world deployment is worthy of discussion to the degree that it is important that all of us understand the constraints under which other people's products / projects are expected to operate. (for instance... i sorta disagree with John Hurliman's stance on trust, but i certainly respect it and understand that if i want to develop a consensus with John, considering his interests would be a requirement. especially since my objective is to find a technical solution that meets both our interests.) i humbly request we move the discussion of politics off this list. i am not trying to muzzle dissent; i only want to move it to a more appropriate forum. and ann... i'm not trying to muzzle you either. but i have to say... your response seems to me to be dangerously close to an ad hominum attack. i ask that in this forum we ALL maintain a high level of decorum. in short... i'm here to get some engineering work done. understanding participants political / social constraints is essential, but i believe we are all better served by avoiding visiting the intentions of others and leaving the debates as to the merits of other people's politics for another forum. -sincerely -meadhbh hamrick (aka infinity linden) On Feb 20, 2009, at 1:01 PM, Ann Otoole wrote: > I see it more for what it is: > 1. A veiled attempt to deny access to "Prokofy Neva". > 2. An attempt to gender bias the activities. > 3, A blatant attempt to deny access and participation to educational > institutions and to private interests that may or may not have a > future stake in this sector. > > Basically this is about a grab for power that appears to be led by a > beneficiary of the former Bush administration who may now see their > contracts dry up as the focus is changed. > This effort should not be about corporations trying to "drive a > stake in the ground from the outset" for the purpose of "preventing > future expenses in technology development while securing future > revenue streams". > > If an interest wishes to remain anonymous while observing or > participating then they will and there is nothing you can do about > it. So you should immediately cease and desist from paranoid > activities that will ultimately taint your organization's > participation with the preamble inserted of "The following text > serves the financial goals of (insert corporation here) and may or > may not actually have any relevance other than a profit motivation > via forcing an industry onto their platform while securing future > revenue streams for said corporation". > > Good way to kill a standards effort out of the gate. > > Now can we get back to the discussion? I posed a question/suggestion > that spurred an excellent debate. Is it that you do not wish to have > debates outside of how the Forterra OLIVE platform works? > > Linden Lab has promoted the open source community and a lot of > excellent work was accomplished in that manner without any > government funded corporations grabbing control. > > Perhaps we need to migrate this effort to the academic sector where > it can be conducted in an unbiased manner. > From: Charles Krinke > To: Robert Gehorsam ; missannotoole@yahoo.com > ; mmox@ietf.org > Sent: Friday, February 20, 2009 3:26:38 PM > Subject: Re: [mmox] Real Names > > My motivation in bringing this up in the first place was to at least > have a clue to whom I am speaking. > > In saying "business-like", I mean a "polite, fruitful interchange of > useful information", which has nothing to do with whether companyX > has more (or less) customers, plans, aspirations, bathrooms or > virtual regions then another. > > Charles > > From: Robert Gehorsam > To: missannotoole@yahoo.com; mmox@ietf.org > Sent: Friday, February 20, 2009 12:15:33 PM > Subject: Re: [mmox] Real Names > > Ann - > > I think the point is that having real names and associations with > those names at the right point in time in a standards-forming > process enables trust and an understanding of each party's > interests. From that perspective, each party can make a judgement > about the statements of others, "good" "bad" "useful" "useless" - > whatever.. This not about "greed" or getting rid of SL in any way. > Au contraire, the discussion is about greater inclusion in > interoperability definitions. > > Robert > > -----Original Message----- > From: mmox-bounces@ietf.org > To: mmox@ietf.org > Sent: Fri Feb 20 12:09:18 2009 > Subject: Re: [mmox] Real Names > > This is not about your meeting rooms Jon. You are clearly trying to > shove Second Life out of the way and thus Forterra needs to be > excluded from the outset. > > I move we remove corporations from the process that have blatantly > declared a pure greed motivation as Jon/Forterra has already done. > > > ________________________________ > > From: Jon Watte > To: Charles Krinke > Cc: mmox@ietf.org; "dyerbrookme@juno.com" > Sent: Friday, February 20, 2009 2:48:42 PM > Subject: Re: [mmox] Real Names > > > Charles, > > I would support a "real names only" policy. > > I think the businesslike stage will happen if a determination of who > actually has a business interest in interoperability is made. I > don't know what the IETF rule on "observers" are -- parties who have > an interest, but don't actually have a business directly involved in > implementing the technology under consideration. > > Sincerely, > > jw > > > Charles Krinke wrote: > > Dear David and Meadhbh: > > > > I'm confused about some of the posts from email addresses that are > either unsigned or from pseudonyms. > > > > It seems entirely reasonable to me that real names be used in this > mailing list to avoid wasting all our time and so that we know who > whe are speaking with. > > > > Is there some way in an IETF mailing list or by peer pressure to > get this to a more businesslike stage? > > > > Charles Krinke > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-4--839937870 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable let us please all calm = down.

ann... we are not denying access to prok. while = i disagree with her on a great number of points, i will defend her right = to make them.

that being said, this _is_ a = forum for technical discussions related to the proposed draft charter = and work items.

i think we can agree that the = "political environment" surrounding a particular virtual world = deployment is worthy of discussion to the degree that it is important = that all of us understand the constraints under which other people's = products / projects are expected to operate. (for instance... i sorta = disagree with John Hurliman's stance on trust, but i certainly respect = it and understand that if i want to develop a consensus with John, = considering his interests would be a requirement. especially since my = objective is to find a technical solution that meets both our = interests.)

i humbly request we move the = discussion of politics off this list. i am not trying to muzzle dissent; = i only want to move it to a more appropriate = forum.

and ann... i'm not trying to muzzle you = either. but i have to say... your response seems to me to be dangerously = close to an ad hominum attack. i ask that in this forum we ALL maintain = a high level of decorum.

in short... i'm here = to get some engineering work done. understanding participants political = / social constraints is essential, but i believe we are all better = served by avoiding visiting the intentions of others and leaving the = debates as to the merits of other people's politics for another = forum.

-sincerely
-meadhbh hamrick = (aka infinity linden)

On Feb 20, 2009, at = 1:01 PM, Ann Otoole wrote:

I see it more for what it is:
1. A veiled = attempt to deny access to "Prokofy Neva".
2. An attempt to gender = bias the activities.
3, A blatant attempt to deny access and = participation to educational institutions and to private interests that = may or may not have a future stake in this sector.

Basically this = is about a grab for power that appears to be led by a beneficiary of the = former Bush administration who may now see their contracts dry up as the = focus is changed.
This effort should not be about corporations trying = to "drive a stake in the ground from the outset" for the purpose of = "preventing future expenses in technology development while securing = future revenue streams".

If an interest wishes to remain = anonymous while observing or participating then they will and there is = nothing you can do about it. So you should immediately cease and desist = from paranoid activities that will ultimately taint your organization's = participation with the preamble inserted of "The following text serves = the financial goals of (insert corporation here) and may or may not = actually have any relevance other than a profit motivation via forcing = an industry onto their platform while securing future revenue streams = for said corporation".

Good way to kill a standards effort out of = the gate. 

Now = can we get back to the discussion? I posed a question/suggestion that = spurred an excellent debate. Is it that you do not wish to have debates = outside of how the Forterra OLIVE platform works?

Linden Lab has = promoted the open source community and a lot of excellent work was = accomplished in that manner without any government funded corporations = grabbing control.

Perhaps we = need to migrate this effort to the academic sector where it can be = conducted in an unbiased manner.
From: Charles Krinke <cfk@pacbell.net>
To: Robert Gehorsam <RGehorsam@forterrainc.com>;<= span class=3D"Apple-converted-space"> missannotoole@yahoo.com; mmox@ietf.org
Sent: Friday, February 20, 2009 = 3:26:38 PM
 Re: [mmox] Real = Names

My motivation = in bringing this up in the first place was to at least have a clue to = whom I am speaking.

In saying "business-like", I mean a "polite, = fruitful interchange of useful information", which has nothing to do = with whether companyX has more (or less) customers, plans, aspirations, = bathrooms or virtual regions then another.

Charles

 Robert Gehorsam <RGehorsam@forterrainc.com>To: missannotoole@yahoo.com; mmox@ietf.org
Sent: Friday, February 20, 2009 = 12:15:33 PM
 Re: [mmox] Real = Names

Ann -

I think the point = is that having real names and associations with those names at the right = point in time in a standards-forming process enables trust and an = understanding of each party's interests.  =46rom that perspective, = each party can make a judgement about the statements of others, "good" = "bad" "useful" "useless" -whatever.. This not about "greed" or getting = rid of SL in any way.  Au contraire, the discussion is about = greater inclusion in interoperability = definitions.

Robert

-----Original = Message-----
From: mmox-bounces@ietf.org <mmox-bounces@ietf.org>
To: mmox@ietf.org <mmox@ietf.org>
Sent: Fri Feb 20 = 12:09:18 2009
Subject: Re: [mmox] Real Names

This is not about = your meeting rooms Jon. You are clearly trying to shove Second Life out = of the way and thus Forterra needs to be excluded from the = outset.

I move we remove corporations from the process that have = blatantly declared a pure greed motivation as Jon/Forterra has already = done.


________________________________

From: Jon Watte = <jwatte@gmail.com>
To: = Charles Krinke <cfk@pacbell.net>
Cc: mmox@ietf.org; "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Sent: = Friday, February 20, 2009 2:48:42 PM
Subject: Re: [mmox] Real = Names


Charles,

I would support a "real names only" = policy.

I think the businesslike stage will happen if a = determination of who actually has a business interest in = interoperability is made. I don't know what the IETF rule on "observers" = are -- parties who have an interest, but don't actually have a business = directly involved in implementing the technology under = consideration.

Sincerely,

jw


Charles Krinke = wrote:
> Dear David and Meadhbh:
>
> I'm confused about some of = the posts from email addresses that are either unsigned or from = pseudonyms.
>
> It seems entirely reasonable to me that real names = be used in this mailing list to avoid wasting all our time and so that = we know who whe are speaking with.
>
> Is there some way in an = IETF mailing list or by peer pressure to get this to a more businesslike = stage?
>
> Charles = Krinke

_______________________________________________
mmox = mailing list
mmox@ietf.org
https://www.ietf.org/m= ailman/listinfo/mmox



_______________________________________________
mmox = mailing list
mmox@ietf.org
https://www.ietf.org/m= ailman/listinfo/mmox

= --Apple-Mail-4--839937870-- From infinity@lindenlab.com Fri Feb 20 13:38:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1C7E3A68C0 for ; Fri, 20 Feb 2009 13:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3O-JhLuNhJ2 for ; Fri, 20 Feb 2009 13:38:18 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id C9CF43A67B4 for ; Fri, 20 Feb 2009 13:38:18 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 0151D3DBC455; Fri, 20 Feb 2009 13:38:34 -0800 (PST) Message-Id: <2FC34C0A-AC59-465C-9BB1-E01339EC35A8@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Ann Otoole In-Reply-To: <833718.32681.qm@web59103.mail.re1.yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-5--839324081 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 13:38:33 -0800 References: <20090220.134403.24682.0@webmail05.vgs.untd.com> <499F0DEE.7090107@gmail.com> <833718.32681.qm@web59103.mail.re1.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:38:20 -0000 --Apple-Mail-5--839324081 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit ann. this is not the forum for discussions of intellectual property in general. this is a forum for discussing issues related to technical interoperability. that being said... i agree that such a metadata repository and related discussion would be useful... only that the mmox mailing list is NOT the place for such a discussion. perhaps you could set up something like that in another location? IETF process requires people participating in IETF mailing lists and meetings disclose their intellectual property interests, so collecting that information shouldn't be difficult. and i can see where the discussion would be interesting and useful. i just want to make sure we do not derail the standards development process with inter-nicene flame wars. -sincerely -meadhbh hamrick (aka infinity linden) On Feb 20, 2009, at 1:22 PM, Ann Otoole wrote: > The first order of business should be to set up a metadata > repository that commences with at least two top level topics of > Legal and Technical. Under Legal would come the interests pertaining > to intellectual property. The child elements can have pointers > intermixed while the metadata is fully fleshed out under it's main > elements. The technical implementation aspects of the various > elements is a ways down the road as I see it. > > From: Jon Watte > To: "dyerbrookme@juno.com" ; "mmox@ietf.org" > > Sent: Friday, February 20, 2009 3:09:18 PM > Subject: [mmox] Content metadata through interoperability > > dyerbrookme@juno.com wrote: > > You're assuming that Linden Lab simply won't let pass through its > gates an object that is not marked for transfer. But Linden Lab's > entire world has been reverse-engineered in > > You seem to be having a beef with Linden Labs. It seems like you > don't trust Linden Labs to actually enforce any policy that would be > specified in an interoperability standard. Surely there are more > appropriate forums for you to discuss these Second Life specific > things with Linden Labs people. > > I think a rule of thumb for /this particular list/ should be that if > the issue discussed is not applicable at least to eight different > technology vendors (for example: Multiverse, Kaneva, Areae, > Forterra, Linden Labs, Qwaq, Second Life and OpenSim), then it > doesn't belong on this list. > > > >> In fact, I am arguing that we should enable exactly what you're > > describing! I don't understand how you belive I'm not. > > > > I think it's very simple: you have to clarify whether you are for > putting copy/mod/transfer permissions on objects or not. > > > > I believe I have clearly stated that it is my position that all > content should contain metadata, and one piece of that metadata is > copy/reuse/cache/storage rights. The specific forms of those copy/ > reuse/cache/storage may be c/m/t, or more likely something a little > richer to cater for situations like copylefted content that has > "sticky" semantics. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-5--839324081 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable ann. this is not the forum for = discussions of intellectual property in general. this is a forum for = discussing issues related to technical = interoperability.

that being said... i agree that = such a metadata repository and related discussion would be useful... = only that the mmox mailing list is NOT the place for such a = discussion.

perhaps you could set up something = like that in another location? IETF process requires people = participating in IETF mailing lists and meetings disclose their = intellectual property interests, so collecting that information = shouldn't be difficult. and i can see where the discussion would be = interesting and useful.

i just want to make = sure we do not derail the standards development process with = inter-nicene flame = wars.

-sincerely
-meadhbh hamrick = (aka infinity linden)

On Feb 20, 2009, at = 1:22 PM, Ann Otoole wrote:

The first order of business should be to set up = a metadata repository that commences with at least two top level topics = of Legal and Technical. Under Legal would come the interests pertaining = to intellectual property. The child elements can have pointers = intermixed while the metadata is fully fleshed out under it's main = elements. The technical implementation aspects of the various elements = is a ways down the road as I see it. 

 Jon = Watte <jwatte@gmail.com>
To: "dyerbrookme@juno.com" <dyerbrookme@juno.com>; "mmox@ietf.org" <mmox@ietf.org>
Sent: Friday, February 20, 2009 = 3:09:18 PM
 [mmox] Content metadata = through interoperability

dyerbrookme@juno.com wrote:
> You're assuming = that Linden Lab simply won't let pass through its gates an object that = is not marked for transfer. But Linden Lab's entire world has been = reverse-engineered in 

You seem to be = having a beef with Linden Labs. It seems like you don't trust Linden = Labs to actually enforce any policy that would be specified in an = interoperability standard. Surely there are more appropriate forums for = you to discuss these Second Life specific things with Linden Labs = people.

I think a rule of thumb for /this particular list/ should = be that if the issue discussed is not applicable at least to eight = different technology vendors (for example: Multiverse, Kaneva, Areae, = Forterra, Linden Labs, Qwaq, Second Life and OpenSim), then it doesn't = belong on this list.


>> In fact, I am arguing that we should = enable exactly what you're    
> describing! I don't = understand how you belive I'm not.
> 
> I think it's very = simple: you have to clarify whether you are for putting = copy/mod/transfer permissions on objects or not.
>  

I believe I have = clearly stated that it is my position that all content should contain = metadata, and one piece of that metadata is copy/reuse/cache/storage = rights. The specific forms of those copy/reuse/cache/storage may be = c/m/t, or more likely something a little richer to cater for situations = like copylefted content that has "sticky" = semantics.

Sincerely,

jw

____________________________= ___________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
=

_______________________________________________
mmox = mailing list
mmox@ietf.org
https://www.ietf.org/m= ailman/listinfo/mmox

= --Apple-Mail-5--839324081-- From alan_webb@us.ibm.com Fri Feb 20 13:59:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8803A67FB; Fri, 20 Feb 2009 13:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrLoL89d9EIK; Fri, 20 Feb 2009 13:59:00 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id D7E4B3A63EC; Fri, 20 Feb 2009 13:58:59 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e7.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1KLp71p019564; Fri, 20 Feb 2009 16:51:07 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1KLxElV182782; Fri, 20 Feb 2009 16:59:14 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1KLw3hX021524; Fri, 20 Feb 2009 16:58:03 -0500 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1KLw33J021521; Fri, 20 Feb 2009 16:58:03 -0500 In-Reply-To: <0DFB1F56-5D87-446C-9742-FF5D9376E8C6@lindenlab.com> References: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C7C@MERCURY.forterrainc.com> <945772.24514.qm@web82602.mail.mud.yahoo.com> <898815.75906.qm@web59105.mail.re1.yahoo.com> <0DFB1F56-5D87-446C-9742-FF5D9376E8C6@lindenlab.com> To: "Meadhbh Hamrick (Infinity)" MIME-Version: 1.0 X-KeepSent: B80FEDE1:7C4F9375-85257563:0078AA4F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Alan M Webb Message-ID: Date: Fri, 20 Feb 2009 16:59:13 -0500 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 8.5|December 05, 2008) at 02/20/2009 16:59:12, Serialize complete at 02/20/2009 16:59:12 Content-Type: multipart/alternative; boundary="=_alternative 0078C5F385257563_=" Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 21:59:01 -0000 This is a multipart message in MIME format. --=_alternative 0078C5F385257563_= Content-Type: text/plain; charset="US-ASCII" I thought it was noted much earlier in this discussion that the IETF require real names to be used in any significant documentation or correspondence associated with the standards process. Best regards Alan ------------------- T.J. Watson Research Center, Hawthorne, NY 1-914-784-7286 alan_webb@us.ibm.com From: "Meadhbh Hamrick (Infinity)" To: Ann Otoole Cc: mmox@ietf.org Date: 02/20/2009 04:28 PM Subject: Re: [mmox] Real Names let us please all calm down. ann... we are not denying access to prok. while i disagree with her on a great number of points, i will defend her right to make them. that being said, this _is_ a forum for technical discussions related to the proposed draft charter and work items. i think we can agree that the "political environment" surrounding a particular virtual world deployment is worthy of discussion to the degree that it is important that all of us understand the constraints under which other people's products / projects are expected to operate. (for instance... i sorta disagree with John Hurliman's stance on trust, but i certainly respect it and understand that if i want to develop a consensus with John, considering his interests would be a requirement. especially since my objective is to find a technical solution that meets both our interests.) i humbly request we move the discussion of politics off this list. i am not trying to muzzle dissent; i only want to move it to a more appropriate forum. and ann... i'm not trying to muzzle you either. but i have to say... your response seems to me to be dangerously close to an ad hominum attack. i ask that in this forum we ALL maintain a high level of decorum. in short... i'm here to get some engineering work done. understanding participants political / social constraints is essential, but i believe we are all better served by avoiding visiting the intentions of others and leaving the debates as to the merits of other people's politics for another forum. -sincerely -meadhbh hamrick (aka infinity linden) On Feb 20, 2009, at 1:01 PM, Ann Otoole wrote: I see it more for what it is: 1. A veiled attempt to deny access to "Prokofy Neva". 2. An attempt to gender bias the activities. 3, A blatant attempt to deny access and participation to educational institutions and to private interests that may or may not have a future stake in this sector. Basically this is about a grab for power that appears to be led by a beneficiary of the former Bush administration who may now see their contracts dry up as the focus is changed. This effort should not be about corporations trying to "drive a stake in the ground from the outset" for the purpose of "preventing future expenses in technology development while securing future revenue streams". If an interest wishes to remain anonymous while observing or participating then they will and there is nothing you can do about it. So you should immediately cease and desist from paranoid activities that will ultimately taint your organization's participation with the preamble inserted of "The following text serves the financial goals of (insert corporation here) and may or may not actually have any relevance other than a profit motivation via forcing an industry onto their platform while securing future revenue streams for said corporation". Good way to kill a standards effort out of the gate. Now can we get back to the discussion? I posed a question/suggestion that spurred an excellent debate. Is it that you do not wish to have debates outside of how the Forterra OLIVE platform works? Linden Lab has promoted the open source community and a lot of excellent work was accomplished in that manner without any government funded corporations grabbing control. Perhaps we need to migrate this effort to the academic sector where it can be conducted in an unbiased manner. From: Charles Krinke To: Robert Gehorsam ; missannotoole@yahoo.com; mmox@ietf.org Sent: Friday, February 20, 2009 3:26:38 PM Subject: Re: [mmox] Real Names My motivation in bringing this up in the first place was to at least have a clue to whom I am speaking. In saying "business-like", I mean a "polite, fruitful interchange of useful information", which has nothing to do with whether companyX has more (or less) customers, plans, aspirations, bathrooms or virtual regions then another. Charles From: Robert Gehorsam To: missannotoole@yahoo.com; mmox@ietf.org Sent: Friday, February 20, 2009 12:15:33 PM Subject: Re: [mmox] Real Names Ann - I think the point is that having real names and associations with those names at the right point in time in a standards-forming process enables trust and an understanding of each party's interests. From that perspective, each party can make a judgement about the statements of others, "good" "bad" "useful" "useless" -whatever.. This not about "greed" or getting rid of SL in any way. Au contraire, the discussion is about greater inclusion in interoperability definitions. Robert -----Original Message----- From: mmox-bounces@ietf.org To: mmox@ietf.org Sent: Fri Feb 20 12:09:18 2009 Subject: Re: [mmox] Real Names This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset. I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done. ________________________________ From: Jon Watte To: Charles Krinke Cc: mmox@ietf.org; "dyerbrookme@juno.com" Sent: Friday, February 20, 2009 2:48:42 PM Subject: Re: [mmox] Real Names Charles, I would support a "real names only" policy. I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration. Sincerely, jw Charles Krinke wrote: > Dear David and Meadhbh: > > I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms. > > It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with. > > Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage? > > Charles Krinke _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --=_alternative 0078C5F385257563_= Content-Type: text/html; charset="US-ASCII"
I thought it was noted much earlier in this discussion that the IETF require real names to be used in any significant documentation or correspondence associated with the standards process.

Best regards
Alan
-------------------
T.J. Watson Research Center, Hawthorne, NY
1-914-784-7286
alan_webb@us.ibm.com


From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: Ann Otoole <missannotoole@yahoo.com>
Cc: mmox@ietf.org
Date: 02/20/2009 04:28 PM
Subject: Re: [mmox] Real Names




let us please all calm down.

ann... we are not denying access to prok. while i disagree with her on a great number of points, i will defend her right to make them.

that being said, this _is_ a forum for technical discussions related to the proposed draft charter and work items.

i think we can agree that the "political environment" surrounding a particular virtual world deployment is worthy of discussion to the degree that it is important that all of us understand the constraints under which other people's products / projects are expected to operate. (for instance... i sorta disagree with John Hurliman's stance on trust, but i certainly respect it and understand that if i want to develop a consensus with John, considering his interests would be a requirement. especially since my objective is to find a technical solution that meets both our interests.)

i humbly request we move the discussion of politics off this list. i am not trying to muzzle dissent; i only want to move it to a more appropriate forum.

and ann... i'm not trying to muzzle you either. but i have to say... your response seems to me to be dangerously close to an ad hominum attack. i ask that in this forum we ALL maintain a high level of decorum.

in short... i'm here to get some engineering work done. understanding participants political / social constraints is essential, but i believe we are all better served by avoiding visiting the intentions of others and leaving the debates as to the merits of other people's politics for another forum.

-sincerely
-meadhbh hamrick (aka infinity linden)

On Feb 20, 2009, at 1:01 PM, Ann Otoole wrote:

I see it more for what it is:
1. A veiled attempt to deny access to "Prokofy Neva".
2. An attempt to gender bias the activities.
3, A blatant attempt to deny access and participation to educational institutions and to private interests that may or may not have a future stake in this sector.

Basically this is about a grab for power that appears to be led by a beneficiary of the former Bush administration who may now see their contracts dry up as the focus is changed.
This effort should not be about corporations trying to "drive a stake in the ground from the outset" for the purpose of "preventing future expenses in technology development while securing future revenue streams".

If an interest wishes to remain anonymous while observing or participating then they will and there is nothing you can do about it. So you should immediately cease and desist from paranoid activities that will ultimately taint your organization's participation with the preamble inserted of "The following text serves the financial goals of (insert corporation here) and may or may not actually have any relevance other than a profit motivation via forcing an industry onto their platform while securing future revenue streams for said corporation".

Good way to kill a standards effort out of the gate.

Now can we get back to the discussion? I posed a question/suggestion that spurred an excellent debate. Is it that you do not wish to have debates outside of how the Forterra OLIVE platform works?

Linden Lab has promoted the open source community and a lot of excellent work was accomplished in that manner without any government funded corporations grabbing control.
Perhaps we need to migrate this effort to the academic sector where it can be conducted in an unbiased manner.
From: Charles Krinke <cfk@pacbell.net>
To: Robert Gehorsam <RGehorsam@forterrainc.com>; missannotoole@yahoo.com; mmox@ietf.org
Sent: Friday, February 20, 2009 3:26:38 PM
Subject: Re: [mmox] Real Names
My motivation in bringing this up in the first place was to at least have a clue to whom I am speaking.

In saying "business-like", I mean a "polite, fruitful interchange of useful information", which has nothing to do with whether companyX has more (or less) customers, plans, aspirations, bathrooms or virtual regions then another.

Charles

From: Robert Gehorsam <RGehorsam@forterrainc.com>
To: missannotoole@yahoo.com; mmox@ietf.org
Sent: Friday, February 20, 2009 12:15:33 PM
Subject: Re: [mmox] Real Names
Ann -

I think the point is that having real names and associations with those names at the right point in time in a standards-forming process enables trust and an understanding of each party's interests.  From that perspective, each party can make a judgement about the statements of others, "good" "bad" "useful" "useless" -whatever.. This not about "greed" or getting rid of SL in any way.  Au contraire, the discussion is about greater inclusion in interoperability definitions.

Robert

-----Original Message-----
From: mmox-bounces@ietf.org <mmox-bounces@ietf.org>
To: mmox@ietf.org <mmox@ietf.org>
Sent: Fri Feb 20 12:09:18 2009
Subject: Re: [mmox] Real Names

This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset.

I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done.


________________________________

From: Jon Watte <jwatte@gmail.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: mmox@ietf.org; "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Sent: Friday, February 20, 2009 2:48:42 PM
Subject: Re: [mmox] Real Names


Charles,

I would support a "real names only" policy.

I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration.

Sincerely,

jw


Charles Krinke wrote:
> Dear David and Meadhbh:
>
> I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms.
>
> It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with.
>
> Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage?
>
> Charles Krinke

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox


_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox

--=_alternative 0078C5F385257563_=-- From jwatte@gmail.com Fri Feb 20 15:01:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A88C3A6359 for ; Fri, 20 Feb 2009 15:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5VW9qtW1dG6 for ; Fri, 20 Feb 2009 15:01:48 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id D3B143A6A45 for ; Fri, 20 Feb 2009 15:01:47 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so934554ywh.49 for ; Fri, 20 Feb 2009 15:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DG9I8Dret0GJ87Sl3Ikd0/lRg/FKG4a3Gu9qeK0aWXs=; b=tbZ/FRM60+4ldkmyTOu0ZQ9tAUWA8S1YYXqino2Tozri0SE7gc+PA4GqA3kbkyoR13 k403tjvfBnZ1b3wT/QDwEsnFZTHcVDzTY5N6N/LFLoPcBvzGhIzY9AX0RBpGDhNjkpng NoDX/S4SO94C6i3pE3UwWGV0uWKHEm3h1Avgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=nNI7/O+bYvoniN3kZDwuaNRlECxlnM3Npa0h/C77xgwpgJjWDzC89ag5gm2nhQof1F KfbIkSuVeYtsNc4VLNjflYfZo6EqxavqQcE4sI+jvmo9+mjWcjVoMEcY9jyj5vdopbhv lFN9cImI5Ib6TAR0xlqC/lcBA8WCI0KNh/j8U= Received: by 10.100.131.16 with SMTP id e16mr2049736and.67.1235170921866; Fri, 20 Feb 2009 15:02:01 -0800 (PST) Received: from ?192.168.168.110? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c28sm5082612anc.25.2009.02.20.15.02.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 15:02:01 -0800 (PST) Message-ID: <499F3667.4000901@gmail.com> Date: Fri, 20 Feb 2009 15:01:59 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> In-Reply-To: <314782.22040.qm@web82601.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 23:01:49 -0000 Well, I can contribute a number of protocols that are also in widespread use. However, I don't think that would be useful, because any protocol that assumes too much about the source architecture will necessarily be improperly slanted, or too watered down to be useful for anything real. Maybe it hasn't been clear, but every proposal I have made here has not been based on how OLIVE works (I could happily describe that, too, but I don't think most other systems would accept our internal model as "the" standard). My proposals have all been made based on my experience integrating a variety of systems, and being involved in the innards of several multiplayer online systems (be they games or other things). I believe that that's the right approach to take: Look at what the industry at large is doing, where it's going, and design based on that. Starting with one particular technology is, I think, a mistake -- but if that's what we want to do, please let me write up the OLIVE TVP protocol and propose that as an alternative protocol for discussion. It certainly has a lot of attractive qualities, like doing time sync, being bit-packed, being input-synchronous (and thus 10 to 100 times as compact as state-based protocols), etc. I believe there are two ways to go 1) Look at OGP and LLSD, and/or other existing protocols that have been or will be suggested, and then suggest removal of anything that's not applicable/appropriate, and suggest addition of anything that seems necessry. 2) Actually start out with the core principles: what are we trying to standardize? Then look for appropriate protocols, if they exist, or design new ones, if they don't. I believe OGP and LLSD may be a fine match for the Linden Labs / Second Life AWG, but from experience I think they are very poor matches to a wider VW interoperability field. Sincerely, jw Charles Krinke wrote: > Well, since the draft proposal is for OGP and LLSD, it seems unlikely > that we would stop talking about either. > > In fact, I would like to know more about OGP and LLSD on this list as > we move forward in trying to standardize some protocols that are in > wide spread use. > > Charles > > ------------------------------------------------------------------------ > *From:* Jon Watte > *To:* Meadhbh Hamrick (Infinity) > *Cc:* Charles Krinke ; "mmox@ietf.org" > *Sent:* Friday, February 20, 2009 11:59:01 AM > *Subject:* Learning from the past; focusing on the future > > Meadhbh Hamrick (Infinity) wrote: > > DIS and HLA are "a bit complex" and were designed to provide > services that were vaguely different from what we're aiming at here. I > don't think we're interested in simulating just a battlefield of > tanks. i think what we're thinking about is a wire protocol that does > not carry a specific semantic load and is less declarative and more > proscriptive. that is to say.. DIS > > Agreed. That's why I think that the final solution will not be > strictly based on DIS (and clearly not on HLA). However, I mention > these protocols, because DIS has been extremely successful, and solves > pretty much the same problem we're trying to solve, but in a narrower > scope. Meanwhile, HLA has had a rocky history trying to solve the same > problem; largely exactly /because /it is "mechanism, not policy" (or, > in your words, proscriptive, not declarative). In HLA, you can > theoretically support a number of object models (known as FOMs). This > leads to virutal systems that are supposedly interoperable, not > actually being able to interoperate, because semantics were left as an > exercise for the reader. > > I think that learning from this past is crucial for any future virutal > worlds standards effort. > > > > >> Or do you want to use the Second Life system just because it's > Second Life, even if it's not currently implemented or in current > commercial use? > > > > again. > > > > we are not proposing the existing second life protocol for > standardization. i think we've said that several times. > > > > we would like to develop a protocol or protocol framework that is > "widely usable." > > > > Me too! However, a number of people on this list have said that they > believe the forums' goal is to standardize OGP and LLSD. I'd like > everyone to agree that that's *not* the goal, and then stop talking > about it. > > > Sincerely, > > jw > > From missannotoole@yahoo.com Fri Feb 20 15:10:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5218D3A63EC for ; Fri, 20 Feb 2009 15:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNJ4PI3TNCn8 for ; Fri, 20 Feb 2009 15:10:12 -0800 (PST) Received: from web59104.mail.re1.yahoo.com (web59104.mail.re1.yahoo.com [66.196.101.15]) by core3.amsl.com (Postfix) with SMTP id F03933A69D0 for ; Fri, 20 Feb 2009 15:10:11 -0800 (PST) Received: (qmail 1273 invoked by uid 60001); 20 Feb 2009 23:10:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1235171426; bh=BBn7wYbiwoNMoGoUGhHSyAm3O7bMTqfwnzIXmiPtTKw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=oP63BPgrB+UtPSDzfoUrXDfZQdT4otsAaApBUrv33gNzfbl9Dt4cbIEnLuTW4RbN9kFOGJ2JEEULb4drAWGFtauhAbXjoUHXhx1qGeV1tmcWv2ASP8xw5C8UEVaOXrMiXHZBrkj66TLCGtT5J1LXNhS+9UlOtk7xdzqVQiTmLlE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=F8WSf0OWKHdMIIjU5+dW7rAboyexCMyQwSZbDPmXrZVnkak7BqRzq1vKAU0wg7v3bKy2yb0VGkFZRiO7f5qJrLCsYIt812vSSxKW7ZPFXg/dXuVDSPTsfZzJVKsNhEFR8ysZl2Q1PbV4D+8R5BSm6vZe95ZSnT/BWeo0fI/Kfuc=; Message-ID: <34264.99944.qm@web59104.mail.re1.yahoo.com> X-YMail-OSG: piofpekVM1lbsTjFFkLrAbo5xDmV6wB9CKvxAI_ULSlPwj_norAlGpj8LeHgtVAqwOe.ovIoT4EOZRdJTDnbornGCZEjxzmhhBDMFw8ycD.MNY0T_va_OWSdUzuGki8I9W3zW9.S.SGl1a7A0Qf2ftgkE4wyj8PaXy9vCrkUBq.1mo3idHTAHMyCc5ekI1_ssB3w68Lvi9Re7xLapm_m1RJVxEzZYnL0eCPVkS9OmCsMw6s- Received: from [97.102.254.236] by web59104.mail.re1.yahoo.com via HTTP; Fri, 20 Feb 2009 15:10:25 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <20090220.134403.24682.0@webmail05.vgs.untd.com> <499F0DEE.7090107@gmail.com> <833718.32681.qm@web59103.mail.re1.yahoo.com> <2FC34C0A-AC59-465C-9BB1-E01339EC35A8@lindenlab.com> Date: Fri, 20 Feb 2009 15:10:25 -0800 (PST) From: Ann Otoole To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1125827559-1235171425=:99944" Subject: Re: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 23:10:13 -0000 --0-1125827559-1235171425=:99944 Content-Type: text/plain; charset=us-ascii So there appears to be agreement that intellectual property metadata, however that looks when published by whomever publishes it, shall be part of the interoperability standard and such filtering of content data shall be part of the common sub routines to ensure content not flagged for transport shall not be transported. Just a generic submissive stance to a superceding authority seems adequate should such an authority ever appear. Then the content creators and lawyers can go have their discussions and form the rules which MMOX will then have to accomodate as a technical implementation (which seems rather trivial once there is a metadata standard). Is that the general reason for excluding intellectual property rights from a interoperability standard? Anyway I am more interested in how some people feel the avatar identity can somehow be represented in multiple spaces at the same time without having to transmit said mesh/texture and environment appearance data. That is a very interesting suggestion. Is it that what one sees is not what another sees and avatars are just generic default visual representaions except on the individual participant's screen where they see what they want to see? I.e.; that impressive Orc or whatever shows up in Jon's meeting room as a standard faceless guy in a black business suit as do all meeting participants. (And no copyrighted data has been transferred btw) Might save a lot of bytes, the available supply of which are becoming limited by US broadband service providers. There will have to be trade offs to accomodate byte transfer capping I guess. Or is some sort of homogenous data hub between worlds the way to go? I have built ETL systems to interrogate all sorts of databases on different technologies simultaneously and translate all the data into a common format for a single fact repository so I see it as entirely feasible to have a hub of sorts (deployed at each "world) to make it possible for data to be shared among worlds with very few limitations other than the overhead of conversion/translation and the unavoidable overhead of bytes transferred. ________________________________ From: Meadhbh Hamrick (Infinity) To: Ann Otoole Cc: mmox@ietf.org Sent: Friday, February 20, 2009 4:38:33 PM Subject: Re: [mmox] Content metadata through interoperability ann. this is not the forum for discussions of intellectual property in general. this is a forum for discussing issues related to technical interoperability. that being said... i agree that such a metadata repository and related discussion would be useful... only that the mmox mailing list is NOT the place for such a discussion. perhaps you could set up something like that in another location? IETF process requires people participating in IETF mailing lists and meetings disclose their intellectual property interests, so collecting that information shouldn't be difficult. and i can see where the discussion would be interesting and useful. i just want to make sure we do not derail the standards development process with inter-nicene flame wars. -sincerely -meadhbh hamrick (aka infinity linden) --0-1125827559-1235171425=:99944 Content-Type: text/html; charset=us-ascii

So there appears to be agreement that intellectual property metadata, however that looks when published by whomever publishes it, shall be part of the interoperability standard and such filtering of content data shall be part of the common sub routines to ensure content not flagged for transport shall not be transported. Just a generic submissive stance to a superceding authority seems adequate should such an authority ever appear. Then the content creators and lawyers can go have their discussions and form the rules which MMOX will then have to accomodate as a technical implementation (which seems rather trivial once there is a metadata standard). Is that the general reason for excluding intellectual property rights from a interoperability standard?

Anyway I am more interested in how some people feel the avatar identity can somehow be represented in multiple spaces at the same time without having to transmit said mesh/texture and environment appearance data. That is a very interesting suggestion. Is it that what one sees is not what another sees and avatars are just generic default visual representaions except on the individual participant's screen where they see what they want to see? I.e.; that impressive Orc or whatever shows up in Jon's meeting room as a standard faceless guy in a black business suit as do all meeting participants. (And no copyrighted data has been transferred btw) Might save a lot of bytes, the available supply of which are becoming limited by US broadband service providers. There will have to be trade offs to accomodate byte transfer capping I guess.

Or is some sort of homogenous data hub between worlds the way to go? I have built ETL systems to interrogate all sorts of databases on different technologies simultaneously and translate all the data into a common format for a single fact repository so I see it as entirely feasible to have a hub of sorts (deployed at each "world) to make it possible for data to be shared among worlds with very few limitations other than the overhead of conversion/translation and the unavoidable overhead of bytes transferred.

From: Meadhbh Hamrick (Infinity) <infinity@lindenlab.com>
To: Ann Otoole <missannotoole@yahoo.com>
Cc: mmox@ietf.org
Sent: Friday, February 20, 2009 4:38:33 PM
Subject: Re: [mmox] Content metadata through interoperability

ann. this is not the forum for discussions of intellectual property in general. this is a forum for discussing issues related to technical interoperability.

that being said... i agree that such a metadata repository and related discussion would be useful... only that the mmox mailing list is NOT the place for such a discussion.

perhaps you could set up something like that in another location? IETF process requires people participating in IETF mailing lists and meetings disclose their intellectual property interests, so collecting that information shouldn't be difficult. and i can see where the discussion would be interesting and useful.

i just want to make sure we do not derail the standards development process with inter-nicene flame wars.

-sincerely
-meadhbh hamrick (aka infinity linden)


--0-1125827559-1235171425=:99944-- From gareth@litesim.com Fri Feb 20 16:09:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3ADC3A698E for ; Fri, 20 Feb 2009 16:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjeHFsDuHCWQ for ; Fri, 20 Feb 2009 16:09:55 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 07FBA3A6806 for ; Fri, 20 Feb 2009 16:09:54 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1076827rvb.49 for ; Fri, 20 Feb 2009 16:10:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.115.6 with SMTP id s6mr665304rvm.117.1235175009486; Fri, 20 Feb 2009 16:10:09 -0800 (PST) In-Reply-To: <898815.75906.qm@web59105.mail.re1.yahoo.com> References: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C7C@MERCURY.forterrainc.com> <945772.24514.qm@web82602.mail.mud.yahoo.com> <898815.75906.qm@web59105.mail.re1.yahoo.com> Date: Sat, 21 Feb 2009 00:10:09 +0000 Message-ID: <61dbdd7d0902201610i52f36322tb67594ea4767acbc@mail.gmail.com> From: Gareth Nelson To: Ann Otoole Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Real Names X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:09:55 -0000 1 - Prok herself has posted that she thinks this is a good idea 2 - Real names don't "gender bias" anything, both males and females do have real names you know..... perhaps you meant some people might not wish to disclose their RL name if their RL gender is a mismatch? For the record, so far at least 3 people have posted who are publically "SL transgendered" - myself included 3 - Because educational institutions need to be anonymous? On Fri, Feb 20, 2009 at 9:01 PM, Ann Otoole wrote: > I see it more for what it is: > 1. A veiled attempt to deny access to "Prokofy Neva". > 2. An attempt to gender bias the activities. > 3, A blatant attempt to deny access and participation to educational > institutions and to private interests that may or may not have a future > stake in this sector. From gareth@litesim.com Fri Feb 20 16:12:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26C703A698E for ; Fri, 20 Feb 2009 16:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXPOxmxN0uy8 for ; Fri, 20 Feb 2009 16:12:09 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 61F6C3A6806 for ; Fri, 20 Feb 2009 16:12:09 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1077468rvb.49 for ; Fri, 20 Feb 2009 16:12:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.87.13 with SMTP id p13mr657710rvl.229.1235175143781; Fri, 20 Feb 2009 16:12:23 -0800 (PST) In-Reply-To: <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> Date: Sat, 21 Feb 2009 00:12:23 +0000 Message-ID: <61dbdd7d0902201612i415f8f0i5be70c164d5412e7@mail.gmail.com> From: Gareth Nelson To: "Mark P. McCahill" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:12:10 -0000 > Tightly coupling the MSP and identity provider functions is why I have to > keep telling people that Mark McCahill is named Mysterio Sinister in Second > Life - I can't easily be mccahill@duke.edu because Second Life doesn't use > external federated identity providers. Then when I go to one of the OpenSim > worlds, I need to create another account, and hope that nobody has signed up > for Mysterio Sinister before I got there. Correct me if i'm wrong, but isn't this the problem the OGP agent domain was designed to resolve? I propose an agent domain which itself allows multiple methods of authentication From belxjander@gmail.com Fri Feb 20 16:16:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA0528C221 for ; Fri, 20 Feb 2009 16:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExRZkTFH5f6b for ; Fri, 20 Feb 2009 16:16:34 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 99BAB28C199 for ; Fri, 20 Feb 2009 16:16:34 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1078650rvb.49 for ; Fri, 20 Feb 2009 16:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=i6sPTtkFybco4bR8l+v4SmlbiWVw1YFCsAqTyrYbeWw=; b=ggJj1CP959aOqvQFLJfohaRCj/5mMhfUb4YE1tLIyp/mKcjSc2Nmelvj5w4yDzKKVu 15DkBm/b+muesfASUavr8t5tt3EdrQn2WWc/Rmcs7TdYOiSuFIqqnIZRe/5peJV1Vp03 oYtsKxoT8sRsuwnmsvHBJc759rC5w783fu3zY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=vFQNbAQqY4CD48Z4hF2jfNF4+18+MQV5Y1+ho3ga/i6yHr9N74SxMWDbVwOTWIN0Cd xCjGA4hO0xzdBe7M0GQFeAKtgDq9e3eK7YLbo4lY9SOlp8QDtKi9GE/sKpd55gLDQtUg euj32TUOP73BNPgncYFKiTi53uEPRO+myRlgA= Received: by 10.140.157.5 with SMTP id f5mr665107rve.122.1235175408562; Fri, 20 Feb 2009 16:16:48 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id k37sm7417408rvb.1.2009.02.20.16.16.46 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 16:16:47 -0800 (PST) From: Kajikawa Jeremy To: Ann Otoole In-Reply-To: <34264.99944.qm@web59104.mail.re1.yahoo.com> References: <20090220.134403.24682.0@webmail05.vgs.untd.com> <499F0DEE.7090107@gmail.com> <833718.32681.qm@web59103.mail.re1.yahoo.com> <2FC34C0A-AC59-465C-9BB1-E01339EC35A8@lindenlab.com> <34264.99944.qm@web59104.mail.re1.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-MewlfKXB8iYOVZF8DRmp" Date: Sat, 21 Feb 2009 09:11:19 +0900 Message-Id: <1235175079.7560.172.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: "mmox@ietf.org" Subject: Re: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:16:35 -0000 --=-MewlfKXB8iYOVZF8DRmp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I would agree about the multiple-presence by permissive authorizations across servers and the appearance of an AV being different per-grid. the only "same-same" appearance options would have to be when the account can have set an "export permitted" *minimal* AV dataset for baking with anything marked grid-exclusive being denied to that sort of "minimal AV"... so someone going to an R18 grid doesnt "take" the materials that are R18 restricted onto a grid region setup for "Teenagers" because I see that someone *will* try that, just to get away with it ... just to clarify... I have accounts on "MSN"/"ICQ"/"Y!M"/"Gtalk"(jabber) and "AIM"... and have replicated the base information to ALL of the accounts with few differences. I see the multiple grid issue along the same lines, restrict to "Identity"&"presence", with the AV and immediate "clothing" being the appearance for presence. and it would always be quicker to have an AV that suites the environment on the grid. If someone makes a "Clan of the Cave bear" environment and someone walks in from playing on an UT2003 or UT2009 server and keeps the AV... it would be too anacronistic to explain away if they are part of the "tribe" in each. Having the option of a "default" AV per-grid would also be using "extended" Identity, by having a "presence" module for each server(group?) have a UserAccount entry for every AV present (even a temporary "extern" entry) and allow a more seamless experience at the user-end as well. =20 as for the Intellectual Property rights exclusion, are they truly being excluded? since "IP materials" such as a piece of SL "clothing" for an AV if appropriate for an alternate system *may* become transportable where a mechanism is made or becomes available. Personally I am wondering about some kind of "object tracking" mechanism, I tried to discuss using a "BitTorrent" style tracker for providing a distribution mechanism where a "content creator" can provide an initial "seed" object and have each "service" "track" it using Asset/Inventory support. This would require a caching mechanism and allow any servers that need the object simply using the index metadata and obtaining it quickly with validation included. this would be useful as a distribution and content tracking mechanism using the existing UUID as "label" for the tracker... however without the metadata and key the trackered item would be effectively useless. to purchase a license you would obtain the metadata and key from the content maker. I personally think metadata such as that would need to have a "local storage" option and any kind of local storage would need to include being keyed. Ive sketched up a few things on paper and Im slowly working through putting them into a more cohesive sketch for submission and review and here would be a decent place since Im trying to make everything as simple as possible. okay...thats it for the braindump... Comments please! :) Jeremy On Fri, 2009-02-20 at 15:10 -0800, Ann Otoole wrote: > So there appears to be agreement that intellectual property metadata, > however that looks when published by whomever publishes it, shall be > part of the interoperability standard and such filtering of content > data shall be part of the common sub routines to ensure content not > flagged for transport shall not be transported. Just a generic > submissive stance to a superceding authority seems adequate should > such an authority ever appear. Then the content creators and lawyers > can go have their discussions and form the rules which MMOX will then > have to accomodate as a technical implementation (which seems rather > trivial once there is a metadata standard). Is that the general reason > for excluding intellectual property rights from a interoperability > standard?=20 >=20 > Anyway I am more interested in how some people feel the avatar > identity can somehow be represented in multiple spaces at the same > time without having to transmit said mesh/texture and environment > appearance data. That is a very interesting suggestion. Is it that > what one sees is not what another sees and avatars are just generic > default visual representaions except on the individual participant's > screen where they see what they want to see? I.e.; that impressive Orc > or whatever shows up in Jon's meeting room as a standard faceless guy > in a black business suit as do all meeting participants. (And no > copyrighted data has been transferred btw) Might save a lot of bytes, > the available supply of which are becoming limited by US broadband > service providers. There will have to be trade offs to accomodate byte > transfer capping I guess. >=20 > Or is some sort of homogenous data hub between worlds the way to go? I > have built ETL systems to interrogate all sorts of databases on > different technologies simultaneously and translate all the data into > a common format for a single fact repository so I see it as entirely > feasible to have a hub of sorts (deployed at each "world) to make it > possible for data to be shared among worlds with very few limitations > other than the overhead of conversion/translation and the unavoidable > overhead of bytes transferred. >=20 >=20 >=20 > ______________________________________________________________________ > From: Meadhbh Hamrick (Infinity) > To: Ann Otoole > Cc: mmox@ietf.org > Sent: Friday, February 20, 2009 4:38:33 PM > Subject: Re: [mmox] Content metadata through interoperability >=20 > ann. this is not the forum for discussions of intellectual property in > general. this is a forum for discussing issues related to technical > interoperability. >=20 >=20 > that being said... i agree that such a metadata repository and related > discussion would be useful... only that the mmox mailing list is NOT > the place for such a discussion. >=20 >=20 > perhaps you could set up something like that in another location? IETF > process requires people participating in IETF mailing lists and > meetings disclose their intellectual property interests, so collecting > that information shouldn't be difficult. and i can see where the > discussion would be interesting and useful. >=20 >=20 > i just want to make sure we do not derail the standards development > process with inter-nicene flame wars. >=20 >=20 > -sincerely > -meadhbh hamrick (aka infinity linden) >=20 >=20 >=20 > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-MewlfKXB8iYOVZF8DRmp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJn0anAAoJECHrKutFYVwT/dwQAMEZQAz2M6fgV+Fj4TbwjgGP iHthA/oCFvxddk0RK1XD/fAt/9G1YdvZZP+BkPLCpB8rMjpIzSfgvltcZJKJv+u4 fcoMoPUcmb8jpfI5AJ9kBNaT55Z4iv9wFLqQsXC+qT6dZMchVMVZMG3lvPfBNqFE b9bWnm10YNaTqmuy/QwYDblrrXQjYvsSFmBbWZJUzLH0QAd1H9XqIPY8rTBPZc4S ItG5vfGGMNz0qIbEUw1kbDoLNwaoLDnrPcgVekkokkrmeyFyKcl9mDnYvBEZwrrJ oG7rODHQ/TDWihITTHKYczCTSm+t0iB2kTVpYQOA8D3HKtW0UlYJ2+PpG6VFt/zC kBg2q5PhpCrcXbwkPZINvsTHpLmIdHnhl1CIX/jEZhDOTNpxTpVHgklagBhRw4ei Siom4M0fY1o31xwN6yRWTDswjXGqPSPIdVpPyXcVFrF6tsRUhmq5tu1/bVu4slw9 ymmC91RGRoeEZm0qGT7nVTSVbutz95YtCWAE2yu+bpYrSqJtT/nLA1DyrJ9KdGFF 3JLLM6/hEo6ZkbOBn02zMDWwGctHMRuxukOjBdAmaJhgUvSimzBde3hhY2o+ooDG BCG17BRI88+E4lgUzzthay7/kwR7uspnWleZQRsvyDiSuQ/8q0Uz7Rsk8Fn2Jpt9 wEbD/DQ6LttFF5zcIqBx =p4US -----END PGP SIGNATURE----- --=-MewlfKXB8iYOVZF8DRmp-- From gareth@litesim.com Fri Feb 20 16:18:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7717E28C21A for ; Fri, 20 Feb 2009 16:18:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZE++LQo1FwUy for ; Fri, 20 Feb 2009 16:18:38 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 985B228C199 for ; Fri, 20 Feb 2009 16:18:38 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1079187rvb.49 for ; Fri, 20 Feb 2009 16:18:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.226.14 with SMTP id y14mr665427rvg.153.1235175533152; Fri, 20 Feb 2009 16:18:53 -0800 (PST) In-Reply-To: <833718.32681.qm@web59103.mail.re1.yahoo.com> References: <20090220.134403.24682.0@webmail05.vgs.untd.com> <499F0DEE.7090107@gmail.com> <833718.32681.qm@web59103.mail.re1.yahoo.com> Date: Sat, 21 Feb 2009 00:18:53 +0000 Message-ID: <61dbdd7d0902201618y2ace079fyf0337f62d9ff1a7@mail.gmail.com> From: Gareth Nelson To: Ann Otoole Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:18:39 -0000 I made a post about this under the "If I make make a few assumptions" thread. Let's put it quite clearly, it's fine to add metadata to the standards, and include any of your DRM flags within that metadata, but putting DRM itself as part of the standard is no good. A bigger question should be, "should we standardise the flags within the metadata?" for those worlds that do want to implement DRM measures. This list isn't the place to express our views on DRM, but it is the right place to ask about what formats we should use for metadata fields. On Fri, Feb 20, 2009 at 9:22 PM, Ann Otoole wrote: > The first order of business should be to set up a metadata repository that > commences with at least two top level topics of Legal and Technical. Under > Legal would come the interests pertaining to intellectual property. The > child elements can have pointers intermixed while the metadata is fully > fleshed out under it's main elements. The technical implementation aspects > of the various elements is a ways down the road as I see it. > > ________________________________ > From: Jon Watte > To: "dyerbrookme@juno.com" ; "mmox@ietf.org" > > Sent: Friday, February 20, 2009 3:09:18 PM > Subject: [mmox] Content metadata through interoperability > > dyerbrookme@juno.com wrote: >> You're assuming that Linden Lab simply won't let pass through its gates an >> object that is not marked for transfer. But Linden Lab's entire world has >> been reverse-engineered in > > You seem to be having a beef with Linden Labs. It seems like you don't trust > Linden Labs to actually enforce any policy that would be specified in an > interoperability standard. Surely there are more appropriate forums for you > to discuss these Second Life specific things with Linden Labs people. > > I think a rule of thumb for /this particular list/ should be that if the > issue discussed is not applicable at least to eight different technology > vendors (for example: Multiverse, Kaneva, Areae, Forterra, Linden Labs, > Qwaq, Second Life and OpenSim), then it doesn't belong on this list. > > >>> In fact, I am arguing that we should enable exactly what you're >> describing! I don't understand how you belive I'm not. >> >> I think it's very simple: you have to clarify whether you are for putting >> copy/mod/transfer permissions on objects or not. >> > > I believe I have clearly stated that it is my position that all content > should contain metadata, and one piece of that metadata is > copy/reuse/cache/storage rights. The specific forms of those > copy/reuse/cache/storage may be c/m/t, or more likely something a little > richer to cater for situations like copylefted content that has "sticky" > semantics. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From gareth@litesim.com Fri Feb 20 16:23:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372EC28C20A for ; Fri, 20 Feb 2009 16:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk23xrdkS97a for ; Fri, 20 Feb 2009 16:23:45 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 49CA828C18A for ; Fri, 20 Feb 2009 16:23:45 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so1051500rvb.5 for ; Fri, 20 Feb 2009 16:23:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.137.8 with SMTP id p8mr676054rvn.27.1235175839729; Fri, 20 Feb 2009 16:23:59 -0800 (PST) In-Reply-To: <61dbdd7d0902201618y2ace079fyf0337f62d9ff1a7@mail.gmail.com> References: <20090220.134403.24682.0@webmail05.vgs.untd.com> <499F0DEE.7090107@gmail.com> <833718.32681.qm@web59103.mail.re1.yahoo.com> <61dbdd7d0902201618y2ace079fyf0337f62d9ff1a7@mail.gmail.com> Date: Sat, 21 Feb 2009 00:23:59 +0000 Message-ID: <61dbdd7d0902201623h467a98acwd8a218a4fed3d46e@mail.gmail.com> From: Gareth Nelson To: Ann Otoole Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:23:46 -0000 To clarify, do we want the SL-style "copy/modify/transfer" only, or do we want a more general framework and how would that more general framework work? SL-like perms of course have their flaws, so we can't assume them to be universal. One approach i've seen to this (thanks Adam) is a domain-specific language to describe permissions: http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/ I know for myself, the current permissions in SL are inadequate, since I can't release something with "no no modify, no no copy, no no transfer" (i.e basic GPL) permissions and people far too easily slap no copy and no modify on top of stuff. On Sat, Feb 21, 2009 at 12:18 AM, Gareth Nelson wrote: > I made a post about this under the "If I make make a few assumptions" > thread. Let's put it quite clearly, it's fine to add metadata to the > standards, and include any of your DRM flags within that metadata, but > putting DRM itself as part of the standard is no good. > > A bigger question should be, "should we standardise the flags within > the metadata?" for those worlds that do want to implement DRM > measures. This list isn't the place to express our views on DRM, but > it is the right place to ask about what formats we should use for > metadata fields. > > On Fri, Feb 20, 2009 at 9:22 PM, Ann Otoole wrote: >> The first order of business should be to set up a metadata repository that >> commences with at least two top level topics of Legal and Technical. Under >> Legal would come the interests pertaining to intellectual property. The >> child elements can have pointers intermixed while the metadata is fully >> fleshed out under it's main elements. The technical implementation aspects >> of the various elements is a ways down the road as I see it. >> >> ________________________________ >> From: Jon Watte >> To: "dyerbrookme@juno.com" ; "mmox@ietf.org" >> >> Sent: Friday, February 20, 2009 3:09:18 PM >> Subject: [mmox] Content metadata through interoperability >> >> dyerbrookme@juno.com wrote: >>> You're assuming that Linden Lab simply won't let pass through its gates an >>> object that is not marked for transfer. But Linden Lab's entire world has >>> been reverse-engineered in >> >> You seem to be having a beef with Linden Labs. It seems like you don't trust >> Linden Labs to actually enforce any policy that would be specified in an >> interoperability standard. Surely there are more appropriate forums for you >> to discuss these Second Life specific things with Linden Labs people. >> >> I think a rule of thumb for /this particular list/ should be that if the >> issue discussed is not applicable at least to eight different technology >> vendors (for example: Multiverse, Kaneva, Areae, Forterra, Linden Labs, >> Qwaq, Second Life and OpenSim), then it doesn't belong on this list. >> >> >>>> In fact, I am arguing that we should enable exactly what you're >>> describing! I don't understand how you belive I'm not. >>> >>> I think it's very simple: you have to clarify whether you are for putting >>> copy/mod/transfer permissions on objects or not. >>> >> >> I believe I have clearly stated that it is my position that all content >> should contain metadata, and one piece of that metadata is >> copy/reuse/cache/storage rights. The specific forms of those >> copy/reuse/cache/storage may be c/m/t, or more likely something a little >> richer to cater for situations like copylefted content that has "sticky" >> semantics. >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > From jwatte@gmail.com Fri Feb 20 16:25:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09CC28C20A for ; Fri, 20 Feb 2009 16:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thZ1A7-z4FQ2 for ; Fri, 20 Feb 2009 16:25:12 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id AC6983A68F9 for ; Fri, 20 Feb 2009 16:25:11 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so600981ana.4 for ; Fri, 20 Feb 2009 16:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=VVB7M3E9b7zp2kWLGpmlPxwGM+okXHeIvkgk0Tiydv0=; b=R+8G2P9o0UPrl022zNLVnnt5ZYy1kU3UtT/Ms6IL+VOWM/PRpdZFpILCUTzea/ZV35 m3/5p9HIVLfW6id/S+t6o19JNsOCZBnmMKdI6jjQPzjii5g435IdLsTQNmGxwVSY7fuD 9NipyWoAucnwy8e3a/jqIPEMFLBCTja2L0efc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZRfBydQ4Dnj1A59+VRqlp97YyR6CehRUsrrYT0kRafm/LUfzvKvnolowL/Dps7hDiL eUD00PkmajfEoKWTtEl6I9JCEsdvQmSW4omRXiiu2BAvHK7EoTRWEIGJmcKCHvltzqaq +bPplsTWwAtGiiuoJUDi+ccWAEKXT/U6ase7A= Received: by 10.100.210.9 with SMTP id i9mr2161526ang.36.1235175925776; Fri, 20 Feb 2009 16:25:25 -0800 (PST) Received: from ?192.168.168.110? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d22sm4061894and.47.2009.02.20.16.25.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 16:25:25 -0800 (PST) Message-ID: <499F49F3.7050508@gmail.com> Date: Fri, 20 Feb 2009 16:25:23 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kajikawa Jeremy References: <20090220.134403.24682.0@webmail05.vgs.untd.com> <499F0DEE.7090107@gmail.com> <833718.32681.qm@web59103.mail.re1.yahoo.com> <2FC34C0A-AC59-465C-9BB1-E01339EC35A8@lindenlab.com> <34264.99944.qm@web59104.mail.re1.yahoo.com> <1235175079.7560.172.camel@localhost> In-Reply-To: <1235175079.7560.172.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:25:24 -0000 Kajikawa Jeremy wrote: > I would agree about the multiple-presence by permissive authorizations > across > servers and the appearance of an AV being different per-grid. > > If you can't keep your appearance when you go to another place, then what good is it? I might as well just register a new avatar for the new place. One of the whole points of interoperability is the transportability of my identity (visual, kinetic, and otherwise). Is the concern here that some world may develop avatar meshes that they do wish for their own paying customers to be able to see on their client machines, but they do not wish friends of the paying customers, using other client machines, to be able to see those meshes? In that case, couldn't those world operators simply provide the generic meshes when asked for the interoperable mesh and texture set for a given user? > If someone makes a "Clan of the Cave bear" environment and someone walks > in > from playing on an UT2003 or UT2009 server and keeps the AV... > it would be too anacronistic to explain away if they are part of the > "tribe" in each. > > If some world wants to enforce a dress code, I think they can, but by default, I don't think it should be designed into or required by the standard. Compare real life: you can put on your biker gear, not wash for a week, and then walk into an investment bank. You will feel pretty out of place, just like the UT2003 guy in the Cave Bear environment. Whether the investment bankers actually throw you out, probably depends more on what you're doing in their office, than what your clothing is. Sincerely, jw From lenglish5@cox.net Fri Feb 20 16:38:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06BF3A6AF9 for ; Fri, 20 Feb 2009 16:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVFa2tBqS01k for ; Fri, 20 Feb 2009 16:38:12 -0800 (PST) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id A5E113A68F9 for ; Fri, 20 Feb 2009 16:38:12 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090221003824.UMYO12540.fed1rmmtao106.cox.net@fed1rmimpo03.cox.net>; Fri, 20 Feb 2009 19:38:24 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id JQeR1b0054N6T0Q04QeRTT; Fri, 20 Feb 2009 19:38:25 -0500 X-Authority-Analysis: v=1.0 c=1 a=dJZNl1pbwy4A:10 a=aNmmtEIUWqEA:10 a=Wajolswj7cQA:10 a=LpB1zSSiHsnA21QlNhcA:9 a=JTzL449nCOXZPtZME3ox6coKKUwA:4 a=6UxOEEjT9BUA:10 a=059jtadoKCeW9wGd:21 a=QKkdkoxl57F1hcEr:21 X-CM-Score: 0.00 Message-ID: <499F4D01.1010109@cox.net> Date: Fri, 20 Feb 2009 17:38:25 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gareth Nelson References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> <61dbdd7d0902201612i415f8f0i5be70c164d5412e7@mail.gmail.com> In-Reply-To: <61dbdd7d0902201612i415f8f0i5be70c164d5412e7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:38:14 -0000 Gareth Nelson wrote: >> Tightly coupling the MSP and identity provider functions is why I have to >> keep telling people that Mark McCahill is named Mysterio Sinister in Second >> Life - I can't easily be mccahill@duke.edu because Second Life doesn't use >> external federated identity providers. Then when I go to one of the OpenSim >> worlds, I need to create another account, and hope that nobody has signed up >> for Mysterio Sinister before I got there. >> > > Correct me if i'm wrong, but isn't this the problem the OGP agent > domain was designed to resolve? > I propose an agent domain which itself allows multiple methods of authentication > Authentication itself was left pretty much under-defined to this point in that OGP, with the assumption that different agent domains might have different authentication schemes. Another thing to keep in mind is that, regarding IP issues, different girds/worlds might have different standards for what is an acceptable authentication scheme. L From jwatte@gmail.com Fri Feb 20 17:00:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F14228C17C for ; Fri, 20 Feb 2009 17:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSJOquSrMU1E for ; Fri, 20 Feb 2009 17:00:05 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id B06C93A6A10 for ; Fri, 20 Feb 2009 17:00:04 -0800 (PST) Received: by gxk22 with SMTP id 22so3199580gxk.13 for ; Fri, 20 Feb 2009 17:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2Yhi1tPJ+HVXKMxQIFx9ge6pP0x5mM/hSkXRdItBU04=; b=BqP3KWT144FOBFvSduEAk2nS8mpJDlDVmMpe8ptj/AabQ4/IT/T5K+jpkbVoAZYj3t chZZQCnYdLnLbEF5bOIBDZrxxh/jIj/cqB62iYDIYV8vPqVu66xjDzvzTRIU8L8N2Cxm dMGhEc4AAGJn/u50Umaqn/f9lg73pAYbZo/ks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=KvQ+alwljgIOTAWznN9L9kRRccQo5NMjiW4GGqhchPixVtDyxv/qHO3zpVlKos9Gj1 XA83dOVwUrMUT08QManjz+H+Zt/VkgznEwnm9gMeGlosTn00t7TbXYHEG9kAl4fR4AYF NdaiX3/c0eAAikPzmeWfR1gsX2XCA4Oa0DS4k= Received: by 10.100.133.2 with SMTP id g2mr2102008and.134.1235178018867; Fri, 20 Feb 2009 17:00:18 -0800 (PST) Received: from ?192.168.168.110? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c23sm6913940ana.52.2009.02.20.17.00.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 17:00:18 -0800 (PST) Message-ID: <499F5220.5010207@gmail.com> Date: Fri, 20 Feb 2009 17:00:16 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke , "mmox@ietf.org" References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> In-Reply-To: <244573.52942.qm@web82607.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 01:00:06 -0000 Charles Krinke wrote: > Well, are we going to find that each virtual world is unwilling accept > any of any other virtual worlds technical decisions? Unfortunately, > that is the impression I get from this. > > This reminds me of the Beta vs VHS history. Beta was argued to be the > technically superior technology (and it actually was), but so many > folks adopted the VHS technology that Beta faded into obscurity. The > point being that the superior technology is trumped by the market's > adoption of any particular technology. > > So, we can spend our time arguing that *our* technology is the > *superior* one and never give an inch. Or, alternatively, we can > figure out some way to work together. Great points! I have never intended that the OLIVE base technology be the basis for interoperability. Instead, I have over several years done a fairly large survey of various virtual world technologies, and of what's worked before, to come up with a "common denominator" type approach to how virtual world interoperability can actually be made to work. This is a design from first principles, if you will. That is what I'm arguing for here. By contrast, OGP seems like it is a mixture of things that came out from the SL AWG, motivated by what was easier to implement on top of existing SL-specific technology, plus removing specificity in certain cases, which leads to a protocol that is both not a good "common denominator" for the entire industry, and not declarative enough to enable "from scratch" interoperability by just reading the protocol specification and implementing it. That's what I have against it -- merits, not sources. Here are a few ground rules that I have come to conclude will be necessary for wide acceptance: - User identity is provided by an identity provider, which may be the "home" world of the user, or some other provider. Users should not need identity tied to the specific world they want to visit. Some worlds may choose to not accept certain specific credentials, just like certain real-world stores may not accept Candian dollars for payment. The market will work out a few major credential systems in the end (such as OpenID, perhaps). As long as each system is accessed uniformly, the specifics of the back end don't matter. - Geometry is based on regular meshes, possibly with LOD switches and lower-resolution physics meshes/proxies/hulls. I understand that this may be a sticking point for the SL-derived worlds (or do they actually support arbitrary meshes as an option now? I haven't kept up.) - Texturing is based on a regular Phong model with various defined texture maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on their own). Turns out, once you have the possibility of gloss maps, normal maps, emission maps, opacity maps, diffuse maps and ambient maps, you have 90% of the "look" of any one technology, which is about as good as you can hope for through interoperability. - Telemetry (entity movement) needs to be sent on a position/orientation/velocity basis, with dead reckoning. Delta compression and lower update rates can be used to keep bandwidth usage in check. This is a big difference for OLIVE, because we are input-synchronous, similar to City of Heroes or Age of Empires. However, again, this is the common denominator and experience speaking. - Animating objects need to use a common, widespread interchange format, using named animation clips and skeletal animation. Morph deformation is likely too big a payload to make sense, at least in the early stages. COLLADA is a good format for this, but there are other possibilities (FBX, X3D and X come to mind). I think that making at least one format required is a good idea, because that ensures a minimum level of interoperability is always present. - Simulation and script execution for a given object needs to be done on the "home" system for that object, because objects may be constructed assuming wildly disparate execution environments (X3D with JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, etc). - Objects need to be marked up with simple, well defined possible interactions, so that a user interface can be generated on each client based on those interactions. Interactions are typically "set this property to this value" or "execute this command." Such interactions need to be forwarded to the server that runs the object in question. Similarly, specific interactions ("emote animation," "collision," "damage," "two-party animation," "flight" etc) need to be defined. - Non-time-critical requests should go over HTTP and/or HTTPS, using XML-RPC or a similarly well understood protocol. - Time-critical and high-bandwidth data (such as entity telemetry and user inputs) should be sent using explicit (separate) schema, and binary representation, for the same reason that we don't send streaming video as XML, or mark each pixel with a color space identifier. Note that the majority of those ground rules are actually not how OLIVE (or Second Life, or Kaneva, or any one other system) works internally. That's fine -- these rules are designed to be as easy as possible to translate to each participating system, while still being rich enough to provide useful interoperability. Now, I would appreciate it if we could take these points, and argue the necessity or not of each of the points, with concrete examples that each apply to at least two world technologies. Similarly, if I have somehow mis-understood something, and OGP actually provides for all of these points, I'd like to be made aware of what my misunderstandings are so I can correct them! Sincerely, jw From missannotoole@yahoo.com Fri Feb 20 17:25:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B15A3A6895 for ; Fri, 20 Feb 2009 17:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyKyBWowfEvt for ; Fri, 20 Feb 2009 17:25:22 -0800 (PST) Received: from web59107.mail.re1.yahoo.com (web59107.mail.re1.yahoo.com [66.196.101.18]) by core3.amsl.com (Postfix) with SMTP id 391583A67A5 for ; Fri, 20 Feb 2009 17:25:17 -0800 (PST) Received: (qmail 86640 invoked by uid 60001); 21 Feb 2009 01:25:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1235179532; bh=p7q/MqS73lD4LlGKKRbqV8IStK0lxTe1cS9Jc88gxIM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=m1TVhmJrQkPRwz6ZHd1q0JOCQR8hqRc/FlCFciqBkKdBgXN+xxbTQ9oZVqUlTtydEtLNGE/ZBNDQ3GXh5ZwSz/orU1urDpsRD6ZUK0Sts9vQDUqXeGyhGJX5w9QjtpEEhhIei3rQV+iV5KBsx96k81Z4nLJDEmmMpCjL6Pb0Sjc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=T0DFihyJDPGKQmuuMLtekVscoCkimhTeI5RiaHQOjp144op/RF63fNxuFTzpKU/j+zcO4RBtCGAuXTGnhTgqIQ1YgMX8hy3lFDVXu8miFhn+bZo59DCnb2rBFKnU+oDjpv+lwT6jQjM6QO7fMkcAxJKPD8ycYF6KvaLam8zilpM=; Message-ID: <595052.19104.qm@web59107.mail.re1.yahoo.com> X-YMail-OSG: vQtD3K8VM1nTScTWm_oOWS_c0VadZrbx3lrTSwKPD2_IGCliG9fXvO1jLEL1EmIREowUDIHB..qqiHv10NqtUJ3Nv_8ibbyolNhE1tuYsqJPjEATquW3v1eP.AhfiHETfVwjj3ZFmUAb7In1PYvAyQYR6Glg7S6ZMjlbE2XrunoPf7X4uYCnqg7TqzIoN5BDjz.dQQs9Bb8cOZ6.yxa33d4GQ6Y2wtHoOxCTqtwJKcKUM3k- Received: from [97.102.254.236] by web59107.mail.re1.yahoo.com via HTTP; Fri, 20 Feb 2009 17:25:32 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> Date: Fri, 20 Feb 2009 17:25:32 -0800 (PST) From: Ann Otoole To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-483616444-1235179532=:19104" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 01:25:30 -0000 --0-483616444-1235179532=:19104 Content-Type: text/plain; charset=us-ascii ODBC works for databases. (yes some of you cringed at the sight of that acronym but it does serve the example purpose) ODBC was the reason I was able to construct a heterogeneous database hub in a simplistic manner that did not cause any of the target databases to have to support anything beyond a connection with the rights necessary to collect the data required at the time it was required. Therefore I was able to build the hub in a manner that did not cause any additional cost overhead by the various database teams. Oracle, SQL Server, Informix, DB2, and even some wretched access data file "databases" were supported simultaneously. Why can't (or wouldn't) there be the necessary adapter/plug in approach used that accommodates the portions a world can accommodate? If your world will support OLIVE, Croqet, and SL then your world's equivalent of a presence system has those adapters a client can connect to on their respective ports. If all worlds are to be supported then all plugins are availableon a respective port. This approach allows for newer or as yet undiscovered "worlds" to become part of the universe if they develop the necessary open grid data connectivity adapter. Jon's list goes beyond what might be required for a data transmission format standard since once the necessary data is transferred to render then, as Jon pointed out, the positional data streaming uses a different format which also needs to be defined. If a data conversion adapter strategy is used then how a client renders is irrelevant if the data for rendering has been converted to the local rendering system's requirements. Once in then the local world's rules apply as far as everything else goes. The scripting aspect is interesting in all this. A question begging for attention is poorly writtten scripts and whether or not you even want them entering your world space. Thus why my first contribution to the list suggested use of real meshes and supporting texture bakes and absence of any SL style attachments. So Jon's list is a good start for hammering out data translation schemas. This is actually where mailing lists start to be a bummer since we can't actually "see" the various avatar entity skeletons and their differences in a common medium. I'm not sure every world will open source their systems so we can even see this information for all worlds either. ________________________________ From: Jon Watte To: Charles Krinke ; "mmox@ietf.org" Sent: Friday, February 20, 2009 8:00:16 PM Subject: Re: [mmox] Learning from the past; focusing on the future Charles Krinke wrote: > Well, are we going to find that each virtual world is unwilling accept any of any other virtual worlds technical decisions? Unfortunately, that is the impression I get from this. > > This reminds me of the Beta vs VHS history. Beta was argued to be the technically superior technology (and it actually was), but so many folks adopted the VHS technology that Beta faded into obscurity. The point being that the superior technology is trumped by the market's adoption of any particular technology. > > So, we can spend our time arguing that *our* technology is the *superior* one and never give an inch. Or, alternatively, we can figure out some way to work together. Great points! I have never intended that the OLIVE base technology be the basis for interoperability. Instead, I have over several years done a fairly large survey of various virtual world technologies, and of what's worked before, to come up with a "common denominator" type approach to how virtual world interoperability can actually be made to work. This is a design from first principles, if you will. That is what I'm arguing for here. By contrast, OGP seems like it is a mixture of things that came out from the SL AWG, motivated by what was easier to implement on top of existing SL-specific technology, plus removing specificity in certain cases, which leads to a protocol that is both not a good "common denominator" for the entire industry, and not declarative enough to enable "from scratch" interoperability by just reading the protocol specification and implementing it. That's what I have against it -- merits, not sources. Here are a few ground rules that I have come to conclude will be necessary for wide acceptance: - User identity is provided by an identity provider, which may be the "home" world of the user, or some other provider. Users should not need identity tied to the specific world they want to visit. Some worlds may choose to not accept certain specific credentials, just like certain real-world stores may not accept Candian dollars for payment. The market will work out a few major credential systems in the end (such as OpenID, perhaps). As long as each system is accessed uniformly, the specifics of the back end don't matter. - Geometry is based on regular meshes, possibly with LOD switches and lower-resolution physics meshes/proxies/hulls. I understand that this may be a sticking point for the SL-derived worlds (or do they actually support arbitrary meshes as an option now? I haven't kept up.) - Texturing is based on a regular Phong model with various defined texture maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on their own). Turns out, once you have the possibility of gloss maps, normal maps, emission maps, opacity maps, diffuse maps and ambient maps, you have 90% of the "look" of any one technology, which is about as good as you can hope for through interoperability. - Telemetry (entity movement) needs to be sent on a position/orientation/velocity basis, with dead reckoning. Delta compression and lower update rates can be used to keep bandwidth usage in check. This is a big difference for OLIVE, because we are input-synchronous, similar to City of Heroes or Age of Empires. However, again, this is the common denominator and experience speaking. - Animating objects need to use a common, widespread interchange format, using named animation clips and skeletal animation. Morph deformation is likely too big a payload to make sense, at least in the early stages. COLLADA is a good format for this, but there are other possibilities (FBX, X3D and X come to mind). I think that making at least one format required is a good idea, because that ensures a minimum level of interoperability is always present. - Simulation and script execution for a given object needs to be done on the "home" system for that object, because objects may be constructed assuming wildly disparate execution environments (X3D with JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, etc). - Objects need to be marked up with simple, well defined possible interactions, so that a user interface can be generated on each client based on those interactions. Interactions are typically "set this property to this value" or "execute this command." Such interactions need to be forwarded to the server that runs the object in question. Similarly, specific interactions ("emote animation," "collision," "damage," "two-party animation," "flight" etc) need to be defined. - Non-time-critical requests should go over HTTP and/or HTTPS, using XML-RPC or a similarly well understood protocol. - Time-critical and high-bandwidth data (such as entity telemetry and user inputs) should be sent using explicit (separate) schema, and binary representation, for the same reason that we don't send streaming video as XML, or mark each pixel with a color space identifier. Note that the majority of those ground rules are actually not how OLIVE (or Second Life, or Kaneva, or any one other system) works internally. That's fine -- these rules are designed to be as easy as possible to translate to each participating system, while still being rich enough to provide useful interoperability. Now, I would appreciate it if we could take these points, and argue the necessity or not of each of the points, with concrete examples that each apply to at least two world technologies. Similarly, if I have somehow mis-understood something, and OGP actually provides for all of these points, I'd like to be made aware of what my misunderstandings are so I can correct them! Sincerely, jw _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-483616444-1235179532=:19104 Content-Type: text/html; charset=us-ascii
ODBC works for databases. (yes some of you cringed at the sight of that acronym but it does serve the example purpose)
ODBC was the reason I was able to construct a heterogeneous database hub in a simplistic manner that did not cause any of the target databases to have to support anything beyond a connection with the rights necessary to collect the data required at the time it was required. Therefore I was able to build the hub in a manner that did not cause any additional cost overhead by the various database teams. Oracle, SQL Server, Informix, DB2, and even some wretched access data file "databases" were supported simultaneously.

Why can't (or wouldn't) there be the necessary adapter/plug in approach used that accommodates the portions a world can accommodate? If your world will support OLIVE, Croqet, and SL then your world's equivalent of a presence system has those adapters a client can connect to on their respective ports. If all worlds are to be supported then all plugins are availableon a respective port. This approach allows for newer or as yet undiscovered "worlds" to become part of the universe if they develop the necessary open grid data connectivity adapter.

Jon's list goes beyond what might be required for a data transmission format standard since once the necessary data is transferred to render then, as Jon pointed out, the positional data streaming uses a different format which also needs to be defined. If a data conversion adapter strategy is used then how a client renders is irrelevant if the data for rendering has been converted to the local rendering system's requirements. Once in then the local world's rules apply as far as everything else goes. The scripting aspect is interesting in all this. A question begging for attention is poorly writtten scripts and whether or not you even want them entering your world space. Thus why my first contribution to the list suggested use of real meshes and supporting texture bakes and absence of any SL style attachments.

So Jon's list is a good start for hammering out data translation schemas.
This is actually where mailing lists start to be a bummer since we can't actually "see" the various avatar entity skeletons and their differences in a common medium.
I'm not sure every world will open source their systems so we can even see this information for all worlds either.

From: Jon Watte <jwatte@gmail.com>
To: Charles Krinke <cfk@pacbell.net>; "mmox@ietf.org" <mmox@ietf.org>
Sent: Friday, February 20, 2009 8:00:16 PM
Subject: Re: [mmox] Learning from the past; focusing on the future

Charles Krinke wrote:
> Well, are we going to find that each virtual world is unwilling accept any of any other virtual worlds technical decisions? Unfortunately, that is the impression I get from this.
>
> This reminds me of the Beta vs VHS history. Beta was argued to be the technically superior technology (and it actually was), but so many folks adopted the VHS technology that Beta faded into obscurity. The point being that the superior technology is trumped by the market's adoption of any particular technology.
>
> So, we can spend our time arguing that *our* technology is the *superior* one and never give an inch. Or, alternatively, we can figure out some way to work together.

Great points!

I have never intended that the OLIVE base technology be the basis for interoperability. Instead, I have over several years done a fairly large survey of various virtual world technologies, and of what's worked before, to come up with a "common denominator" type approach to how virtual world interoperability can actually be made to work. This is a design from first principles, if you will. That is what I'm arguing for here.

By contrast, OGP seems like it is a mixture of things that came out from the SL AWG, motivated by what was easier to implement on top of existing SL-specific technology, plus removing specificity in certain cases, which leads to a protocol that is both not a good "common denominator" for the entire industry, and not declarative enough to enable "from scratch" interoperability by just reading the protocol specification and implementing it. That's what I have against it -- merits, not sources.


Here are a few ground rules that I have come to conclude will be necessary for wide acceptance:

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

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

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

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

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

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

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

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

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


Note that the majority of those ground rules are actually not how OLIVE (or Second Life, or Kaneva, or any one other system) works internally. That's fine -- these rules are designed to be as easy as possible to translate to each participating system, while still being rich enough to provide useful interoperability.

Now, I would appreciate it if we could take these points, and argue the necessity or not of each of the points, with concrete examples that each apply to at least two world technologies. Similarly, if I have somehow mis-understood something, and OGP actually provides for all of these points, I'd like to be made aware of what my misunderstandings are so I can correct them!

Sincerely,

jw

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox

--0-483616444-1235179532=:19104-- From cfk@pacbell.net Fri Feb 20 18:00:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B89993A6816 for ; Fri, 20 Feb 2009 18:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwdzAoWzYX8G for ; Fri, 20 Feb 2009 18:00:07 -0800 (PST) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id 119ED3A6403 for ; Fri, 20 Feb 2009 18:00:07 -0800 (PST) Received: (qmail 62458 invoked by uid 60001); 21 Feb 2009 02:00:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=OvW/hwvPNS2BOzo02dTQf0VSizgQ8MnWl902SHkYgwx+J/mZ9wBMKT3PoKJwRfsBjGpNSVs27gCKkdZw7rrza3Rmum/SxfdGQnhCMlB5/bUlkwoR5UVNrZ7Q9AvxeQcIT1lCbnvP8HqceHu+pXM73iRNsdKy9WAN5x4D3F6SkIU=; X-YMail-OSG: cb4aZs4VM1m8RD9WXsyCBjpGGO1QYPDSX4fIjOux2ONN1zoWM_g3F446jLjrMTKsehY2DgMGW7DwDGYzr2J1dE6o0nc_Cv.wnpSFQCTcHFd7rwWzoi2UN7QqB5MtcD0DfDKbjpwWCD36cfVNCFVP3LF8JmL0hSjytk9HRhpDowiqS4ueZpuLuQuAySxCi3hOL3tab9UBYEP33M9lu60U1EcQirk- Received: from [67.120.11.69] by web82607.mail.mud.yahoo.com via HTTP; Fri, 20 Feb 2009 18:00:20 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> Date: Fri, 20 Feb 2009 18:00:20 -0800 (PST) From: Charles Krinke To: Jon Watte , "mmox@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-227361953-1235181620=:52772" Message-ID: <873917.52772.qm@web82607.mail.mud.yahoo.com> Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 02:00:08 -0000 --0-227361953-1235181620=:52772 Content-Type: text/plain; charset=us-ascii Well, I think the place we are at is that neither SecondLife, nor OpenSim, nor Fortrerra is likely to substantially change their sim architecture. In this particular case, OpenSim is using OGP and is using HyperGrid. Both work. Both are continuing to be developed. So this is not a theoretical discussion, but rather both are actual implementations which are deployed. So, to me, the debate about creating a new architecture is somewhat moot. I would say the way we can make progress is to accept that we all have ongoing projects and see if there is a way to define a charter for this working group to define interop between existing architectures (and future architectures) as we move forward. As I look at this whole thing, my hope for it is see a minimal number of changes to our client<->sim communication in order to keep compatibility with SecondLife and hopefully add interop compatibility with Croquet, Wonderland, perhaps Fortrerra, and others. Charles Krinke ________________________________ From: Jon Watte To: Charles Krinke ; "mmox@ietf.org" Sent: Friday, February 20, 2009 5:00:16 PM Subject: Re: Learning from the past; focusing on the future Charles Krinke wrote: > Well, are we going to find that each virtual world is unwilling accept any of any other virtual worlds technical decisions? Unfortunately, that is the impression I get from this. > > This reminds me of the Beta vs VHS history. Beta was argued to be the technically superior technology (and it actually was), but so many folks adopted the VHS technology that Beta faded into obscurity. The point being that the superior technology is trumped by the market's adoption of any particular technology. > > So, we can spend our time arguing that *our* technology is the *superior* one and never give an inch. Or, alternatively, we can figure out some way to work together. Great points! I have never intended that the OLIVE base technology be the basis for interoperability. Instead, I have over several years done a fairly large survey of various virtual world technologies, and of what's worked before, to come up with a "common denominator" type approach to how virtual world interoperability can actually be made to work. This is a design from first principles, if you will. That is what I'm arguing for here. By contrast, OGP seems like it is a mixture of things that came out from the SL AWG, motivated by what was easier to implement on top of existing SL-specific technology, plus removing specificity in certain cases, which leads to a protocol that is both not a good "common denominator" for the entire industry, and not declarative enough to enable "from scratch" interoperability by just reading the protocol specification and implementing it. That's what I have against it -- merits, not sources. Here are a few ground rules that I have come to conclude will be necessary for wide acceptance: - User identity is provided by an identity provider, which may be the "home" world of the user, or some other provider. Users should not need identity tied to the specific world they want to visit. Some worlds may choose to not accept certain specific credentials, just like certain real-world stores may not accept Candian dollars for payment. The market will work out a few major credential systems in the end (such as OpenID, perhaps). As long as each system is accessed uniformly, the specifics of the back end don't matter. - Geometry is based on regular meshes, possibly with LOD switches and lower-resolution physics meshes/proxies/hulls. I understand that this may be a sticking point for the SL-derived worlds (or do they actually support arbitrary meshes as an option now? I haven't kept up.) - Texturing is based on a regular Phong model with various defined texture maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on their own). Turns out, once you have the possibility of gloss maps, normal maps, emission maps, opacity maps, diffuse maps and ambient maps, you have 90% of the "look" of any one technology, which is about as good as you can hope for through interoperability. - Telemetry (entity movement) needs to be sent on a position/orientation/velocity basis, with dead reckoning. Delta compression and lower update rates can be used to keep bandwidth usage in check. This is a big difference for OLIVE, because we are input-synchronous, similar to City of Heroes or Age of Empires. However, again, this is the common denominator and experience speaking. - Animating objects need to use a common, widespread interchange format, using named animation clips and skeletal animation. Morph deformation is likely too big a payload to make sense, at least in the early stages. COLLADA is a good format for this, but there are other possibilities (FBX, X3D and X come to mind). I think that making at least one format required is a good idea, because that ensures a minimum level of interoperability is always present. - Simulation and script execution for a given object needs to be done on the "home" system for that object, because objects may be constructed assuming wildly disparate execution environments (X3D with JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, etc). - Objects need to be marked up with simple, well defined possible interactions, so that a user interface can be generated on each client based on those interactions. Interactions are typically "set this property to this value" or "execute this command." Such interactions need to be forwarded to the server that runs the object in question. Similarly, specific interactions ("emote animation," "collision," "damage," "two-party animation," "flight" etc) need to be defined. - Non-time-critical requests should go over HTTP and/or HTTPS, using XML-RPC or a similarly well understood protocol. - Time-critical and high-bandwidth data (such as entity telemetry and user inputs) should be sent using explicit (separate) schema, and binary representation, for the same reason that we don't send streaming video as XML, or mark each pixel with a color space identifier. Note that the majority of those ground rules are actually not how OLIVE (or Second Life, or Kaneva, or any one other system) works internally. That's fine -- these rules are designed to be as easy as possible to translate to each participating system, while still being rich enough to provide useful interoperability. Now, I would appreciate it if we could take these points, and argue the necessity or not of each of the points, with concrete examples that each apply to at least two world technologies. Similarly, if I have somehow mis-understood something, and OGP actually provides for all of these points, I'd like to be made aware of what my misunderstandings are so I can correct them! Sincerely, jw --0-227361953-1235181620=:52772 Content-Type: text/html; charset=us-ascii
Well, I think the place we are at is that neither SecondLife, nor OpenSim, nor Fortrerra is likely to substantially change their sim architecture. In this particular case, OpenSim is using OGP and is using HyperGrid. Both work. Both are continuing to be developed. So this is not a theoretical discussion, but rather both are actual implementations which are deployed.

So, to me, the debate about creating a new architecture is somewhat moot.

I would say the way we can make progress is to accept that we all have ongoing projects and see if there is a way to define a charter for this working group to define interop between existing architectures (and future architectures) as we move forward.

As I look at this whole thing, my hope for it is see a minimal number of changes to our client<->sim communication in order to keep compatibility with SecondLife and hopefully add interop compatibility with Croquet, Wonderland, perhaps Fortrerra, and others.

Charles Krinke

From: Jon Watte <jwatte@gmail.com>
To: Charles Krinke <cfk@pacbell.net>; "mmox@ietf.org" <mmox@ietf.org>
Sent: Friday, February 20, 2009 5:00:16 PM
Subject: Re: Learning from the past; focusing on the future

Charles Krinke wrote:
> Well, are we going to find that each virtual world is unwilling accept any of any other virtual worlds technical decisions? Unfortunately, that is the impression I get from this.
>
> This reminds me of the Beta vs VHS history. Beta was argued to be the technically superior technology (and it actually was), but so many folks adopted the VHS technology that Beta faded into obscurity. The point being that the superior technology is trumped by the market's adoption of any particular technology.
>
> So, we can spend our time arguing that *our* technology is the *superior* one and never give an inch. Or, alternatively, we can figure out some way to work together.

Great points!

I have never intended that the OLIVE base technology be the basis for interoperability. Instead, I have over several years done a fairly large survey of various virtual world technologies, and of what's worked before, to come up with a "common denominator" type approach to how virtual world interoperability can actually be made to work. This is a design from first principles, if you will. That is what I'm arguing for here.

By contrast, OGP seems like it is a mixture of things that came out from the SL AWG, motivated by what was easier to implement on top of existing SL-specific technology, plus removing specificity in certain cases, which leads to a protocol that is both not a good "common denominator" for the entire industry, and not declarative enough to enable "from scratch" interoperability by just reading the protocol specification and implementing it. That's what I have against it -- merits, not sources.


Here are a few ground rules that I have come to conclude will be necessary for wide acceptance:

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

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

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

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

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

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

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

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

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


Note that the majority of those ground rules are actually not how OLIVE (or Second Life, or Kaneva, or any one other system) works internally. That's fine -- these rules are designed to be as easy as possible to translate to each participating system, while still being rich enough to provide useful interoperability.

Now, I would appreciate it if we could take these points, and argue the necessity or not of each of the points, with concrete examples that each apply to at least two world technologies. Similarly, if I have somehow mis-understood something, and OGP actually provides for all of these points, I'd like to be made aware of what my misunderstandings are so I can correct them!

Sincerely,

jw

--0-227361953-1235181620=:52772-- From john.hurliman@intel.com Fri Feb 20 18:20:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF4F3A66B4 for ; Fri, 20 Feb 2009 18:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.666 X-Spam-Level: X-Spam-Status: No, score=-5.666 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, J_BACKHAIR_46=1, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZPgzi6QTsnL for ; Fri, 20 Feb 2009 18:20:32 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 7D4A53A67A2 for ; Fri, 20 Feb 2009 18:20:32 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 20 Feb 2009 18:15:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,244,1233561600"; d="scan'208";a="491889791" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by orsmga001.jf.intel.com with ESMTP; 20 Feb 2009 18:20:31 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Fri, 20 Feb 2009 19:20:47 -0700 From: "Hurliman, John" To: "mmox@ietf.org" , "opensim-dev@lists.berlios.de" Date: Fri, 20 Feb 2009 19:20:34 -0700 Thread-Topic: My evaluation of LLSD+LLIDL Thread-Index: AcmTyvoAGzSwaobSSlizmgP/T1Y+Fg== Message-ID: <62BFE5680C037E4DA0B0A08946C0933D50263405@rrsmsx506.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {4E1F6EB3-B48C-4C21-8DCD-8B8C6B186FC8} x-cr-hashedpuzzle: LGk= AD7S CaZm DN6H F3ko HjDJ JSar Mi3K Nl9C N1t8 PFj5 PGkz PbY2 Su10 VQFV WPnB; 2; bQBtAG8AeABAAGkAZQB0AGYALgBvAHIAZwA7AG8AcABlAG4AcwBpAG0ALQBkAGUAdgBAAGwAaQBzAHQAcwAuAGIAZQByAGwAaQBvAHMALgBkAGUA; Sosha1_v1; 7; {4E1F6EB3-B48C-4C21-8DCD-8B8C6B186FC8}; agBvAGgAbgAuAGgAdQByAGwAaQBtAGEAbgBAAGkAbgB0AGUAbAAuAGMAbwBtAA==; Sat, 21 Feb 2009 02:20:34 GMT; TQB5ACAAZQB2AGEAbAB1AGEAdABpAG8AbgAgAG8AZgAgAEwATABTAEQAKwBMAEwASQBEAEwA acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mmox] My evaluation of LLSD+LLIDL X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 02:20:34 -0000 I have a partial, very early implementation of a C# LLIDL lexer/parser and = code generator in SVN at http://openmv.org/svn/misc/LLIDL/ (under the BSD l= icense) in addition to the C# implementation of LLSD that has been under ac= tive development for about a year. This is my evaluation of the combined LL= SD+LLIDL system in comparison to other similar offerings. Please add commen= ts, corrections, and general feedback. Linden Lab Structured Data by itself provides an abstract type system. This= defines a fixed number of data types: null, boolean, signed 32-bit integer= , 64-bit floating point, string, 128-bit UUID, timestamp, URI, binary data,= array, and map. Arrays and maps are weakly typed allowing them to store an= y LLSD data type. Type-casting mechanics are defined, creating a complete, = weakly typed system. Implementation involves a layer to handle the weak typ= ing (straightforward in Python, usually a class for each type inheriting fr= om a base class in OO languages) and a layer to handle the conversions to a= nd from native language types. LLSD by itself is not very interesting; each individual programming languag= e already had its own way of handling data and has no need for a new abstra= ct type system. The idea is that if all languages shared a common type syst= em, one or more serializations can be defined that allows the types to trav= el language and network boundaries. The approach used in other systems (ASN= .1, Google Protocol Buffers, Apache Thrift, etc.) is to clearly define the = data types at the serialization level instead of at the LLSD<->native level= . My opinion is that this is an implementation detail that does not affect = the developer using library in any meaningful way. Where LLSD gets interesting is the addition of LLIDL. The interface descrip= tion language for LLSD defines a text format for defining messages, similar= to what you find in ASN.1, Protobufs, Thrift, and every other IDL. The tex= t is very easy to parse (here's my ANTLR grammar file to convert LLIDL file= s to an AST: http://openmv.org/svn/misc/LLIDL/LLIDL.g, compare this to the = ANTLR grammar for ASN.1: http://www.antlr.org/grammar/1231433381400/ASN.g).= What you do with the LLIDL is an open question. You can make a simple pars= er that validates LLSD against an LLIDL definition, but that doesn't add va= lue beyond being a good debugging tool. You can make a converter for incomi= ng LLSD to conform to an LLIDL definition, but this has questionable value.= Section 2.1 of the LLSD draft already states that reading the values will = either "just work", or default values will be filled in for missing paramet= ers. The only thing LLIDL can offer in addition to this is a warning of whe= ther or not there were missing or extra fields. Additionally, this forces y= ou to work with weakly typed data where you want to have strict type enforc= ement. The code generated by ASN.1, Protobufs, Thrift, etc. doubles as a co= mpiler-enforced contract. Consider the following example: Thrift: struct UserProfile { 1: i32 uid, 2: string name } This might generate psuedocode code like this: public struct UserProfile { int uid; string name; public void Serialize(Stream outputStream) { ... } } LLSD/LLIDL: &UserProfile =3D { uid : int, name : string } This generates: LLSDMap UserProfile; With keys "uid" and "name" that hold the types int and string, respectively= . When writing code with the first example, you know exactly what data type= s the enclosing type is composed of, what the types of each format are, and= any default/fixed values. Working with the LLSD/LLIDL system, your only re= ference is to open up the LLIDL text file and look at it. This is roughly e= quivalent to a well formatted README file. The solution? Implement a strongly typed generator on top of LLSD/LLIDL. Th= is is what my llidlgen program attempts to do. For very basic examples of L= LIDL (such as the example above) this seems like a straightforward thing to= do. However, because of the baked in assumption that no one would attempt = to do this, there are several problems. The outputted code is full of gener= ator-named types and variables, lots of special handling has to be added to= prevent the output from turning into layer after layer of nested classes, = there are situations such as nested maps ({ $ : { $ : int } }) that drastic= ally increase the complexity of converting LLSD types to native types, and = the fact that this happens to be using an abstract type system starts to fe= el like a trivial design decision that is eventually hidden away from the d= eveloper. Summary: * There is no clear benefit to standardizing on conversions at the abstract= type level instead of the serialization level. Doing so removes the abilit= y to enforce data contracts at compile time * The only published code for LLIDL is a broken C# generator. ASN.1, Protob= ufs, and Thrift all have proven implementations across a wide variety of la= nguages * The binary serialization format for LLSD is objectively less efficient th= an the Protobuf serialization format. With real-world data, the gap likely = widens (haven't compared with Thrift or ASN.1). LLSD and Thrift support JSO= N "out of the box", Protobufs is flexible enough to support it but does not= ship with JSON support. I haven't seen anything that would suggest ASN.1 c= ould be transported over JSON. Only LLSD and ASN.1 (XER) support XML * LLSD+LLIDL gives you the choice between guessing and checking what parame= ters need to be serialized for a particular message (no compiler-enforced s= tructure), or writing a strongly typed generator so complex it makes ASN.1 = look easy. Generator-named types and variables (in a strongly typed output)= move the system further away from comprehensible data contracts This evaluation was based on the LLSD/LLIDL draft at http://www.ietf.org/in= ternet-drafts/draft-hamrick-llsd-00.txt. If I overlooked something in the d= raft or misunderstood the intended use please provide corrections. John From jwatte@gmail.com Fri Feb 20 21:59:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0DEC3A6B78 for ; Fri, 20 Feb 2009 21:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF8+QQMSYdab for ; Fri, 20 Feb 2009 21:59:50 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 76EC23A6B7C for ; Fri, 20 Feb 2009 21:59:39 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1154294rvb.49 for ; Fri, 20 Feb 2009 21:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9N3X8c1TaVKCro+yhll5lCrscbpBWJQMVyRT/tfSUC8=; b=GQ/uezRbCxW6ctNW6Dzzv/FYP/ozKoJGpz/LPxVubsvgyj6hpjYQpIH8eLc/oOU3Ff w8yi4o8MPgyy/eLPz1YVCf7QWvYNMj2BrHTWBmr/lTQEO4oaykWNf7A0V/IvrbJA3R7E 1DRxUYIrIzNVEAky5kVnigIIOoXGZNxerGD2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Dcs6vJY6FeIuQTqXBmse1URt168WSkE3zPU6duTXeJ/r01s3Kd8C+piJGB660T8hY7 UCup6jRot5WyHMtDJ4NzRyU977IZ5TyvsK7TM21bE+4Pz7aXTIuGlKUoCAAk+b4PPcAX nRsG1npj/aAwAVKxEA+ySXHrcHKQHk0CyF08w= Received: by 10.140.142.11 with SMTP id p11mr803630rvd.206.1235195994774; Fri, 20 Feb 2009 21:59:54 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id g31sm7795072rvb.7.2009.02.20.21.59.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 21:59:54 -0800 (PST) Message-ID: <499F9859.9020705@gmail.com> Date: Fri, 20 Feb 2009 21:59:53 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <873917.52772.qm@web82607.mail.mud.yahoo.com> In-Reply-To: <873917.52772.qm@web82607.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 05:59:52 -0000 Charles Krinke wrote: > Well, I think the place we are at is that neither SecondLife, nor > OpenSim, nor Fortrerra is likely to substantially change their sim > architecture. Agreed. The internal architecture of each system won't likely change. > In this particular case, OpenSim is using OGP and is using HyperGrid. > Both work. Both are continuing to be developed. So this is not a > theoretical discussion, but rather both are actual implementations > which are deployed. > > So, to me, the debate about creating a new architecture is somewhat moot. > Right; let's just all use the Forterra architecture. No, wait, that doesn't make sense, because implementing the Forterra architecture is a lot of work for everyone else. Let's all use the Multiverse architecture! Ah, but that doesn't make sense, because implementing the Multiverse architecture is a lot of work for everyone not Multiverse. Do you see where I'm getting at? While you can interoperate with other technologies based on the original Second Life design, you're not going to be able to interoperate with any other system if that's the direction you choose. (I would like to point out that the charter for the group says that it is explicitly about designing a new protocol, not rubber stamping any existing approach). Like it or not, a "common denominator" approach that picks the overall easiest implementation (i e, min(sum(map(implementation_cost, everyone)))) is most likely to prevail (in the greater world, as opposed to the narrower Second Life derived subculture). > I would say the way we can make progress is to accept that we all have > ongoing projects and see if there is a way to define a charter for > this working group to define interop between existing architectures > (and future architectures) as we move forward. > > As I look at this whole thing, my hope for it is see a minimal number > of changes to our client<->sim communication in order to keep > compatibility with SecondLife and hopefully add interop compatibility > with Croquet, Wonderland, perhaps Fortrerra, and others. In my proposal, there is zero, or close to zero, change in client <-> sim communication, because the interop happens through gateways between sims. And I'm convinced that sims need to talk to sims, because that's the only way that objects with behaviors can be simulated in a way that every other object with behaviors can be cognizant of the object in the environment. So, given the points that I enumerated, it would be useful if you could enumerate what your opinion is on each point: Here are a few ground rules that I have come to conclude will be necessary for wide acceptance: - User identity is provided by an identity provider, which may be the "home" world of the user, or some other provider. Users should not need identity tied to the specific world they want to visit. Some worlds may choose to not accept certain specific credentials, just like certain real-world stores may not accept Candian dollars for payment. The market will work out a few major credential systems in the end (such as OpenID, perhaps). As long as each system is accessed uniformly, the specifics of the back end don't matter. - Geometry is based on regular meshes, possibly with LOD switches and lower-resolution physics meshes/proxies/hulls. I understand that this may be a sticking point for the SL-derived worlds (or do they actually support arbitrary meshes as an option now? I haven't kept up.) - Texturing is based on a regular Phong model with various defined texture maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on their own). Turns out, once you have the possibility of gloss maps, normal maps, emission maps, opacity maps, diffuse maps and ambient maps, you have 90% of the "look" of any one technology, which is about as good as you can hope for through interoperability. - Telemetry (entity movement) needs to be sent on a position/orientation/velocity basis, with dead reckoning. Delta compression and lower update rates can be used to keep bandwidth usage in check. This is a big difference for OLIVE, because we are input-synchronous, similar to City of Heroes or Age of Empires. However, again, this is the common denominator and experience speaking. - Animating objects need to use a common, widespread interchange format, using named animation clips and skeletal animation. Morph deformation is likely too big a payload to make sense, at least in the early stages. COLLADA is a good format for this, but there are other possibilities (FBX, X3D and X come to mind). I think that making at least one format required is a good idea, because that ensures a minimum level of interoperability is always present. - Simulation and script execution for a given object needs to be done on the "home" system for that object, because objects may be constructed assuming wildly disparate execution environments (X3D with JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, etc). - Objects need to be marked up with simple, well defined possible interactions, so that a user interface can be generated on each client based on those interactions. Interactions are typically "set this property to this value" or "execute this command." Such interactions need to be forwarded to the server that runs the object in question. Similarly, specific interactions ("emote animation," "collision," "damage," "two-party animation," "flight" etc) need to be defined. - Non-time-critical requests should go over HTTP and/or HTTPS, using XML-RPC or a similarly well understood protocol. - Time-critical and high-bandwidth data (such as entity telemetry and user inputs) should be sent using explicit (separate) schema, and binary representation, for the same reason that we don't send streaming video as XML, or mark each pixel with a color space identifier. This is a concrete set of ground rules, that I propose we adapt as guiding principles. If you want to reject some or all of the rules, then I'd like to hear specific arguments (I believe that I've mostly included the arguments /for/ the rules in the rule descriptions themselves). Sincerely, jw From dyerbrookme@juno.com Fri Feb 20 22:58:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2414B3A688D for ; Fri, 20 Feb 2009 22:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiLAnQmZe0Md for ; Fri, 20 Feb 2009 22:58:51 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 5B87E3A685D for ; Fri, 20 Feb 2009 22:58:51 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail04.vgs.untd.com [10.181.12.144]) by smtpout04.vgs.untd.com with SMTP id AABE39KTTAR5RJJA for (sender ); Fri, 20 Feb 2009 22:58:57 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNEzCCC0Gh27Q7mvfrEZRDDg== Received: (from dyerbrookme@juno.com) by webmail04.vgs.untd.com (jqueuemail) id N9WG4CDE; Fri, 20 Feb 2009 22:58:11 PST Received: from [68.161.198.3] by webmail04.vgs.untd.com with HTTP: Sat, 21 Feb 2009 06:58:04 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 21 Feb 2009 06:58:04 GMT To: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090221.015804.27043.0@webmail04.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:3:3153104819 X-MAIL-INFO: 512a7eca8b0b6bc78e5feb1b9f27aece9e8ed77aa3aecf6e0a7b3e6a73ee23474e1ffe8f0e1f2e3e4b432b4fef033e839b63433f875e1bd73e33777eabce7737ab77c7aa1abe X-UNTD-Peer-Info: 10.181.12.144|webmail04.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 06:58:52 -0000 >From: Meadhbh Hamrick (Infinity) To: Ann Otoole Cc: mmox@ietf.org Sent: Friday, February 20, 2009 4:38:33 PM Subject: Re: [mmox] Content metadata through interoperability >ann. this is not the forum for discussions of intellectual property in = general. this is a = forum for discussing issues related to technical interoperability. Infinity, that would seem reasonable except...if interoperability itself= will simply strip away all property rights in the very process of devel= oping standards, by cutting out the c/m/t, by telling everyone to call t= heir lawyer, or put a CC notecard in their prim instead. That's the prob= lem, if the technology and the drive towards interoperability standards = hinge on first dropping the metadata and the previous engineering of an = implementation of c/m/t. Then suddenly interoperability *does* become a = discussion of intellectual property -- because you refused to defend it = technically. You can go on saying, "Oh, please let me do that, let me fi= nish my engineering of the bridge, let us all please have technical disc= ussions without you getting in the way with your commercial concerns, an= d then I promise I'll pop in IP later as a module," but many see this as= putting the cart before the horse. This isn't some internecine quarrel,= it goes to the heart of the matter: does interoperability build in prot= ection of intellectual property along the way toward developing, or does= it drop it as technically not feasible or politically undesirable and p= romise to try to "do something" about the social problem of content crea= tors' ire later? ____________________________________________________________ Find k-12 education here. We take education seriously. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTKM1VSJS3GUuoZzBp7zx3B= CzBqOhpf4VUWjcu7OxmR6XMOtKpypSQ/ From dyerbrookme@juno.com Fri Feb 20 23:07:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84EFC3A6B9D for ; Fri, 20 Feb 2009 23:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KFnuerhU9tW for ; Fri, 20 Feb 2009 23:07:37 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 95B0A3A6873 for ; Fri, 20 Feb 2009 23:07:37 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail04.vgs.untd.com [10.181.12.144]) by smtpout05.vgs.untd.com with SMTP id AABE39LA3AUJMR3J for (sender ); Fri, 20 Feb 2009 23:07:05 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNxRge9BI3ESGGvfsjh1sn2g== Received: (from dyerbrookme@juno.com) by webmail04.vgs.untd.com (jqueuemail) id N9WHJ4T3; Fri, 20 Feb 2009 23:06:14 PST Received: from [68.161.198.3] by webmail04.vgs.untd.com with HTTP: Sat, 21 Feb 2009 07:06:09 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 21 Feb 2009 07:06:09 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090221.020609.27043.1@webmail04.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 3:5:194282167 X-MAIL-INFO: 447d196519bd796d8d4c6d4c01f8591c5d8d0d4df1acace8aca10909aca1fc09780d3d25797d750008199dad28add9 X-UNTD-Peer-Info: 10.181.12.144|webmail04.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 71 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 07:07:38 -0000 >You seem to be having a beef with Linden Labs. It seems like you don't = trust Linden Labs to actually enforce any policy that would be specified= in an interoperability standard. Surely there are more appropriate foru= ms for you to discuss these Second Life specific = things with Linden Labs people. There is only one Linden Lab, it's not "Linden Labs" -- not yet, anyway.= It's not about any "beef" with LL or any "trust". These are generic issu= es. If you do not require of each and every interoperability partner or = candidate that they follow a minimal set of rules, like implementing c/m= /t, then the sender cannot expect that the receiver will feel any restra= int whatsoever. If another grid strips out c/m/t or doesn't implement it= , sending the object into that environment then seems irresponsible, and= it's not specific, it's a generic issue. It's merely that there are now= practical examples of this as you can see from this discussion around t= he opensourcing of the viewer, the hacking up of the viewer to use it to= grief, the blocking of log-ons of the viewer, etc. http://foo.secondlifeherald.com/slh/2009/02/open-life-users-banned-from-= second-life.html >I think a rule of thumb for /this particular list/ should be that if th= e issue discussed is not applicable at least to eight different technolo= gy vendors (for example: = Multiverse, Kaneva, Areae, Forterra, Linden Labs, Qwaq, Second Life and = OpenSim), then it doesn't belong on this list. This seems arbitrary, and I think the generic issue remains: will the te= chnology vendors, in their push toward interoperability, respect technic= al implementations of IP or not, or will they cast it aside as an imposs= ible DRM scheme they are unable or unwilling to implement. This is an im= portant issue to decide early on, now that the cart is before the horse = anyway, so that the public can understand sooner rather than later what = is likely going to happen to their IP. >I believe I have clearly stated that it is my position that all content= should contain metadata, and one piece of that metadata is copy/reuse/c= ache/storage rights. The specific forms of those copy/reuse/cache/storag= e may be c/m/t, or more likely something a little = richer to cater for situations like copylefted content that has "sticky"= semantics. Are you or are you not for having that metadata not just signalled as an= intent, but implemented as a technical, engineering solution on the rec= eiving grid? And it seems to me that for any "copylefted sticky semantic= s" you already have: c/ Prokofy Neva ____________________________________________________________ Shop and compare the best deals on fruit. Act now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTFWpKSPl6hH6rVlAcoWiqW= rVMHpuvTqfUvld3o6WPZI8iSjdodNBh/ From dyerbrookme@juno.com Fri Feb 20 23:29:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035ED3A6C27 for ; Fri, 20 Feb 2009 23:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVRHDmvHPzWj for ; Fri, 20 Feb 2009 23:29:08 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 0D9D93A6C24 for ; Fri, 20 Feb 2009 23:29:07 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail04.vgs.untd.com [10.181.12.144]) by smtpout01.vgs.untd.com with SMTP id AABE39MJ4A7J7ZBJ for (sender ); Fri, 20 Feb 2009 23:28:26 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNh0Cy76ZdrtLN7CvEiOjz2g== Received: (from dyerbrookme@juno.com) by webmail04.vgs.untd.com (jqueuemail) id N9WJSSEV; Fri, 20 Feb 2009 23:27:55 PST Received: from [68.161.198.3] by webmail04.vgs.untd.com with HTTP: Sat, 21 Feb 2009 07:27:31 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 21 Feb 2009 07:27:31 GMT To: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090221.022731.27043.2@webmail04.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:3652636589 X-UNTD-Peer-Info: 10.181.12.144|webmail04.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 69 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 07:29:09 -0000 >Charles, I would support a "real names only" policy. I think the businesslike stage will happen if a determination of who act= ually has a business interest in interoperability is made. I don't know = what the IETF rule on "observers" are -- parties who have an interest, b= ut don't actually have a business directly involved in implementing the = technology under consideration. Jon, I see what you are doing with this effort to make up various exclus= ionary rules and shake loose categories of people, or perhaps just one p= erson. Let me see if I can make up a more workable rule for you that wil= l do the trick: how about excluding females without degrees in computer = science? But...as I can see from the rules, the lists of IETF must be ma= de open to the public. = I'm startled to find that a discussion of the interoperability of virtua= l worlds would require at the outset that only those companies with a "b= usiness interest" would be allowed to take part in the shaping of univer= sal standards, or that only "business interest" is valid as a virtual wo= rld standardizer. This seems to run contrary to many of the aspects and = sentiments around not only the IETF, but the entire Internet, which has = been a mixture of both proprietary and opensource code, business, educat= ion, non-profit, and amateur hobbyist. I fail to see why only profit-mak= ing technology vendors would be empowered to decide matters of interoper= ability affecting us all in virtual worlds, which are an immersive form = of *social* media. = I don't object to a demand for a real name and I supply it, but it strik= es me as an obstacle designed to exclude certain SL avatars who in fact = already have established reputations and businesses under their avatar n= ame, which is an accepted convention. The insistence on real-life names = or "find me everywhere under the same name" shouldn't be welded into the= interop standards. ____________________________________________________________ Find monitors and projectors here. Get serious about tech. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTJHlmLDd4SmOsLTxbvSUl2= 3TCqAh008gAy2Ivk7h1EikzcHHgHAv7/ From infinity@lindenlab.com Fri Feb 20 23:46:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441D63A6873 for ; Fri, 20 Feb 2009 23:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QOpyl8OK1tv for ; Fri, 20 Feb 2009 23:46:47 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 644A03A682B for ; Fri, 20 Feb 2009 23:46:47 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 348231414001; Fri, 20 Feb 2009 23:47:02 -0800 (PST) Message-Id: <8C1B1116-D820-4398-982A-E5F5A24A154A@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <499F49F3.7050508@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 23:46:59 -0800 References: <20090220.134403.24682.0@webmail05.vgs.untd.com> <499F0DEE.7090107@gmail.com> <833718.32681.qm@web59103.mail.re1.yahoo.com> <2FC34C0A-AC59-465C-9BB1-E01339EC35A8@lindenlab.com> <34264.99944.qm@web59104.mail.re1.yahoo.com><1235175079.7560.172.camel@localhost> <499F49F3.7050508@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Kajikawa Jeremy , "mmox@ietf.org" Subject: Re: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 07:46:48 -0000 jon. i agree that being able to keep your identity (including your appearance and any scripted objects you might have following you around) is a very cool idea. at linden lab, we think it's very important to enable this in the future. but we can't enforce this view on other VW operators. just 'cause we have the ability to export avatar meshes that look like an amoeba with a bad head cold doesn't mean blizzard wants such a thing showing up on their grid. so again... mechanism, not policy. we can define how two different administrative domains might communicate about your avatar appearance, while at the same time NOT requiring the target domain to honor the information. -cheers -meadhbh On Feb 20, 2009, at 4:25 PM, Jon Watte wrote: > Kajikawa Jeremy wrote: >> I would agree about the multiple-presence by permissive >> authorizations >> across >> servers and the appearance of an AV being different per-grid. >> >> > > If you can't keep your appearance when you go to another place, then > what good is it? I might as well just register a new avatar for the > new place. One of the whole points of interoperability is the > transportability of my identity (visual, kinetic, and otherwise). > > Is the concern here that some world may develop avatar meshes that > they do wish for their own paying customers to be able to see on > their client machines, but they do not wish friends of the paying > customers, using other client machines, to be able to see those > meshes? In that case, couldn't those world operators simply provide > the generic meshes when asked for the interoperable mesh and texture > set for a given user? > >> If someone makes a "Clan of the Cave bear" environment and someone >> walks >> in >> from playing on an UT2003 or UT2009 server and keeps the AV... >> it would be too anacronistic to explain away if they are part of the >> "tribe" in each. >> >> > > If some world wants to enforce a dress code, I think they can, but > by default, I don't think it should be designed into or required by > the standard. Compare real life: you can put on your biker gear, not > wash for a week, and then walk into an investment bank. You will > feel pretty out of place, just like the UT2003 guy in the Cave Bear > environment. Whether the investment bankers actually throw you out, > probably depends more on what you're doing in their office, than > what your clothing is. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From morgaine.dinova@googlemail.com Fri Feb 20 23:49:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516163A6873 for ; Fri, 20 Feb 2009 23:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljf5dDyb6Msf for ; Fri, 20 Feb 2009 23:49:05 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id B4C6B3A6A2B for ; Fri, 20 Feb 2009 23:49:04 -0800 (PST) Received: by bwz5 with SMTP id 5so3302037bwz.13 for ; Fri, 20 Feb 2009 23:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=srXSAaDPdo97FleGzbAJP+PL+j2rx8LROctgXsXlUDY=; b=rlj2hReDYEMmVnoivO8UXi2fmUb6YgzlCjawRPFOhrwjnB6ygUct8Lip81EK3Egg4k XYIFXGHhcjdGvBfps+vio2XTUDlbj8ZuCvexjc1X4iz2WAwq41YR12BWj4B0Yareyr/1 rePGacqeq8j2FxU1e+lP90SnADb9zwydNPJl4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hNewNelfuhyG4uOHDTmk6xIMN2ljH3AR6ifL2jJv3rEdHJwT2/+augxGwxnKx7F6iD AC0MrNH5iNa6jsJ7sQx3hNq+c9SHYg5LTzwNrj/UMSv8EUXytRjWqfzBfXTLOXEpOur/ vF7RsAkhLUtzXmYbuOZ8lPfB4088Iy6Q3+Ywg= MIME-Version: 1.0 Received: by 10.181.51.14 with SMTP id d14mr608602bkk.4.1235202558717; Fri, 20 Feb 2009 23:49:18 -0800 (PST) In-Reply-To: <499DD634.3050101@gmail.com> References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <499DD634.3050101@gmail.com> Date: Sat, 21 Feb 2009 07:49:18 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=0016364991adbcf34d04636901a6 Cc: "mmox@ietf.org" Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 07:49:07 -0000 --0016364991adbcf34d04636901a6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 19, 2009 at 9:59 PM, Jon Watte wrote: > Morgaine wrote: > >> Unfortunately, that's non-scalable, particularly along the complexity >> axis. >> >> I disagree. See below: > Not at all. Note that the actual simulation of each object happens on the > "home" sim server of that object. Only telemetry is sent to other servers. Aha! :-) Good, I badly misunderstood your previous description, sorry: clearly the idea of simulating all the other worlds with which your users interact would be a non-starter on many grounds, so I'm glad to hear that those simulations are left to the remote systems. But notice that since your local system sensibly does not perform a simulation of the remote worlds in your local shared space, then the "telemetry" that you are sending to those remote worlds is really very similar to the data interchange in the model espoused by Linden Lab and Opensim. In their case, in-world objects belonging to one of their users are forwarded to the remote grid currently being visited by that user, while the user's client directly controls the more interactive aspects of avatar presence. You describe your system as follows: > > If people from 8 different virtual world service providers meet in one > physical space ("my room"), then there will be 8 copies of "my room" > temporarily running on the greater internet, but each of those copies just > simulate one user in that room. The cost of physical space ("my room") is > very cheap, compared to the cost of managing an active, simulated user. Each > server will connect to 7 peer servers, and send the telemetry data for the > one user it simulates, and receive interactions from those 7 peers for > things that affect that one user. > Hang on, there are no copies of your room simulated by those 7 other providers: you made that clear to avoid my point about local simulation not being scalable --- those 7 other worlds would have to have access to your own world simulation code to be able to simulate your room, since your room is a different world to theirs and in the general case has its own special rules and physics. So what you must mean is not that your room is simulated by those other 7, but that they send you their objects (including their avatars) for you to manage within your own room simulation (and you send them telemetry in return), since they do not have access to your world simulation code. Presumably the scheme is symmetrical, so that when you wish to join them in one of their shared rooms, you have to send your avatar and objects there too, since you do not have access to the world simulation code of their rooms either. Those objects they receive from you are then managed by them within their own individual world simulations. If so, that is exactly what the Linden Lab and Opensim models do as well. You've made it clear that the internal behaviour of the objects in your room is always processed within the objects' home environment of your room (I believe), so in LL/Opensim terminology this would mean that the "scripts" of objects always execute in their home world. In other words, any objects you take with you when you visit remote shared rooms have internal behaviour controlled by your home world but external behaviour controlled by the remote world simulations. You haven't described any internal/external behaviour split that way, but it's a necessary conclusion given that you also deny that everyone has to run everyone else's world simulation. Apart from the local execution of object behaviours, which has not yet been defined for SL/Opensim interop, this seems almost identical to their model. If my analysis above is incorrect, then I'd most appreciate you shedding a bit more light on the shared space paradigm, and how it would operate in a metaverse with potentially unbounded virtual world simulation diversity. Morgaine. On Thu, Feb 19, 2009 at 9:59 PM, Jon Watte wrote: > Morgaine wrote: > >> Unfortunately, that's non-scalable, particularly along the complexity >> axis. >> >> > I disagree. See below: > > It works fine in your example because you have only two parties wishing to >> share a space and hence there is only one space to simulate, but try to >> extrapolate from there to see where it leads. If your organization A has N >> users, and those N users wish to take part in N different worlds (which is >> asymptotically likely if N << total number of worlds), then your >> organization A must now simulate N different worlds. For large N, this >> places a colossal load on organization A, even if the individual shared >> spaces are minimally populated. To coin a common phrase by analogy, you're >> undertaking to "simulate the Internet". ;-) >> >> > Not at all. Note that the actual simulation of each object happens on the > "home" sim server of that object. Only telemetry is sent to other servers. > I'm assuming forwarding telemetry is "cheap" whereas simulation of objects > is "expensive" -- previous technical history shows that that is true. Thus, > a virtual world service provider will undertake to provide simulation > capacity for a user and N objects, and that's how many objects the user can > put into the world. Some servers might be on an "all you can eat, and damn > the lag" plan; others may be very metered and charge by the CPU-second. That > is all up to policy, not mechanism. > > If people from 8 different virtual world service providers meet in one > physical space ("my room"), then there will be 8 copies of "my room" > temporarily running on the greater internet, but each of those copies just > simulate one user in that room. The cost of physical space ("my room") is > very cheap, compared to the cost of managing an active, simulated user. Each > server will connect to 7 peer servers, and send the telemetry data for the > one user it simulates, and receive interactions from those 7 peers for > things that affect that one user. > > What's more, very few platform optimizations will be possible since the N >> worlds are all different, and this also means that the scalability of each >> shared space will be severely constrained as well. And as if that were not >> bad enough, the N worlds that your users visit tomorrow will not necessarily >> be today's N worlds, so for (N << total number of worlds) your local cache >> will need to grow almost without limit if it's to work at all. >> >> > Luckily, bandwidth between well connected servers is not a problem. You can > purge the cache when it gets big, and just pull down the asset when you need > it. Compare to YouTube, or MSN, or any other large service provider. That's > not a problem. > > Even if organization A's machinery were powerful enough to support N >> radically different worlds through shared-space simulations though, they >> still couldn't do it, because in the general case the simulation code for a >> given world will not be available. The world simulation is the "secret >> sauce" of many virtual worlds, and from a business perspective it is quite >> likely to be their product differentiator and they will be loathe to share >> it. But even if it were freely available, the portability of one >> organization's simulation code to another organization's machinery is far >> from guaranteed with today's software technology, not to mention the >> management of upgrades for something this complex across organization >> boundaries. >> >> > My proposal specifically says that simulation code stays on the home > server, and only interactions (the "result" of simulation) is shared to > other servers. I agree that no other system can work. > > Foreign world simulations never need to be supported. >> >> > I agree! If you think my proposal requires that, I don't understand how > that came across. Could you find the part where you thought I was suggesting > that and point it out, so I could clarify it? > > Sincerely, > > jw > > --0016364991adbcf34d04636901a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 19, 2009 at 9:59 PM, Jon Watte <jwatte@gmail.com&g= t; wrote:
Morgaine wrote:
Unfortunately, that's non-scalable, particularly along the complexity a= xis.

I disagree. See below:
 
Not at all. Note that the actual s= imulation of each object happens on the "home" sim server of that object. Only telemetry is sent to o= ther servers.


Aha! :-)  Good, I badly misunderstoo= d your previous description, sorry:  clearly the idea of simulating al= l the other worlds with which your users interact would be a non-starter on= many grounds, so I'm glad to hear that those simulations are left to t= he remote systems.

But notice that since your local system sensibly does not perform a sim= ulation of the remote worlds in your local shared space, then the "tel= emetry" that you are sending to those remote worlds is really very sim= ilar to the data interchange in the model espoused by Linden Lab and Opensi= m.  In their case, in-world objects belonging to one of their users ar= e forwarded to the remote grid currently being visited by that user, while = the user's client directly controls the more interactive aspects of ava= tar presence.

You describe your system as follows: 

If people from 8 different virtual world service providers meet in one physical space ("my room"), then there will be 8 copies of "= my room" temporarily running on the greater internet, but each of those copies just simulate one user in that room. The cost of physical space ("my room") is very cheap, compared to the cost of managing an active, simulated user. Each server will connect to 7 peer servers, and send the telemetry data for the one user it simulates, and receive interactions from those 7 peers for things that affect that one user.

Hang on, there are no copies of your room simulated= by those 7 other providers:  you made that clear to avoid my point ab= out local simulation not being scalable --- those 7 other worlds would have= to have access to your own world simulation code to be able to simulate yo= ur room, since your room is a different world to theirs and in the general = case has its own special rules and physics.

So what you must mean is not that your room is simulated by those other= 7, but that they send you their objects  (including their avatars) fo= r you to manage within your own room simulation (and you send them telemetr= y in return), since they do not have access to your world simulation code.&= nbsp; Presumably the scheme is symmetrical, so that when you wish to join t= hem in one of their shared rooms, you have to send your avatar and objects = there too, since you do not have access to the world simulation code of the= ir rooms either.  Those objects they receive from you are then managed= by them within their own individual world simulations.   If so, = that is exactly what the Linden Lab and Opensim models do as well.

You've made it clear that the internal behaviour of the objects in = your room is always processed within the objects' home environment of y= our room (I believe), so in LL/Opensim terminology this would mean that the= "scripts" of objects always execute in their home world.  I= n other words, any objects you take with you when you visit remote shared r= ooms have internal behaviour controlled by your home world but external beh= aviour controlled by the remote world simulations.  You haven't de= scribed any internal/external behaviour split that way, but it's a nece= ssary conclusion given that you also deny that everyone has to run everyone= else's world simulation.

Apart from the local execution of object behaviours, which has not yet = been defined for SL/Opensim interop, this seems almost identical to their m= odel.

If my analysis above is incorrect, then I'd most appreciat= e you shedding a bit more light on the shared space paradigm, and how it wo= uld operate in a metaverse with potentially unbounded virtual world simulat= ion diversity.

Morgaine.




On = Thu, Feb 19, 2009 at 9:59 PM, Jon Watte <jwatte@gmail.com> wrote:
Morgaine wrote:
Unfortunately, that's non-scalable, particularly along the complexity a= xis.


I disagree. See below:


It works fine in your example because you have only two parties wishing to = share a space and hence there is only one space to simulate, but try to ext= rapolate from there to see where it leads.  If your organization A has= N users, and those N users wish to take part in N different worlds (which = is asymptotically likely if N << total number of worlds), then your o= rganization A must now simulate N different worlds.  For large N, this= places a colossal load on organization A, even if the individual shared sp= aces are minimally populated.  To coin a common phrase by analogy, you= 're undertaking to "simulate the Internet". ;-)


Not at all. Note that the actual simulation of each object happens on the &= quot;home" sim server of that object. Only telemetry is sent to other = servers. I'm assuming forwarding telemetry is "cheap" whereas= simulation of objects is "expensive" -- previous technical histo= ry shows that that is true. Thus, a virtual world service provider will und= ertake to provide simulation capacity for a user and N objects, and that= 9;s how many objects the user can put into the world. Some servers might be= on an "all you can eat, and damn the lag" plan; others may be ve= ry metered and charge by the CPU-second. That is all up to policy, not mech= anism.

If people from 8 different virtual world service providers meet in one phys= ical space ("my room"), then there will be 8 copies of "my r= oom" temporarily running on the greater internet, but each of those co= pies just simulate one user in that room. The cost of physical space ("= ;my room") is very cheap, compared to the cost of managing an active, = simulated user. Each server will connect to 7 peer servers, and send the te= lemetry data for the one user it simulates, and receive interactions from t= hose 7 peers for things that affect that one user.


What's more, very few platform optimizations will be possible since the= N worlds are all different, and this also means that the scalability of ea= ch shared space will be severely constrained as well.  And as if that = were not bad enough, the N worlds that your users visit tomorrow will not n= ecessarily be today's N worlds, so for (N << total number of worl= ds) your local cache will need to grow almost without limit if it's to = work at all.


Luckily, bandwidth between well connected servers is not a problem. You can= purge the cache when it gets big, and just pull down the asset when you ne= ed it. Compare to YouTube, or MSN, or any other large service provider. Tha= t's not a problem.


Even if organization A's machinery were powerful enough to support N ra= dically different worlds through shared-space simulations though, they stil= l couldn't do it, because in the general case the simulation code for a= given world will not be available.  The world simulation is the "= ;secret sauce" of many virtual worlds, and from a business perspective= it is quite likely to be their product differentiator and they will be loa= the to share it.  But even if it were freely available, the portabilit= y of one organization's simulation code to another organization's m= achinery is far from guaranteed with today's software technology, not t= o mention the management of upgrades for something this complex across orga= nization boundaries.


My proposal specifically says that simulation code stays on the home server= , and only interactions (the "result" of simulation) is shared to= other servers. I agree that no other system can work.


Foreign world simulations never need to be supported.


I agree! If you think my proposal requires that, I don't understand how= that came across. Could you find the part where you thought I was suggesti= ng that and point it out, so I could clarify it?

Sincerely,

jw


--0016364991adbcf34d04636901a6-- From infinity@lindenlab.com Sat Feb 21 00:02:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458803A6A1C for ; Sat, 21 Feb 2009 00:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYEXBLXDgC1D for ; Sat, 21 Feb 2009 00:02:03 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 63C123A6942 for ; Sat, 21 Feb 2009 00:02:03 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id DA7E51414001; Sat, 21 Feb 2009 00:02:18 -0800 (PST) Message-Id: <3F381422-3691-495F-8A27-45CA031087DE@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: lenglish5@cox.net In-Reply-To: <499F4D01.1010109@cox.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 00:02:16 -0800 References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu><61dbdd7d0902201612i415f8f0i5be70c164d5412e7@mail.gmail.com> <499F4D01.1010109@cox.net> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 08:02:04 -0000 mmm... the mechanism for authentication _is_ defined in OGP in an unambiguous way. the mechanism does not directly support OpenID, Kerberos, sxip, shibboleth, etc. (though it's possible to hijack the shared secret auth scheme to do OpenID.) but yes. OGP/Auth as it is currently written defines MECHANISM, not POLICY. For instance, the OGP support in the beta grid does not support the PKCS12 auth scheme. This was a POLICY decision. If it did, it would support it in a way that was verifiably consistent with the OGP/Auth spec. it might be useful to think of OGP as a "bag of tools" for doing things like authenticating yourself, placing yourself into a particular simulation context, moving around, sending group messages, establishing voice channels, etc. it does not stipulate that each compliant virtual world implement each and every technique. however.. before you could hope to have interoperability, you would have to publish an "interoperability profile" which defines each of the features a particular world implements. there are examples of such critters... X.509/PKIX, X11, RTP and even HTTP to a limited degree. as to the benefit of a protocol that provides mechanism and not policy? defining the wire protocol allows us to ask our friendly neighborhood open source development team to build a "toolbox" for virtual world interactivity. this would allow people building virtual worlds to confine their work to the higher- margin creative work that tends to "sell" such environments. -cheers -meadhbh On Feb 20, 2009, at 4:38 PM, Lawson English wrote: > Gareth Nelson wrote: >>> Tightly coupling the MSP and identity provider functions is why I >>> have to >>> keep telling people that Mark McCahill is named Mysterio Sinister >>> in Second >>> Life - I can't easily be mccahill@duke.edu because Second Life >>> doesn't use >>> external federated identity providers. Then when I go to one of >>> the OpenSim >>> worlds, I need to create another account, and hope that nobody has >>> signed up >>> for Mysterio Sinister before I got there. >>> >> >> Correct me if i'm wrong, but isn't this the problem the OGP agent >> domain was designed to resolve? >> I propose an agent domain which itself allows multiple methods of >> authentication >> > > Authentication itself was left pretty much under-defined to this > point in that OGP, with the assumption that different agent domains > might have different authentication schemes. Another thing to keep > in mind is that, regarding IP issues, different girds/worlds might > have different standards for what is an acceptable authentication > scheme. > > > L > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From jwatte@gmail.com Sat Feb 21 00:05:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398183A6980 for ; Sat, 21 Feb 2009 00:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3gtHmG68RYE for ; Sat, 21 Feb 2009 00:05:15 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 4528C3A6873 for ; Sat, 21 Feb 2009 00:05:15 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1178033rvb.49 for ; Sat, 21 Feb 2009 00:05:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9vuhjb6HyqqeTnJsT35pkv1ngs8JoJiHT8dFcMie8mg=; b=kZP7bVUL27F/Oiu7WuSYyzQkMd5UZLi63/8Qmcb+Yhqcc3UP952sLmzWJjaBvGoxmF XPmWpRkJ9sljyugJ9pwvF9GpLaiD86J7OWrYR5tREpvdYkayulEjCHn1xfM2y3j9bbAC SB3XH9fxseUaeznhJyg/hrfGv3ktEx6NFiECY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=A4h82rpecG+kZiZhuRJxSHMvgudYoDoXW5tu4w5USG0x3HTOEp4w5oPl3g5f5QbWmq Kfh7L8Fj69w7VoBclsYBPoZgVLYO6yyUr8IDykB8CfEVRiudYr6hsIpFJ8m31UHFKY7Z h6xMhCOybj4Qitx1n/2I2YuBCnHdvyz2s2Vaw= Received: by 10.141.28.2 with SMTP id f2mr858515rvj.170.1235203529516; Sat, 21 Feb 2009 00:05:29 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id g14sm2926712rvb.0.2009.02.21.00.05.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 00:05:29 -0800 (PST) Message-ID: <499FB5C8.4030900@gmail.com> Date: Sat, 21 Feb 2009 00:05:28 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Hurliman, John" References: <62BFE5680C037E4DA0B0A08946C0933D50263405@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D50263405@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] My evaluation of LLSD+LLIDL X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 08:05:16 -0000 Hurliman, John wrote: > Linden Lab Structured Data by itself provides an abstract type system. This defines a fixed As does XDR, by the way. XDR is well understood, very widespread, and has been in use (including some very common Internet protocols) for the last 20 years. XDR is also an accepted IETF RFC. Others have pointed out other existing data serialization/encoding standards that already exist and are standardized. However, I think all that is beside the point. Honestly, I really do think we should start with the overall basics of agreeing on requirements, then agreeing on a model of interoperability, before we even start thinking about adopting, adapting, or introducing things like data format specifications. I think the discussion of LLSD on this list is, at best, premature, and at worst, adds noise at this juncture. Sincerely, jw From infinity@lindenlab.com Sat Feb 21 00:13:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B25328C11F for ; Sat, 21 Feb 2009 00:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NliihOHsHyEv for ; Sat, 21 Feb 2009 00:13:40 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id F211A28C0E7 for ; Sat, 21 Feb 2009 00:13:39 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 271CD1414001; Sat, 21 Feb 2009 00:13:55 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <499F5220.5010207@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 00:13:52 -0800 References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com><548919.2383. qm@web82607.mail.mud.yahoo.com><1234917818.6664.51.camel@localhost><77186.32658.qm@web59104.mail.re1.yahoo.com><499C7FAD.408000 9@gmail.com><2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com><499CA9BB.8070506@gmail.com><647098.76086.qm@web82602.mail.mud.yahoo.com><719A6D8A-1198-4A96-804B-5803165C5510@lindenlab .com><499DDEED.2000109@gmail.com><499F0B85.8060807@gmail.com><314782.22040. qm@web82601.mail.mud.yahoo.com><499F3667.4000901@gmail.com><244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 08:13:41 -0000 um. jon. are we reading the same documents? there are no published OGP specs that cover most of the items you list below, so i'm wondering how you came to the conclusion that OGP is "a mixture of things that came out from the SL AWG, motivated by what was easier to implement on top of existing SL-specific technology." ? On Feb 20, 2009, at 5:00 PM, Jon Watte wrote: > Charles Krinke wrote: >> Well, are we going to find that each virtual world is unwilling >> accept any of any other virtual worlds technical decisions? >> Unfortunately, that is the impression I get from this. >> >> This reminds me of the Beta vs VHS history. Beta was argued to be >> the technically superior technology (and it actually was), but so >> many folks adopted the VHS technology that Beta faded into >> obscurity. The point being that the superior technology is trumped >> by the market's adoption of any particular technology. >> >> So, we can spend our time arguing that *our* technology is the >> *superior* one and never give an inch. Or, alternatively, we can >> figure out some way to work together. > > Great points! > > I have never intended that the OLIVE base technology be the basis > for interoperability. Instead, I have over several years done a > fairly large survey of various virtual world technologies, and of > what's worked before, to come up with a "common denominator" type > approach to how virtual world interoperability can actually be made > to work. This is a design from first principles, if you will. That > is what I'm arguing for here. > > By contrast, OGP seems like it is a mixture of things that came out > from the SL AWG, motivated by what was easier to implement on top of > existing SL-specific technology, plus removing specificity in > certain cases, which leads to a protocol that is both not a good > "common denominator" for the entire industry, and not declarative > enough to enable "from scratch" interoperability by just reading the > protocol specification and implementing it. That's what I have > against it -- merits, not sources. > > > Here are a few ground rules that I have come to conclude will be > necessary for wide acceptance: > > - User identity is provided by an identity provider, which may be > the "home" world of the user, or some other provider. Users should > not need identity tied to the specific world they want to visit. > Some worlds may choose to not accept certain specific credentials, > just like certain real-world stores may not accept Candian dollars > for payment. The market will work out a few major credential systems > in the end (such as OpenID, perhaps). As long as each system is > accessed uniformly, the specifics of the back end don't matter. > > - Geometry is based on regular meshes, possibly with LOD switches > and lower-resolution physics meshes/proxies/hulls. I understand that > this may be a sticking point for the SL-derived worlds (or do they > actually support arbitrary meshes as an option now? I haven't kept > up.) > > - Texturing is based on a regular Phong model with various defined > texture maps (because HLSL vs GLSL vs some-other-SL are each of them > not suitable on their own). Turns out, once you have the possibility > of gloss maps, normal maps, emission maps, opacity maps, diffuse > maps and ambient maps, you have 90% of the "look" of any one > technology, which is about as good as you can hope for through > interoperability. > > - Telemetry (entity movement) needs to be sent on a position/ > orientation/velocity basis, with dead reckoning. Delta compression > and lower update rates can be used to keep bandwidth usage in check. > This is a big difference for OLIVE, because we are input- > synchronous, similar to City of Heroes or Age of Empires. However, > again, this is the common denominator and experience speaking. > > - Animating objects need to use a common, widespread interchange > format, using named animation clips and skeletal animation. Morph > deformation is likely too big a payload to make sense, at least in > the early stages. COLLADA is a good format for this, but there are > other possibilities (FBX, X3D and X come to mind). I think that > making at least one format required is a good idea, because that > ensures a minimum level of interoperability is always present. > > - Simulation and script execution for a given object needs to be > done on the "home" system for that object, because objects may be > constructed assuming wildly disparate execution environments (X3D > with JavaScript; Prims with SL Script, C++ with XML, Java with JSR > 184, etc). > > - Objects need to be marked up with simple, well defined possible > interactions, so that a user interface can be generated on each > client based on those interactions. Interactions are typically "set > this property to this value" or "execute this command." Such > interactions need to be forwarded to the server that runs the object > in question. Similarly, specific interactions ("emote animation," > "collision," "damage," "two-party animation," "flight" etc) need to > be defined. > > - Non-time-critical requests should go over HTTP and/or HTTPS, using > XML-RPC or a similarly well understood protocol. > > - Time-critical and high-bandwidth data (such as entity telemetry > and user inputs) should be sent using explicit (separate) schema, > and binary representation, for the same reason that we don't send > streaming video as XML, or mark each pixel with a color space > identifier. > > > Note that the majority of those ground rules are actually not how > OLIVE (or Second Life, or Kaneva, or any one other system) works > internally. That's fine -- these rules are designed to be as easy as > possible to translate to each participating system, while still > being rich enough to provide useful interoperability. > > Now, I would appreciate it if we could take these points, and argue > the necessity or not of each of the points, with concrete examples > that each apply to at least two world technologies. Similarly, if I > have somehow mis-understood something, and OGP actually provides for > all of these points, I'd like to be made aware of what my > misunderstandings are so I can correct them! > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From wjgeorge@dceo.rutgers.edu Sat Feb 21 00:15:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC90928C165 for ; Sat, 21 Feb 2009 00:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1AZqXuZHxW0 for ; Sat, 21 Feb 2009 00:15:33 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 0031C28C144 for ; Sat, 21 Feb 2009 00:15:32 -0800 (PST) Received: by gxk22 with SMTP id 22so3410073gxk.13 for ; Sat, 21 Feb 2009 00:15:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.196.17 with SMTP id t17mr2318676anf.84.1235204147156; Sat, 21 Feb 2009 00:15:47 -0800 (PST) Date: Sat, 21 Feb 2009 03:15:47 -0500 Message-ID: <27a487810902210015t7040f42ck98e08e0d1d82213e@mail.gmail.com> From: William George To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016e645a3d86a96f30463696075 Subject: [mmox] "home" system of object X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 08:15:33 -0000 --0016e645a3d86a96f30463696075 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jon wrote: > - Simulation and script execution for a given object needs to be done on > the "home" system for that object, because objects may be constructed > assuming wildly disparate execution environments (X3D with JavaScript; > Prims with SL Script, C++ with XML, Java with JSR 184, etc). This "home system" could be a complex, doesn't need to be just one machine. Waka --0016e645a3d86a96f30463696075 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jon wrote:

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

This "home system" could be a complex, doesn't need to be just one machine.

Waka
--0016e645a3d86a96f30463696075-- From dcolivares@gmail.com Sat Feb 21 00:18:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931F528C0E7 for ; Sat, 21 Feb 2009 00:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubjW7WY8re9V for ; Sat, 21 Feb 2009 00:18:04 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 4D3A33A6942 for ; Sat, 21 Feb 2009 00:18:04 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so1377279fgb.41 for ; Sat, 21 Feb 2009 00:18:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=BXcpttR4LGdsa60ZZ4nmB4Lgw3KYpQ6Ug2+rcHsVyBI=; b=j2vlEPx8kwmUhkyLvjNi/4bAwS9jHJG2BsGsulCfylaOy0IX6v5rqzAU+gVFOuzGqd XOhK4sYFKBopEnPxkrX1A2ErggwBdeCiFSc8BO3lsVIfCHTx4tqhMruQ8HmGMYrPPjOe tT1JUmxfRce27kPLPoHlSzBO3kdP+QMya/bMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=NyLA0UI4b0yse8ozpNMC+EeDQlmc1yFqzpYYmrHrgWd3NoT8Xdf6GvpquwBqvD9i4x PMh3VtsYZL6BT0KyK54o9UMEFzD66q53zH0mWd6c62Iw4AC1y8r+Ja9O8CwjKAusUazx TzXeoHTThJTiLePFj2viX9UCMcqc3N+dj/tjk= MIME-Version: 1.0 Received: by 10.103.24.17 with SMTP id b17mr2257669muj.112.1235204299053; Sat, 21 Feb 2009 00:18:19 -0800 (PST) Date: Sat, 21 Feb 2009 03:18:18 -0500 Message-ID: From: Dan Olivares To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 08:18:05 -0000 Greetings everyone The positive discussion so far has been interesting and will move us forward in the future, however.. I remind everyone that technically, there is no MMOX working group yet. There is currently only a proposed working group. We also have not voted on a draft charter. There have been several proposals and revisions however, without a working group charter, there is no working group. Is it really in our best interest to be discussing implementation details when we're not even past the draft charter step? We have a limited time here, lets make sure to use it as best we can. I propose that our priority until it's approved should be the charter including the deliverables and milestones of the proposed working group and drumming up interest. Working groups exist to address specific problems or produce deliverables. There are several things that the IETF will be looking for in the formation of MMOX 1. A solid draft charter where rough consensus has been reached and the area director approves. 2. Express the issues that the working group plans to address in a clear way that also demonstrates that it's relevant to the internet community. 3. Express, clearly, the milestones and deliverables that the working group will complete and demonstrate that they can be achieved within a reasonable time frame. 4. Express the importance and urgency of the work. 5. Demonstrate that the working group doesn't overlap with any other IETF working groups 6. Demonstrate that there is a base of interested consumers and developers willing to put in the effort to meet the milestones and produce the deliverables. 7. Demonstrate that the IETF has a reasonable role to play in the determination of this standard (Ref: rfc2418 section 2.1) The charter is sort of like a contract between the working group and the IETF. The working group exists to meet the milestones and produce the deliverables. A few important things that the charter should do; 1. List relevant administrative aspects of the working group. 2. Specify the direction or objectives of the working group and describe the approach that will be taken to achieve the goals. 3. Enumerate a set of milestones together with time frames for their completion. (Ref: rfc2418 section 2.2) For more information on the working group process, please refer to rfc2418 (http://www.ietf.org/rfc/rfc2418.txt) At this point in time, are there any more proposals for the working group draft? Should we move on to establishing rough consensus and BOF? Best Regards Daniel Olivares From infinity@lindenlab.com Sat Feb 21 00:24:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465063A6980 for ; Sat, 21 Feb 2009 00:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVyGmVLm7RDS for ; Sat, 21 Feb 2009 00:24:10 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 784443A6942 for ; Sat, 21 Feb 2009 00:24:10 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 6B6301414001; Sat, 21 Feb 2009 00:24:25 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: "dyerbrookme@juno.com" In-Reply-To: <20090221.015804.27043.0@webmail04.vgs.untd.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 00:24:23 -0800 References: <20090221.015804.27043.0@webmail04.vgs.untd.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 08:24:11 -0000 On Feb 20, 2009, at 10:58 PM, dyerbrookme@juno.com wrote: > Infinity, that would seem reasonable except...if interoperability > itself will simply strip away all property rights in the very > process of developing standards, by cutting out the c/m/t, by > telling everyone to call their lawyer, or put a CC notecard in their > prim instead. ann. i've yet to see this mandated in any protocol suggested here or by the AWG. please do not mis-represent the work going on here. this is a forum for the discussion and development of technical standards. > That's the problem, if the technology and the drive towards > interoperability standards hinge on first dropping the metadata and > the previous engineering of an implementation of c/m/t. again. there are no protocols being considered by this group that would REQUIRE the abandonment of the transport of permissions metadata. > Then suddenly interoperability *does* become a discussion of > intellectual property -- because you refused to defend it > technically. You can go on saying, "Oh, please let me do that, let > me finish my engineering of the bridge, let us all please have > technical discussions without you getting in the way with your > commercial concerns, and then I promise I'll pop in IP later as a > module," but many see this as putting the cart before the horse. > This isn't some internecine quarrel, it goes to the heart of the > matter: does interoperabi > lity build in protection of intellectual property along the way > toward developing, or does it drop it as technically not feasible or > politically undesirable and promise to try to "do something" about > the social problem of content creators' ire later? this is not a forum for you to complain about the permissions system currently deployed on the second life main grid or linden lab's policies regarding digital asset creator's intellectual property rights. there _are_ other forums where this is appropriate and i encourage you to participate in them. From morgaine.dinova@googlemail.com Sat Feb 21 00:39:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5B73A6C3D for ; Sat, 21 Feb 2009 00:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgsZu55r7b6Y for ; Sat, 21 Feb 2009 00:39:00 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 3BEDE3A6B54 for ; Sat, 21 Feb 2009 00:39:00 -0800 (PST) Received: by bwz5 with SMTP id 5so3323333bwz.13 for ; Sat, 21 Feb 2009 00:39:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=DVMQE/vNzD8+JflXNa2eR7oE42KlsAxsDLuWJlqH9Yk=; b=wE2/Cno1gz5WeKvXT7onBpqN4/dFpIuy2Pg78I/0h2Xc/IAcQongf5Ihr2fe1LxYFK Sdq1DJYYrpj8D5CyQIe1iZRVIDcfZsdPbcqurSUZSsl31gtb652k66oZV/kON9oO3pSJ w+BMYnFlK22QtCIdQ45j5ZqQ81ZJJabzXVxPg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=L/2ygFi7yVGL5x7yPiJ3HgEocJ6180S0qwuEzmand97FUpcUUd5Bm8ZMKxcSDlDa5Q ZZsxvaA+FP8QLVy0Ezd9VHhdgGr8O8gGGm1NnEpZHO5MO4EALxoowiTlOj3kNA/XSM3j 0DUQp67gqXQg8L2ZtJXsyzOHUwQcHN+mbv8+A= MIME-Version: 1.0 Received: by 10.181.235.6 with SMTP id m6mr611871bkr.131.1235205554319; Sat, 21 Feb 2009 00:39:14 -0800 (PST) In-Reply-To: <499F10D7.5080605@gmail.com> References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> <61320.78349.qm@web82607.mail.mud.yahoo.com> <962799.66993.qm@web82608.mail.mud.yahoo.com> <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> <88DFFC67-0B59-4D65-86FB-8776899B794A@lindenlab.com> <499F10D7.5080605@gmail.com> Date: Sat, 21 Feb 2009 08:39:14 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=001636c5b1174a2ff0046369b4ee Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD and content schema X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 08:39:01 -0000 --001636c5b1174a2ff0046369b4ee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 20, 2009 at 8:21 PM, Jon Watte wrote: > > If I want to send a piece of data from point A to point B, and point A and > point B know exactly what this data will be, then data type information does > not need to be sent as part of the serialization. In fact, including data > type information is redundant and consumes network bandwidth unnecessarily. > > Thus, I would assume that any communication where size matters (such as for > entity property update streams) will be done using negotiated (bilaterally > understood) schema, with the following properties: > 1) Only data elements, not names or types, are sent. > 2) Specfic properties are addressed using short Ids that are translated in > schema. > 3) If certain properties are always sent together (say, position x y z and > orientation x y z w) then schema allows for an "aggregate property" to be > declared, such that only a single name (Id) is needed to identify that > entire tuple. > > That is quite close to being a description of Google Protocol Buffers. One of the reasons why I find LLSD to be "tentatively satisfactory" as a * base* from which to create an ADT layer suitable for virtual worlds interop is that LLSD embraces multiple alternative serializations, and to its 3 current serializations I would be adding Protocol Buffers for the very good properties that you described. Several other changes would be needed too, in particular the addition of new data types to remove the conversion ambiguities that others have mentioned, as well as to support more efficient encoding of common VW elements beyond LL's native requirements. Despite the need for all these changes, I do find LLSD to be a useful *base* from which to start, largely because nobody has suggested an alternative *that ticks all the same boxes*. Given an alternative *that ticks all the same boxes* (this is important) then I would of course re-evaluate the matter. Morgaine. --001636c5b1174a2ff0046369b4ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 20, 2009 at 8:21 PM, Jon Wat= te <jwatte@gmail.c= om> wrote:

If I want to send a piece of data from point A to point B, and point A and = point B know exactly what this data will be, then data type information doe= s not need to be sent as part of the serialization. In fact, including data= type information is redundant and consumes network bandwidth unnecessarily= .

Thus, I would assume that any communication where size matters (such as for= entity property update streams) will be done using negotiated (bilaterally= understood) schema, with the following properties:
1) Only data elements, not names or types, are sent.
2) Specfic properties are addressed using short Ids that are translated in = schema.
3) If certain properties are always sent together (say, position x y z and = orientation x y z w) then schema allows for an "aggregate property&quo= t; to be declared, such that only a single name (Id) is needed to identify = that entire tuple.


That is quite close to being a description of Go= ogle Protocol Buffers.

One of the reasons why I find LLSD to be &quo= t;tentatively satisfactory" as a base from which to create an A= DT layer suitable for virtual worlds interop is that LLSD embraces multiple= alternative serializations, and to its 3 current serializations I would be= adding Protocol Buffers for the very good properties that you described.
Several other changes would be needed too, in particular the addition o= f new data types to remove the conversion ambiguities that others have ment= ioned, as well as to support more efficient encoding of common VW elements = beyond LL's native requirements.  Despite the need for all these c= hanges, I do find LLSD to be a useful base from which to start, larg= ely because nobody has suggested an alternative that ticks all the same = boxes.

Given an alternative that ticks all the same boxes (this is imp= ortant) then I would of course re-evaluate the matter.

Morgaine.
--001636c5b1174a2ff0046369b4ee-- From morgaine.dinova@googlemail.com Sat Feb 21 00:59:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58DAC3A688F for ; Sat, 21 Feb 2009 00:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPPvFXP643lt for ; Sat, 21 Feb 2009 00:59:17 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 1914A3A6873 for ; Sat, 21 Feb 2009 00:59:16 -0800 (PST) Received: by bwz5 with SMTP id 5so3332240bwz.13 for ; Sat, 21 Feb 2009 00:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Hul6viu0MOsqpHlH3vIrHNbZ5KfEkVrLym2nPK/OuPo=; b=XVnk6OzGXTO/6j7OgdIl0nPiUYpI0EBHWpo37QbXZR08zF33VHYFbDWs8xHOGA2FUg fPM9nO2Us4XhVzNxtB4Cdq7iUHTXQaeQm+FlTO1fUVy0uf0INKNixLwA6FrCga7xfqni +V+X61SDYi+Wipg+dZ2jFhfCMmsRgomPqZGPI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=azW7Z9UckqGIOKUf9H/Lw77+xR7QGGvSleUh98X1xTz++qbPR+tgmTmYDGLQwLS57V wYUFdV0erlwsQ1d3VFFMgLXw6+LtTikeT0H9+4NOZeB6iPqAYaL06vCEbdNaLeeavFXW 7zwIdwOExOBaxdp65WVYEljFM0lwZfxSkAJQM= MIME-Version: 1.0 Received: by 10.181.139.10 with SMTP id r10mr627849bkn.11.1235206770071; Sat, 21 Feb 2009 00:59:30 -0800 (PST) In-Reply-To: <8C1B1116-D820-4398-982A-E5F5A24A154A@lindenlab.com> References: <20090220.134403.24682.0@webmail05.vgs.untd.com> <499F0DEE.7090107@gmail.com> <833718.32681.qm@web59103.mail.re1.yahoo.com> <2FC34C0A-AC59-465C-9BB1-E01339EC35A8@lindenlab.com> <34264.99944.qm@web59104.mail.re1.yahoo.com> <1235175079.7560.172.camel@localhost> <499F49F3.7050508@gmail.com> <8C1B1116-D820-4398-982A-E5F5A24A154A@lindenlab.com> Date: Sat, 21 Feb 2009 08:59:30 +0000 Message-ID: From: Morgaine To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=001636499f6dc118cf046369fcea Cc: Kajikawa Jeremy , "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 08:59:18 -0000 --001636499f6dc118cf046369fcea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 7:46 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > > just 'cause we have the ability to export avatar meshes that look like an > amoeba with a bad head cold doesn't mean blizzard wants such a thing showing > up on their grid. > > so again... mechanism, not policy. That is a very clear statement (and a funny illustration) of where I have always believed that virtual worlds interop was heading. While there will undoubtedly be huge interest in maintaining an avatar's properties such as appearance and visible name while hopping from world to world (because people take much pride in their visible attributes), this cannot be imposed upon a world operator for a variety of reasons, including technical, artistic and many others. As Infinity states, our interest should be merely in *allowing* such continuity, not in requiring it. We define the mechanisms of interop, but not the policies. Morgaine. --001636499f6dc118cf046369fcea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 21, 2009 at 7:46 AM, Meadhbh= Hamrick (Infinity) <infinity@lindenlab.com> wrote:

= just 'cause we have the ability to export avatar meshes that look like = an amoeba with a bad head cold doesn't mean blizzard wants such a thing= showing up on their grid.

so again... mechanism, not policy.

That is a very clea= r statement (and a funny illustration) of where I have always believed that= virtual worlds interop was heading.

While there will undoubtedly be= huge interest in maintaining an avatar's properties such as appearance= and visible name while hopping from world to world (because people take mu= ch pride in their visible attributes), this cannot be imposed upon a world = operator for a variety of reasons, including technical, artistic and many o= thers.

As Infinity states, our interest should be merely in allowing su= ch continuity, not in requiring it.  We define the mechanisms of inter= op, but not the policies.

Morgaine.
--001636499f6dc118cf046369fcea-- From gareth@litesim.com Sat Feb 21 01:14:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF7D3A68BB for ; Sat, 21 Feb 2009 01:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZvfyeBDS9zL for ; Sat, 21 Feb 2009 01:14:48 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 6A3B83A689F for ; Sat, 21 Feb 2009 01:14:25 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so1177456rvb.5 for ; Sat, 21 Feb 2009 01:14:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.161.11 with SMTP id j11mr899355rve.15.1235207679559; Sat, 21 Feb 2009 01:14:39 -0800 (PST) In-Reply-To: References: Date: Sat, 21 Feb 2009 09:14:39 +0000 Message-ID: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> From: Gareth Nelson To: Dan Olivares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 09:14:49 -0000 So, why don't we get on with voting on a charter? As for discussing implementation details now - nothing wrong with doing so if it's in the same basic area as the formal working group would be On Sat, Feb 21, 2009 at 8:18 AM, Dan Olivares wrote: > Greetings everyone > > The positive discussion so far has been interesting and will move us > forward in the future, however.. I remind everyone that technically, > there is no MMOX working group yet. There is currently only a > proposed working group. We also have not voted on a draft charter. > There have been several proposals and revisions however, without a > working group charter, there is no working group. Is it really in our > best interest to be discussing implementation details when we're not > even past the draft charter step? We have a limited time here, lets > make sure to use it as best we can. I propose that our priority > until it's approved should be the charter including the deliverables > and milestones of the proposed working group and drumming up interest. > > Working groups exist to address specific problems or produce > deliverables. There are several things that the IETF will be looking > for in the formation of MMOX > > 1. A solid draft charter where rough consensus has been reached and > the area director approves. > 2. Express the issues that the working group plans to address in a > clear way that also demonstrates that it's relevant to the internet > community. > 3. Express, clearly, the milestones and deliverables that the working > group will complete and demonstrate that they can be achieved within a > reasonable time frame. > 4. Express the importance and urgency of the work. > 5. Demonstrate that the working group doesn't overlap with any other > IETF working groups > 6. Demonstrate that there is a base of interested consumers and > developers willing to put in the effort to meet the milestones and > produce the deliverables. > 7. Demonstrate that the IETF has a reasonable role to play in the > determination of this standard > (Ref: rfc2418 section 2.1) > > > The charter is sort of like a contract between the working group and > the IETF. The working group exists to meet the milestones and > produce the deliverables. A few important things that the charter > should do; > > 1. List relevant administrative aspects of the working group. > 2. Specify the direction or objectives of the working group and > describe the approach that will be taken to achieve the goals. > 3. Enumerate a set of milestones together with time frames for their > completion. > > (Ref: rfc2418 section 2.2) > > For more information on the working group process, please refer to > rfc2418 (http://www.ietf.org/rfc/rfc2418.txt) > > At this point in time, are there any more proposals for the working > group draft? Should we move on to establishing rough consensus and > BOF? > > Best Regards > > Daniel Olivares > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From infinity@lindenlab.com Sat Feb 21 01:17:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59B6C3A6868 for ; Sat, 21 Feb 2009 01:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qfVwm4saQxI for ; Sat, 21 Feb 2009 01:17:53 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 7A5983A67A3 for ; Sat, 21 Feb 2009 01:17:53 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id DFE701414001; Sat, 21 Feb 2009 01:18:08 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <499F10D7.5080605@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 01:18:06 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com><80E946E9-5C62-4E00-BE8C-A15513898F99@lindenla b.com><62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com><29656.28734.qm@web82607.mail.mud.yahoo.com><61320.78349.qm@web82607.mail.mud.yahoo.com><962799.66993.qm@web82608.mail.mud.yahoo.com> <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> <88DFFC67-0B59-4D65-86FB-8776899B794A@lindenlab.com> <499F10D7.5080605@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD and content schema X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 09:17:54 -0000 On Feb 20, 2009, at 12:21 PM, Jon Watte wrote: > Meadhbh Hamrick (Infinity) wrote: >> * LLSD is implementable by mortals in a tractable amount of time >> and without the use of complicated third-party tools (ASN.1 >> compilers, etc.) > > I don't see the LLSD interface compiler as any different in > conceptual complexity than an ASN.1 compiler. I did bring up the > question of ASN.1 before, and was told by you that you felt it was > "too buggy," which I think is not fair or accurate. which LLSD compiler are you referring to? i wasn't aware that one was required or available. > However, I believe ASN.1 and also LLSD have a problem that I'd like > to see addressed in a standard: they use implicit schema. > > If I want to send a piece of data from point A to point B, and the > points don't both exactly know what the data is, that's fine -- but, > in that case, you typically want to use something a little more open- > ended and more generally standardized, like XML. The benefit of XML > is that there are tons of tools that already support it (as there > are with ASN.1, btw); XML also allows well-formed documents to be > verified using XSD schema. If you need large binary blob support > (textures, etc), those can be included by reference uri. I think XML > is appropriate for those cases, and LLSD doesn't quite fit the bill > in that case. Jon. i think you mis-understand LLSD. there is nothing in the LLSD specification that REQUIREs a schema be defined. In the current implementations of LLSD, it is not considered a transport-layer error to add an additional field, or even to drop one that's defined by an application protocol. In this sense XML is more restrictive because it REQUIRES you to create a new DTD to extend an existing message flow (though presumably you would configure your DTDs or Schemas to be easily extensible.) for instance.. if a parameter was defined as: &response = { success : false , description : string , err_num : integer } &response = { success : true, description : string } %% foo <- undef -> & response and you received an XML serialization that looked like: success true something_i_like_to_eat_on_sundays bananas this i not an error. an implementation that attempted to get the value of "description" field from the map would retrieve the default for type string (i.e. - a zero length string.) that the 'something_i_like_to_eat_on_sundays' information is passed may be a waste of bandwidth, but it might also be a new message format unknown by the consumer. a system that ignores unexpected input is a system that has a fighting chance of not having to upgraded in tandem with the client. > If I want to send a piece of data from point A to point B, and point > A and point B know exactly what this data will be, then data type > information does not need to be sent as part of the serialization. > In fact, including data type information is redundant and consumes > network bandwidth unnecessarily. however, sending type information in the serialization allows intermediary systems to reason about the content of the data they are receiving and potentially make routing and caching decisions based on the content. LLSD is intended to be used in a "loosely coupled" environment. one "feature" of such an environment is that systems be resilient in the face of heterogeneity in terms of component version. for example, consider a logging system that received logging messages from a number of clients and stores them for later analysis. when the system is initially deployed, messages may be defined as the tuple (source, severity, description). it is not difficult to imagine the situation where one client wishes to add a value to that tuple to make it (source, facility, severity, description). in tightly bound systems, you might create a new message PDU format, but both the client and the server would need to know about this change at exactly the same time (otherwise the server would signal an error when it received an unknown message format. now imagine the mess if half of the systems were in one administrative domain and the rest in another. From morgaine.dinova@googlemail.com Sat Feb 21 01:24:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737D33A67A3 for ; Sat, 21 Feb 2009 01:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id totfvR34HO1j for ; Sat, 21 Feb 2009 01:24:04 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id EE2243A6885 for ; Sat, 21 Feb 2009 01:24:03 -0800 (PST) Received: by bwz5 with SMTP id 5so3344453bwz.13 for ; Sat, 21 Feb 2009 01:24:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7j3iuS6qRdSy6XAI/AItGze60bBcsnAW67eLZ7uDN4A=; b=jbJf2zyt9/0DWvhCzYolPuDjIT20NeniBF5aZDuEpaKpYkWGofzfSrM7zvlUJ2IudD ka2mHp8A1hI1t1bAdgo2VEcVehFWcBatFIn+fst5BxH9ruynjvJGywBjO7LBeTcJPwbI jmbRFX7kJXMdDD6gY1gTggp6Dr07XaXT/aiYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FjCWkHPgcDmJjmuGD6dYsVRHUt6jLn/IrGkIALO2YFxpii/SPTLPHRbbf3xCkU7AAm z5ykSbUShd9dNt2Q7tdZSCGuE3wVpFQ7AsrGvWyOe22jaQ4yZN9ZGUyC33HpYtOg9Kb2 fOjIgjXnNp2bVb15jg5GueIb54PeMIHs40YNQ= MIME-Version: 1.0 Received: by 10.181.159.11 with SMTP id l11mr619123bko.186.1235208258287; Sat, 21 Feb 2009 01:24:18 -0800 (PST) In-Reply-To: <499FB5C8.4030900@gmail.com> References: <62BFE5680C037E4DA0B0A08946C0933D50263405@rrsmsx506.amr.corp.intel.com> <499FB5C8.4030900@gmail.com> Date: Sat, 21 Feb 2009 09:24:18 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=0016e6d7dff47578fe04636a55bf Cc: "mmox@ietf.org" Subject: Re: [mmox] My evaluation of LLSD+LLIDL X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 09:24:05 -0000 --0016e6d7dff47578fe04636a55bf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 8:05 AM, Jon Watte wrote: > > Honestly, I really do think we should start with the overall basics of > agreeing on requirements, then agreeing on a model of interoperability, > before we even start thinking about adopting, adapting, or introducing > things like data format specifications. I think the discussion of LLSD on > this list is, at best, premature, and at worst, adds noise at this juncture. > > I don't see why this should be so. The two activities are highly independent, and so work on them can proceed concurrently. In general, I would tend to take the opposite approach to yours, and define my foundations before trying to build more complex structures. It's the usual bottom-up approach in engineering. The only time when defining the datatypes first isn't sensible nor feasible is when the datatypes are not yet known, but that is not the case here. We all have experience of one virtual world or several, and therefore we know the datatypes needed for interop: it is the superset of all the ones we use or imagine we might use, which is a rather small set of primitive types plus some composite construction material. It's rather simple. Admittedly LLSD is too narrow, but that's why we'll be extending it to suit worlds beyond LL's. (*Proviso: unless someone proposes an equally flexible alternative.)* Morgaine. --0016e6d7dff47578fe04636a55bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 21, 2009 at 8:05 AM, Jon Wat= te <jwatte@gmail.c= om> wrote:

Honestly, I really do think we should start with the overall basics of agre= eing on requirements, then agreeing on a model of interoperability, before = we even start thinking about adopting, adapting, or introducing things like= data format specifications. I think the discussion of LLSD on this list is= , at best, premature, and at worst, adds noise at this juncture.

I don't see why this should be so.  The two= activities are highly independent, and so work on them can proceed concurr= ently.

In general, I would tend to take the opposite approach to you= rs, and define my foundations before trying to build more complex structure= s.  It's the usual bottom-up approach in engineering.

The only time when defining the datatypes first isn't sensible nor = feasible is when the datatypes are not yet known, but that is not the case = here.  We all have experience of one virtual world or several, and the= refore we know the datatypes needed for interop:  it is the superset o= f all the ones we use or imagine we might use, which is a rather small set = of primitive types plus some composite construction material.  It'= s rather simple.

Admittedly LLSD is too narrow, but that's why we'll be extendin= g it to suit worlds beyond LL's.  (Proviso: unless someone prop= oses an equally flexible alternative.)

Morgaine.
--0016e6d7dff47578fe04636a55bf-- From infinity@lindenlab.com Sat Feb 21 01:32:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DA13A68A4 for ; Sat, 21 Feb 2009 01:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESwQMmpGIHM5 for ; Sat, 21 Feb 2009 01:32:12 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 6904E3A67D0 for ; Sat, 21 Feb 2009 01:32:12 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id EC53A1414001; Sat, 21 Feb 2009 01:32:27 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Dan Olivares In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 01:32:25 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 09:32:13 -0000 right. the agenda for the upcoming meeting is essentially: * what's "in scope" for the charter, * a brief rap about trust, and * LLSD but i can understand why people might want to jump into the deep end quickly. all of us who have committed to the source code trees of our respective projects or spent time designing aspects of virtual worlds have considerable interest in our creations... personal and professional. ultimately this group is about teasing out the best from each of our individual approaches and agreeing to standardize those techniques. we may want to consider two styles of interop: "interoperability" and "INTEROPERABILITY". the latter might imply that any client may connect to any sever and expect to get a "reasonable experience." i think we all agree this would be hard. the former style might imply a series of mechanisms defined for particular tasks with the exact definition of which mechanisms and what options to use defined in an "interoperability profile." the problem with this technique is it may lead to systems that adhere to the specification but are not INTEROPERABLE in any practical sense. but it still has benefit if your objective is to build a system with limited "INTEROPERABILITY" between virtual world implementations, but is "interoperable" with particular tool chains. so.. i would add to the list of things to think about... where you want to be on the "big I" / "little i" spectrum. -cheers -meadhbh On Feb 21, 2009, at 12:18 AM, Dan Olivares wrote: > Greetings everyone > > The positive discussion so far has been interesting and will move us > forward in the future, however.. I remind everyone that technically, > there is no MMOX working group yet. There is currently only a > proposed working group. We also have not voted on a draft charter. > There have been several proposals and revisions however, without a > working group charter, there is no working group. Is it really in our > best interest to be discussing implementation details when we're not > even past the draft charter step? We have a limited time here, lets > make sure to use it as best we can. I propose that our priority > until it's approved should be the charter including the deliverables > and milestones of the proposed working group and drumming up interest. > > Working groups exist to address specific problems or produce > deliverables. There are several things that the IETF will be looking > for in the formation of MMOX > > 1. A solid draft charter where rough consensus has been reached and > the area director approves. > 2. Express the issues that the working group plans to address in a > clear way that also demonstrates that it's relevant to the internet > community. > 3. Express, clearly, the milestones and deliverables that the working > group will complete and demonstrate that they can be achieved within a > reasonable time frame. > 4. Express the importance and urgency of the work. > 5. Demonstrate that the working group doesn't overlap with any other > IETF working groups > 6. Demonstrate that there is a base of interested consumers and > developers willing to put in the effort to meet the milestones and > produce the deliverables. > 7. Demonstrate that the IETF has a reasonable role to play in the > determination of this standard > (Ref: rfc2418 section 2.1) > > > The charter is sort of like a contract between the working group and > the IETF. The working group exists to meet the milestones and > produce the deliverables. A few important things that the charter > should do; > > 1. List relevant administrative aspects of the working group. > 2. Specify the direction or objectives of the working group and > describe the approach that will be taken to achieve the goals. > 3. Enumerate a set of milestones together with time frames for their > completion. > > (Ref: rfc2418 section 2.2) > > For more information on the working group process, please refer to > rfc2418 (http://www.ietf.org/rfc/rfc2418.txt) > > At this point in time, are there any more proposals for the working > group draft? Should we move on to establishing rough consensus and > BOF? > > Best Regards > > Daniel Olivares > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Sat Feb 21 01:33:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4053B3A67D9 for ; Sat, 21 Feb 2009 01:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oudJuDN-sZN3 for ; Sat, 21 Feb 2009 01:33:10 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 6B1C03A67D0 for ; Sat, 21 Feb 2009 01:33:10 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 097EF1414001; Sat, 21 Feb 2009 01:33:26 -0800 (PST) Message-Id: <84AB249C-46C5-4239-A9AD-D4844E9987C4@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: "dyerbrookme@juno.com" In-Reply-To: <20090221.020609.27043.1@webmail04.vgs.untd.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 01:33:23 -0800 References: <20090221.020609.27043.1@webmail04.vgs.untd.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 71 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 09:33:11 -0000 okay. let me be clear. if you are upset that a particular second life account was terminated for non payment of fees, this is an issue you need to bring up with linden lab, not this list. this is a forum for the technical discussion of the development of interoperability protocols for virtual worlds. please take the discussion of linden's policies elsewhere. thank you On Feb 20, 2009, at 11:06 PM, dyerbrookme@juno.com wrote: >> You seem to be having a beef with Linden Labs. It seems like you >> don't trust Linden Labs to actually enforce any policy that would >> be specified in an interoperability standard. Surely there are more >> appropriate forums for you to discuss these Second Life specific > things with Linden Labs people. > > There is only one Linden Lab, it's not "Linden Labs" -- not yet, > anyway. > > It's not about any "beef" with LL or any "trust". These are generic > issues. If you do not require of each and every interoperability > partner or candidate that they follow a minimal set of rules, like > implementing c/m/t, then the sender cannot expect that the receiver > will feel any restraint whatsoever. If another grid strips out c/m/t > or doesn't implement it, sending the object into that environment > then seems irresponsible, and it's not specific, it's a generic > issue. It's merely that there are now practical examples of this as > you can see from this discussion around the opensourcing of the > viewer, the hacking up of the viewer to use it to grief, the > blocking of log-ons of the viewer, etc. > > http://foo.secondlifeherald.com/slh/2009/02/open-life-users-banned-from-second-life.html > >> I think a rule of thumb for /this particular list/ should be that >> if the issue discussed is not applicable at least to eight >> different technology vendors (for example: > Multiverse, Kaneva, Areae, Forterra, Linden Labs, Qwaq, Second Life > and OpenSim), then it doesn't belong on this list. > > This seems arbitrary, and I think the generic issue remains: will > the technology vendors, in their push toward interoperability, > respect technical implementations of IP or not, or will they cast it > aside as an impossible DRM scheme they are unable or unwilling to > implement. This is an important issue to decide early on, now that > the cart is before the horse anyway, so that the public can > understand sooner rather than later what is likely going to happen > to their IP. > >> I believe I have clearly stated that it is my position that all >> content should contain metadata, and one piece of that metadata is >> copy/reuse/cache/storage rights. The specific forms of those copy/ >> reuse/cache/storage may be c/m/t, or more likely something a little > richer to cater for situations like copylefted content that has > "sticky" semantics. > > Are you or are you not for having that metadata not just signalled > as an intent, but implemented as a technical, engineering solution > on the receiving grid? And it seems to me that for any "copylefted > sticky semantics" you already have: c/ > > Prokofy Neva > > > > ____________________________________________________________ > Shop and compare the best deals on fruit. Act now! > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTFWpKSPl6hH6rVlAcoWiqWrVMHpuvTqfUvld3o6WPZI8iSjdodNBh/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From morgaine.dinova@googlemail.com Sat Feb 21 01:40:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07EDF3A6885 for ; Sat, 21 Feb 2009 01:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+naj6wbBMbG for ; Sat, 21 Feb 2009 01:40:12 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id A32C43A67D9 for ; Sat, 21 Feb 2009 01:40:11 -0800 (PST) Received: by bwz5 with SMTP id 5so3352276bwz.13 for ; Sat, 21 Feb 2009 01:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=uXUiARHA9Crycl+xH6enewk+2kR8z5Y41+qpygJbucM=; b=DPqK9VUC3+Ea85rQFcgyctjASx7kUkqsTpBri9g6Jm6QgGWYTOAppTFR1FVghFlnk1 1ohrJbxwf+idvMbNZ9NSEmVzp/nIAaMGBc4ak4fDg/DN+kU/uXAYNmGozM4Yco/0Rfgf kIxiN8Dh7dbFcuJ61chZ0sEHNUcJeZagb1PWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OrOMzX/WGvzV60igc9AE3plsdNl2rhYxDHAKPKGFgo2z5xbFsKGiJx07gCr6mL5Sdu 5MHbbGm3FOuw8hGSUZakZ7/ktsw13pcQN7g7OPx+oiTaqUsBgBshwoZdbx0/fwDfRVNx T3xdelAyP3Npypwbtysar5MQoKpAQ243vMtm0= MIME-Version: 1.0 Received: by 10.181.206.7 with SMTP id i7mr636374bkq.57.1235209225701; Sat, 21 Feb 2009 01:40:25 -0800 (PST) In-Reply-To: <499F5220.5010207@gmail.com> References: <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> Date: Sat, 21 Feb 2009 09:40:25 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=0016e6d646881f0a2704636a8fcc Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 09:40:13 -0000 --0016e6d646881f0a2704636a8fcc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 1:00 AM, Jon Watte wrote: > > - Geometry is based on regular meshes, possibly with LOD switches and > lower-resolution physics meshes/proxies/hulls. I understand that this may be > a sticking point for the SL-derived worlds (or do they actually support > arbitrary meshes as an option now? I haven't kept up.) > We're defining mechanism, not policy, so there is no possible sticking point for Linden Lab if the interop standard provides for interchange of meshes as is so widely required. LL are free to not implement meshes if they choose not to do so, that's all. I believe that such a decision would impact on their business, but it is not up to me (nor us) to make that call. By the same token, if we define interchange of SL-like "primitive" objects to be in the standard, then anyone who wants to benefit from the acceleration and standardized behaviour of such primitives is free to implement them (the Opensim worlds certainly will), but nobody is *required*to do so. Mechanism, not policy. Morgaine. --0016e6d646881f0a2704636a8fcc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 21, 2009 at 1:00 AM, Jon Wat= te <jwatte@gmail.c= om> wrote:

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

We're defining mechanism, not policy, so there is= no possible sticking point for Linden Lab if the interop standard provides= for interchange of meshes as is so widely required.  LL are free to n= ot implement meshes if they choose not to do so, that's all.  = ; I believe that such a decision would impact on their business, but it is = not up to me (nor us) to make that call.

By the same token, if we define interchange of SL-like "primitive&= quot; objects to be in the standard, then anyone who wants to benefit from = the acceleration and standardized behaviour of such primitives is free to i= mplement them (the Opensim worlds certainly will), but nobody is require= d to do so.

Mechanism, not policy.

Morgaine.
--0016e6d646881f0a2704636a8fcc-- From infinity@lindenlab.com Sat Feb 21 01:55:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028723A68F9 for ; Sat, 21 Feb 2009 01:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.244 X-Spam-Level: X-Spam-Status: No, score=-3.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX2rnGdJ0Pfd for ; Sat, 21 Feb 2009 01:55:37 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 6615F3A6868 for ; Sat, 21 Feb 2009 01:55:37 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 9C1631414001; Sat, 21 Feb 2009 01:55:52 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Gareth Nelson In-Reply-To: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 01:55:50 -0800 References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 09:55:38 -0000 hey gareth... i think the IETF policy is we want to discuss it f2f before finalizing the charter. and MHO is we're still a ways away from enough consensus to declare work on the charter "done". On Feb 21, 2009, at 1:14 AM, Gareth Nelson wrote: > So, why don't we get on with voting on a charter? > As for discussing implementation details now - nothing wrong with > doing so if it's in the same basic area as the formal working group > would be > > On Sat, Feb 21, 2009 at 8:18 AM, Dan Olivares > wrote: From gareth@litesim.com Sat Feb 21 01:59:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12F13A68F9 for ; Sat, 21 Feb 2009 01:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJNnq9tDp2kp for ; Sat, 21 Feb 2009 01:59:21 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 402DD3A6868 for ; Sat, 21 Feb 2009 01:59:21 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1196687rvb.49 for ; Sat, 21 Feb 2009 01:59:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.210.2 with SMTP id m2mr895098rvq.284.1235210375592; Sat, 21 Feb 2009 01:59:35 -0800 (PST) In-Reply-To: References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> Date: Sat, 21 Feb 2009 09:59:35 +0000 Message-ID: <61dbdd7d0902210159u5b597d73j1829656935321069@mail.gmail.com> From: Gareth Nelson To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 09:59:21 -0000 Well, i'm out of luck then, being on a whole other continent from all you guys. How much consensus do we need to build a charter? Surely the consensus on implementation details is different from consensus on what we're actually doing here? On Sat, Feb 21, 2009 at 9:55 AM, Meadhbh Hamrick (Infinity) wrote: > hey gareth... > > i think the IETF policy is we want to discuss it f2f before finalizing the > charter. > > and MHO is we're still a ways away from enough consensus to declare work on > the charter "done". > > On Feb 21, 2009, at 1:14 AM, Gareth Nelson wrote: > >> So, why don't we get on with voting on a charter? >> As for discussing implementation details now - nothing wrong with >> doing so if it's in the same basic area as the formal working group >> would be >> >> On Sat, Feb 21, 2009 at 8:18 AM, Dan Olivares >> wrote: > From infinity@lindenlab.com Sat Feb 21 02:07:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787593A6989 for ; Sat, 21 Feb 2009 02:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxw5FJ-eYVbM for ; Sat, 21 Feb 2009 02:07:38 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id A48E93A67D9 for ; Sat, 21 Feb 2009 02:07:38 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 4CAB91414001; Sat, 21 Feb 2009 02:07:54 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <499FB5C8.4030900@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 02:07:51 -0800 References: <62BFE5680C037E4DA0B0A08946C0933D50263405@rrsmsx506.amr.corp.intel.com> <499FB5C8.4030900@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] My evaluation of LLSD+LLIDL X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 10:07:39 -0000 xdr is a presentation layer construction, not an abstract type system. for instance, it provides no guidance for conversion between basic abstract types. the role of LLSD in OGP is two fold: 1. to provide a mechanism for reasoning about the semantics of fields in protocol messages (which is why we have URI, UUID and Date type as distinct from type String) 2. to (un)marshall protocol messages into one of a number serialization formats. the selection of XML and JSON as two of the serialization formats in the LLSD draft is not a mistake. there is a well developed ecosystem of tools for the manipulation of XML data and streams. we also see a future that integrates the virtual world with the web; JSON is far easier to consume in AJAXish applications than XDR. that being said... an XDR serialization of LLSD is certainly possible, On Feb 21, 2009, at 12:05 AM, Jon Watte wrote: > Hurliman, John wrote: >> Linden Lab Structured Data by itself provides an abstract type >> system. This defines a fixed > > As does XDR, by the way. XDR is well understood, very widespread, > and has been in use (including some very common Internet protocols) > for the last 20 years. XDR is also an accepted IETF RFC. Others have > pointed out other existing data serialization/encoding standards > that already exist and are standardized. However, I think all that > is beside the point. > > Honestly, I really do think we should start with the overall basics > of agreeing on requirements, then agreeing on a model of > interoperability, before we even start thinking about adopting, > adapting, or introducing things like data format specifications. I > think the discussion of LLSD on this list is, at best, premature, > and at worst, adds noise at this juncture. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Sat Feb 21 02:14:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04FCC3A6989 for ; Sat, 21 Feb 2009 02:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.207 X-Spam-Level: X-Spam-Status: No, score=-3.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bg7X22gTXSY for ; Sat, 21 Feb 2009 02:14:08 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 54C283A67D9 for ; Sat, 21 Feb 2009 02:14:08 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id F04B01414001; Sat, 21 Feb 2009 02:14:23 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Gareth Nelson In-Reply-To: <61dbdd7d0902210159u5b597d73j1829656935321069@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 02:14:21 -0800 References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> <61dbdd7d0902210159u5b597d73j1829656935321069@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 10:14:09 -0000 well... we are planning on broadcasting video of the event via RTSP so it's consumable by qwaq, second life and osgrid / open sim regions. and we're busy trying to put everything in place to allow communication from these worlds into the face to face meeting. so you're not completely out of luck. and... i am confident conversation will continue after the f2f on the mailing list before we declare general consensus achieved. -cheers -meadhbh On Feb 21, 2009, at 1:59 AM, Gareth Nelson wrote: > Well, i'm out of luck then, being on a whole other continent from > all you guys. > How much consensus do we need to build a charter? Surely the consensus > on implementation details is different from consensus on what we're > actually doing here? > > On Sat, Feb 21, 2009 at 9:55 AM, Meadhbh Hamrick (Infinity) > wrote: >> hey gareth... >> >> i think the IETF policy is we want to discuss it f2f before >> finalizing the >> charter. >> >> and MHO is we're still a ways away from enough consensus to declare >> work on >> the charter "done". >> >> On Feb 21, 2009, at 1:14 AM, Gareth Nelson wrote: >> >>> So, why don't we get on with voting on a charter? >>> As for discussing implementation details now - nothing wrong with >>> doing so if it's in the same basic area as the formal working group >>> would be >>> >>> On Sat, Feb 21, 2009 at 8:18 AM, Dan Olivares >>> wrote: >> From lenglish5@cox.net Sat Feb 21 02:35:42 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF21B3A697F for ; Sat, 21 Feb 2009 02:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qV3lYLHRNjK for ; Sat, 21 Feb 2009 02:35:42 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 0FBDD3A6883 for ; Sat, 21 Feb 2009 02:35:41 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090221103558.RBCV10385.fed1rmmtao107.cox.net@fed1rmimpo01.cox.net>; Sat, 21 Feb 2009 05:35:58 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id Jabx1b0014N6T0Q03abxup; Sat, 21 Feb 2009 05:35:57 -0500 X-Authority-Analysis: v=1.0 c=1 a=cLXfh73VNe8A:10 a=PQp3fo3PBBsA:10 a=Wajolswj7cQA:10 a=9PA3dU3QqwZ5YMS5g1cA:9 a=21bPvXiblfQhdme9sLgA:7 a=PS90A_B605k9cmHL_M7piryXPY4A:4 a=72oxJoRhc8oA:10 a=AnAIffsURemKz08j:21 a=xjQLU6PJqkAPh0NB:21 X-CM-Score: 0.00 Message-ID: <499FD90D.4000407@cox.net> Date: Sat, 21 Feb 2009 03:35:57 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> <61dbdd7d0902210159u5b597d73j1829656935321069@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 10:35:43 -0000 Meadhbh Hamrick (Infinity) wrote: > well... we are planning on broadcasting video of the event via RTSP so > it's consumable by qwaq, second life and osgrid / open sim regions. > > and we're busy trying to put everything in place to allow > communication from these worlds into the face to face meeting. > > so you're not completely out of luck. > > and... i am confident conversation will continue after the f2f on the > mailing list before we declare general consensus achieved. It seems to me that some aspect of "virtualization" of the MMOX BOF meeting can be extended after that meeting, as well. If we can take video, audio presence and distribute it to 3 different worlds (and a webpage) and hopefully take the video/audio/chat presence from each world and make it available in the RL meeting and in the other worlds, there's no reason why we can't hold regular in-world meetings in multiple worlds at the same time with a virtual video conferencing system, bypassing the RL meeting entirely. Would this be worth doing? Seems that it would be, simply as an ongoing test of what we're heading toward which would encourage refinement and collaboration in order to make even that primitive virtual video conference better and hopefully help us learn more about less obvious interop issues while we're doing it. Besides it would be just plain fun, IMHO. Certainly, Metanomics and Science Friday would embrace a multi-world venue and publicize it for us (1.25 million NPR listeners hearing about mmox every week can't be a bad thing, eh?) and hopefully get more people interested in contributing to the project. Lawson From morgaine.dinova@googlemail.com Sat Feb 21 03:10:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04B23A6AA0 for ; Sat, 21 Feb 2009 03:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SwmbQpfMJ4k for ; Sat, 21 Feb 2009 03:10:10 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 5318A3A69C7 for ; Sat, 21 Feb 2009 03:10:10 -0800 (PST) Received: by bwz5 with SMTP id 5so3399844bwz.13 for ; Sat, 21 Feb 2009 03:10:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yZojmuRxhH2vFd2BKmnNCHUh5FV2pvoE6ckFA8nvLKs=; b=AU60mD0Iii6R0JV6jRdzG1Q2V75Vjkmk5K8jl95P/mY5hu0+zsNnWwSKROsyD12A53 kOZWtZj1/NsoRlq3hWemcV1SL/11JwS+f0hMkMOI+LMJ36qpHTKbGZxPQhD7Y6EkLp7Y EXyGYwPe+LM10j4PpzlEM1vo6E6WM7uGwJK7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EliSOGjBcBcfX6EhOhjXG0Wow703tNR3HFqXgVsYNLScfVuYjNDIDmNMNKaucSPFFS WFCBglYiMbav8QeBoR/NLVehVy8QJ89QyWkJDJM21RwDBkf3J+/gNjNm5wqR4t9prFQb CcJ4jmHcYeBkWOo5DcZV8szVcmIWvxAxGg3H8= MIME-Version: 1.0 Received: by 10.181.138.13 with SMTP id q13mr661511bkn.42.1235214623934; Sat, 21 Feb 2009 03:10:23 -0800 (PST) In-Reply-To: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> Date: Sat, 21 Feb 2009 11:10:23 +0000 Message-ID: From: Morgaine To: Gareth Nelson Content-Type: multipart/alternative; boundary=001485f85a94e18b0d04636bd0bf Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 11:10:11 -0000 --001485f85a94e18b0d04636bd0bf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 9:14 AM, Gareth Nelson wrote: So, why don't we get on with voting on a charter? > As for discussing implementation details now - nothing wrong with > doing so if it's in the same basic area as the formal working group > would be > That work has already started, Gareth, although the discussion might have preceded your joining the list. :-) To help your navigation, I'll unpick the messy email threading for you: 1) John Hurliman first pointed out the inappropriateness of references to OGP in the charter of a workgroup whose mission it is to examine what is appropriate in the first place: http://www.ietf.org/mail-archive/web/mmox/current/msg00012.html 2) I agreed, and affirmed that we are definitely not here to rubberstamp Linden proposals, and hence that we should start immediately on improving the charter: http://www.ietf.org/mail-archive/web/mmox/current/msg00013.html 3) Infinity responded extremely positively and noted that the initial draft was highly LL/IBM-specific since they were the two authors of the draft, but invited John and myself (and everyone else on the list of course) to submit concrete proposals for improvements: http://www.ietf.org/mail-archive/web/mmox/current/msg00015.html 4) I responded with an offer to help directly: http://www.ietf.org/mail-archive/web/mmox/current/msg00016.html 5) Based off the LL/IBM original (#1), John provided the first improved draft charter (#2): http://www.ietf.org/mail-archive/web/mmox/current/msg00032.html 6) Based off John's draft #2, I made improvements for clarity and removed an ambiguity, to give us draft #3: http://www.ietf.org/mail-archive/web/mmox/current/msg00036.html 7) Infinity and I then exchanged several emails in the list to narrow down whether the word "proprietary" was substantive, or just a residue from the initial version. The clear conclusion was that it was *highly* substantive, and therefore I further modified my version with a clear statement that we are in the business of defining open, non-proprietary standards, which became draft #4: http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html There have been no specific updates since then. Needless to say, if you or anyone else requires further changes, then pick up the baton and run with it! I look forward to draft #5. :-) I am sure the text will undergo numerous further iterations before we finally agree on an effective charter that can be passed at the BoF. The MMOX list is currently examining other issues, but it is certain to return to the charter as the BoF draws nearer. Morgaine. --001485f85a94e18b0d04636bd0bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 21, 2009 at 9:14 AM, Gareth = Nelson <gareth@l= itesim.com> wrote:

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


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

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

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

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

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

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

5) Based off the = LL/IBM original (#1), John provided the first improved draft charter (#2):&= nbsp; http://www.ietf.org/mail-archive/web/mmox/current/msg00032.html<= br>
6) Based off John's draft #2, I made improvements for clarity and r= emoved an ambiguity, to give us draft #3:  http://www.ietf.org/mail-a= rchive/web/mmox/current/msg00036.html

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

There have been no specific updates since then.

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

I am sure the te= xt will undergo numerous further iterations before we finally agree on an e= ffective charter that can be passed at the BoF.  The MMOX list is curr= ently examining other issues, but it is certain to return to the charter as= the BoF draws nearer.

Morgaine.

--001485f85a94e18b0d04636bd0bf-- From gareth@litesim.com Sat Feb 21 03:22:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC1B3A6A7C for ; Sat, 21 Feb 2009 03:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3DxZXFbGdwi for ; Sat, 21 Feb 2009 03:22:44 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id CBBD53A69C7 for ; Sat, 21 Feb 2009 03:22:44 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1209637rvb.49 for ; Sat, 21 Feb 2009 03:22:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.209.6 with SMTP id l6mr935326rvq.192.1235215378914; Sat, 21 Feb 2009 03:22:58 -0800 (PST) In-Reply-To: References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> Date: Sat, 21 Feb 2009 11:22:58 +0000 Message-ID: <61dbdd7d0902210322g3ac1e9d3na94284a3ca90504f@mail.gmail.com> From: Gareth Nelson To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 11:22:45 -0000 Thanks for the overview :) My only comment with a quick glance is regarding this: "c) allow network layers to recognize VW traffic and make routing decisions based on its characteristics." Is client<>server traffic for individual worlds not primarily something for individual worlds rather than an interop issue? For example, you might be on world A, and talking to world B via world A's servers, but your client<>server traffic is still running A's protocol. At the server<>server end is this kind of QoS actually useful? On Sat, Feb 21, 2009 at 11:10 AM, Morgaine wrote: > > > On Sat, Feb 21, 2009 at 9:14 AM, Gareth Nelson wrote: > >> So, why don't we get on with voting on a charter? >> As for discussing implementation details now - nothing wrong with >> doing so if it's in the same basic area as the formal working group >> would be > > > That work has already started, Gareth, although the discussion might have > preceded your joining the list. :-) > > To help your navigation, I'll unpick the messy email threading for you: > > 1) John Hurliman first pointed out the inappropriateness of references to > OGP in the charter of a workgroup whose mission it is to examine what is > appropriate in the first place: > http://www.ietf.org/mail-archive/web/mmox/current/msg00012.html > > 2) I agreed, and affirmed that we are definitely not here to rubberstamp > Linden proposals, and hence that we should start immediately on improving > the charter: > http://www.ietf.org/mail-archive/web/mmox/current/msg00013.html > > 3) Infinity responded extremely positively and noted that the initial draft > was highly LL/IBM-specific since they were the two authors of the draft, but > invited John and myself (and everyone else on the list of course) to submit > concrete proposals for improvements: > http://www.ietf.org/mail-archive/web/mmox/current/msg00015.html > > 4) I responded with an offer to help directly: > http://www.ietf.org/mail-archive/web/mmox/current/msg00016.html > > 5) Based off the LL/IBM original (#1), John provided the first improved > draft charter (#2): > http://www.ietf.org/mail-archive/web/mmox/current/msg00032.html > > 6) Based off John's draft #2, I made improvements for clarity and removed an > ambiguity, to give us draft #3: > http://www.ietf.org/mail-archive/web/mmox/current/msg00036.html > > 7) Infinity and I then exchanged several emails in the list to narrow down > whether the word "proprietary" was substantive, or just a residue from the > initial version. The clear conclusion was that it was highly substantive, > and therefore I further modified my version with a clear statement that we > are in the business of defining open, non-proprietary standards, which > became draft #4: > http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html > > There have been no specific updates since then. > > Needless to say, if you or anyone else requires further changes, then pick > up the baton and run with it! I look forward to draft #5. :-) > > I am sure the text will undergo numerous further iterations before we > finally agree on an effective charter that can be passed at the BoF. The > MMOX list is currently examining other issues, but it is certain to return > to the charter as the BoF draws nearer. > > Morgaine. > > From gareth@litesim.com Sat Feb 21 03:25:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB3E3A6A7C for ; Sat, 21 Feb 2009 03:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqBxlFVbD-es for ; Sat, 21 Feb 2009 03:25:23 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id CF71E3A69C7 for ; Sat, 21 Feb 2009 03:25:23 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1210011rvb.49 for ; Sat, 21 Feb 2009 03:25:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.136.4 with SMTP id o4mr947850rvn.13.1235215537174; Sat, 21 Feb 2009 03:25:37 -0800 (PST) In-Reply-To: <61dbdd7d0902210322g3ac1e9d3na94284a3ca90504f@mail.gmail.com> References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> <61dbdd7d0902210322g3ac1e9d3na94284a3ca90504f@mail.gmail.com> Date: Sat, 21 Feb 2009 11:25:37 +0000 Message-ID: <61dbdd7d0902210325n69f8bec1t5e029ace2d5d7f40@mail.gmail.com> From: Gareth Nelson To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 11:25:25 -0000 2 more comments (Apologies for the multiple replies style, it's a bit of a habit) October 2009 Publication of LLSD Draft as an Informational RF Is there a reason this milestone is set so late? LLSD is already fairly well defined. I would go so far as to say that the existing specs and code can be RFC-alised as-is with only some subtle changes as compatibility dictates. On Sat, Feb 21, 2009 at 11:22 AM, Gareth Nelson wrote: > Thanks for the overview :) > My only comment with a quick glance is regarding this: > > "c) allow network layers to recognize VW traffic and make routing > decisions based on its characteristics." > > Is client<>server traffic for individual worlds not primarily > something for individual worlds rather than an interop issue? > For example, you might be on world A, and talking to world B via world > A's servers, but your client<>server traffic is still running A's > protocol. At the server<>server end is this kind of QoS actually > useful? > > On Sat, Feb 21, 2009 at 11:10 AM, Morgaine > wrote: >> >> >> On Sat, Feb 21, 2009 at 9:14 AM, Gareth Nelson wrote: >> >>> So, why don't we get on with voting on a charter? >>> As for discussing implementation details now - nothing wrong with >>> doing so if it's in the same basic area as the formal working group >>> would be >> >> >> That work has already started, Gareth, although the discussion might have >> preceded your joining the list. :-) >> >> To help your navigation, I'll unpick the messy email threading for you: >> >> 1) John Hurliman first pointed out the inappropriateness of references to >> OGP in the charter of a workgroup whose mission it is to examine what is >> appropriate in the first place: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00012.html >> >> 2) I agreed, and affirmed that we are definitely not here to rubberstamp >> Linden proposals, and hence that we should start immediately on improving >> the charter: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00013.html >> >> 3) Infinity responded extremely positively and noted that the initial draft >> was highly LL/IBM-specific since they were the two authors of the draft, but >> invited John and myself (and everyone else on the list of course) to submit >> concrete proposals for improvements: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00015.html >> >> 4) I responded with an offer to help directly: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00016.html >> >> 5) Based off the LL/IBM original (#1), John provided the first improved >> draft charter (#2): >> http://www.ietf.org/mail-archive/web/mmox/current/msg00032.html >> >> 6) Based off John's draft #2, I made improvements for clarity and removed an >> ambiguity, to give us draft #3: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00036.html >> >> 7) Infinity and I then exchanged several emails in the list to narrow down >> whether the word "proprietary" was substantive, or just a residue from the >> initial version. The clear conclusion was that it was highly substantive, >> and therefore I further modified my version with a clear statement that we >> are in the business of defining open, non-proprietary standards, which >> became draft #4: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html >> >> There have been no specific updates since then. >> >> Needless to say, if you or anyone else requires further changes, then pick >> up the baton and run with it! I look forward to draft #5. :-) >> >> I am sure the text will undergo numerous further iterations before we >> finally agree on an effective charter that can be passed at the BoF. The >> MMOX list is currently examining other issues, but it is certain to return >> to the charter as the BoF draws nearer. >> >> Morgaine. >> >> > From lenglish5@cox.net Sat Feb 21 04:04:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3603A6AD6 for ; Sat, 21 Feb 2009 04:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.82 X-Spam-Level: X-Spam-Status: No, score=0.82 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSEmNesHhgwC for ; Sat, 21 Feb 2009 04:04:08 -0800 (PST) Received: from fed1rmmtao105.cox.net (fed1rmmtao105.cox.net [68.230.241.41]) by core3.amsl.com (Postfix) with ESMTP id B00913A6C39 for ; Sat, 21 Feb 2009 04:04:08 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090221120425.SOMZ15318.fed1rmmtao105.cox.net@fed1rmimpo03.cox.net>; Sat, 21 Feb 2009 07:04:25 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id Jc4Q1b0014N6T0Q04c4Qal; Sat, 21 Feb 2009 07:04:24 -0500 X-Authority-Analysis: v=1.0 c=1 a=cLXfh73VNe8A:10 a=PQp3fo3PBBsA:10 a=Wajolswj7cQA:10 a=XLNHbFYT0cI0Xel8AloA:9 a=zu0eMBrP9DIhdk-2mIFyPCwr_d0A:4 a=6UxOEEjT9BUA:10 X-CM-Score: 0.00 Message-ID: <499FEDC7.5060509@cox.net> Date: Sat, 21 Feb 2009 05:04:23 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gareth Nelson References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> <61dbdd7d0902210322g3ac1e9d3na94284a3ca90504f@mail.gmail.com> <61dbdd7d0902210325n69f8bec1t5e029ace2d5d7f40@mail.gmail.com> In-Reply-To: <61dbdd7d0902210325n69f8bec1t5e029ace2d5d7f40@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 12:04:09 -0000 Gareth Nelson wrote: > 2 more comments (Apologies for the multiple replies style, it's a bit > of a habit) > > October 2009 Publication of LLSD Draft as an Informational RF > > Is there a reason this milestone is set so late? LLSD is already > fairly well defined. I would go so far as to say that the existing > specs and code can be RFC-alised as-is with only some subtle changes > as compatibility dictates. > Given the friction that has arisen merely over the name "LL" I think that we're a bit far from getting the protocol even semi-ready. Some want to scratch developing something new and go with an existing standard just because it is a standard. LLSD is a standard as well, but only used by a handful of companies (with probably as many as a million or two active users though). Lawson From cathypfeffer@gmail.com Sat Feb 21 05:28:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12AB83A6AF3 for ; Sat, 21 Feb 2009 05:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOBSie75rWmx for ; Sat, 21 Feb 2009 05:28:39 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id C45213A6805 for ; Sat, 21 Feb 2009 05:28:38 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so211161eya.31 for ; Sat, 21 Feb 2009 05:28:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=WuyXXC9GA9vQefBuwFXMFxcrhpTJhbOHPlEx0eSWdfw=; b=EK5N44bh80Cis7VFN48gaIkn3dU6t1VRKptF6UVBEKaGe1GffAss4tXvARmRg1zXFE JiJ0OJPKrZldSBc1hVxIn15qlLTqQ5Y78KlVIgPxhlwKiNE43/y4Pzq5Fsl3j2LqpplF GMFxjAfiGx33yX2yLnwL9jIKBoqj9Vzr89wQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=skyR5v068V9IJ5LES1La+B1jxurC4sVhTqwYxjxqhjNy7PXQ7UGggkpIQAV3EyXcBC lv2MQdOxWFUl9ZYDzPrB2Efik57bwe6k+8Ap8Bye/+VerY4+hAyhFGjSmCGV8L76aPVt 9b+ylMgIKRfD8Tie1z0Cet2rmtLbV7qX6WCko= MIME-Version: 1.0 Received: by 10.210.16.10 with SMTP id 10mr1594951ebp.80.1235222932928; Sat, 21 Feb 2009 05:28:52 -0800 (PST) Date: Sat, 21 Feb 2009 14:28:52 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=000e0cd1ea6e22b9b904636dc0a3 Subject: [mmox] Schedule for marshalling / unmarshalling foundation X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 13:28:40 -0000 --000e0cd1ea6e22b9b904636dc0a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Gareth said: > October 2009 Publication of LLSD Draft as an Informational RFC > > Is there a reason this milestone is set so late? LLSD is already > fairly well defined. I would go so far as to say that the existing > specs and code can be RFC-alised as-is with only some subtle changes > as compatibility dictates. Perharps October is a bit far away for this, yes. But some people have expressed serious concerns about details like all integers being 32 bits and signed. I think that simply rubberstamping "existing specs and code" would be a mistake. There is not even an agreement on the xxSD name. Not to say there is still an ongoing debate about whether LLSD is the way to go, or whether an existing mechanism like ASN should be preferred. Even though I think LLSD has a lot of merits, I think such questioning should not be evacuated with the back of the hand. As for the attempt to eject pseudonymous users like me from this mailing list. it is not appreciated. While I recognize IETF will never provide attribution for intellectual material suggested by anonymous and pseudonymous users, I think that external persons who have no business interests in this all affair but only their love for virtual worlds and intellectual honesty to bring in should be allowed to lurk and comment on this mailing list. -- Cathy --000e0cd1ea6e22b9b904636dc0a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gareth said:
> October 2009  Publication of LLSD Draft as an Inf= ormational RFC
>
> Is there a reason this milestone is set so l= ate? LLSD is already
> fairly well defined. I would go so far as to s= ay that the existing
> specs and code can be RFC-alised as-is with only some subtle changes> as compatibility dictates.

Perharps October is a bit far away= for this, yes. But some people have expressed serious concerns about detai= ls like all integers being 32 bits and signed. I think that simply rubberst= amping "existing specs and code" would be a mistake. There is not= even an agreement on the xxSD name. Not to say there is still an ongoing d= ebate about whether LLSD is the way to go, or whether an existing mechanism= like ASN should be preferred. Even though I think LLSD has a lot of merits= , I think such questioning should not be evacuated with the back of the han= d.

As for the attempt to eject pseudonymous users like me from this mailin= g list. it is not appreciated. While I recognize IETF will never provide at= tribution for intellectual material suggested by anonymous and pseudonymous= users, I think that external persons who have no business interests in thi= s all affair but only their love for virtual worlds and intellectual honest= y to bring in should be allowed to lurk and comment on this mailing list.
--
Cathy
--000e0cd1ea6e22b9b904636dc0a3-- From morgaine.dinova@googlemail.com Sat Feb 21 05:48:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ED113A6AA2 for ; Sat, 21 Feb 2009 05:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3E2kTjZa8lh for ; Sat, 21 Feb 2009 05:48:36 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 11D4A3A6805 for ; Sat, 21 Feb 2009 05:48:35 -0800 (PST) Received: by bwz5 with SMTP id 5so3476693bwz.13 for ; Sat, 21 Feb 2009 05:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MgCRylfYJwAiWdvC/GT5/7EJGHh2WlyQ7TVM25rLSJU=; b=uzRg4ex5756Iso7CEWI51+AS1eMZOMbVx6dA3VzDOHoo+UsaMIs7O5ZBjXq/bTX0xI xUCuZuUytPWAK0YyLiJ98rHBlFKSvb/Eegwn6af1XpSBcBmMPI9I4jKWXjMtcBvZnjfA 4t45TX501Z2vqSw1yo1546WHlawFhxpr3Wi5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CQLxZimjd0Y5h3zkTCSopSVvcZBy1f5tAernkQ+BkDzouK8n+G8aXoE/LQ8xyeWH6/ x0+B/xvK4amaSPwRitiJRMF5PyjFyza3tbKJ+upjL1wZl4RL7Ga1Ns+v6b53Qzd2GPyd /wwkkJTggnWMMoLVmCFmMHSvZMQi0F7maLJUQ= MIME-Version: 1.0 Received: by 10.181.61.2 with SMTP id o2mr708487bkk.49.1235224130324; Sat, 21 Feb 2009 05:48:50 -0800 (PST) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D50263405@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D50263405@rrsmsx506.amr.corp.intel.com> Date: Sat, 21 Feb 2009 13:48:50 +0000 Message-ID: From: Morgaine To: "Hurliman, John" Content-Type: multipart/alternative; boundary=001636498e5181886f04636e07cf Cc: "mmox@ietf.org" , "opensim-dev@lists.berlios.de" Subject: Re: [mmox] My evaluation of LLSD+LLIDL X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 13:48:37 -0000 --001636498e5181886f04636e07cf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 2:20 AM, Hurliman, John wrote: > > * There is no clear benefit to standardizing on conversions at the abstract > type level instead of the serialization level. Doing so removes the ability > to enforce data contracts at compile time > That's true of LLSD because of the ambiguities that result from its unhelpfully small set of types which denies effective 1:1 mapping between programs and on-the-wire representations (and possibly other reasons too). I think you would find a lot of aggreement that LLSD as it stands is not adequate, but we never expected it to be --- it's an SL standard, after all. The problem can be fixed by modifying LLSD to meet our broader requirements, or replacing it if deemed appropriate. On the question of the benefit of standardizing on conversions at the abstract type level instead of the serialization level, there are three absolutely key benefits: 1. Independence of programs from the on-the-wire format; 2. Ability to switch the wire format dynamically and to support multiple formats simultaneously on different channels from the same code base; and 3. Ability to use interface generation/validation tools and to write marshalling systems that are independent of the wire format. These are highly tangible benefits that promote broad acceptance of a protocol standard simply by being all-embracing at the on-the-wire level. But it goes much further than that, because of the strong engineering benefits that come from better toolset longevity and from allowing the wire formats to evolve and improve without impacting the code base. Multiple serializations is a benefit that should not be lost, and consequently we need some way of programming to an abstract interface. I am not wedded to LLSD though. Given an alternative that provides these same benefits and is also better in some area, I would happily support it. Morgaine. --001636498e5181886f04636e07cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 21, 2009 at 2:20 AM, Hurlima= n, John <jo= hn.hurliman@intel.com> wrote:
 
* There is no clear benefit to standardizing on conversions at the abstract= type level instead of the serialization level. Doing so removes the abilit= y to enforce data contracts at compile time
 

That's true of LLSD because of = the ambiguities that result from its unhelpfully small set of types which d= enies effective 1:1 mapping between programs and on-the-wire representation= s (and possibly other reasons too).  I think you would find a lot of a= ggreement that LLSD as it stands is not adequate, but we never expected it = to be --- it's an SL standard, after all.  The problem can be fixe= d by modifying LLSD to meet our broader requirements, or replacing it if de= emed appropriate.


On the question of the benefit of standardizing on conversions at t= he abstract type level instead of the serialization level, there are three = absolutely key benefits:
  1. Independence of programs from the on-th= e-wire format;
  2. Ability to switch the wire format dynamically and to support multiple formats simultaneously on different channels from the same code base;  and
  3. Ability to use interface generation/validation= tools and to write marshalling systems that are independent of the wire fo= rmat.
These are highly tangible benefits that promote broad ac= ceptance of a protocol standard simply by being all-embracing at the on-the= -wire level.  But it goes much further than that, because of the stron= g engineering benefits that come from better toolset longevity and from all= owing the wire formats to evolve and improve without impacting the code bas= e.

Multiple serializations is a benefit that should not be lost, and conse= quently we need some way of programming to an abstract interface.

I = am not wedded to LLSD though.  Given an alternative that provides thes= e same benefits and is also better in some area, I would happily support it= .

Morgaine.
--001636498e5181886f04636e07cf-- From tme@multicasttech.com Sat Feb 21 06:12:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5C73A6C43 for ; Sat, 21 Feb 2009 06:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2x9IjAj4Xkj0 for ; Sat, 21 Feb 2009 06:12:23 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 901CD3A6887 for ; Sat, 21 Feb 2009 06:12:23 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14731695; Sat, 21 Feb 2009 09:10:48 -0500 Message-Id: <6DC14F5E-9AE6-4CAC-9547-581C0DA35109@multicasttech.com> From: Marshall Eubanks To: Gareth Nelson In-Reply-To: <61dbdd7d0902210159u5b597d73j1829656935321069@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 09:12:38 -0500 References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> <61dbdd7d0902210159u5b597d73j1829656935321069@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 14:12:24 -0000 On Feb 21, 2009, at 4:59 AM, Gareth Nelson wrote: > Well, i'm out of luck then, being on a whole other continent from > all you guys. Face to face meetings are good, but in the IETF all decisions are made on the mailing lists, as that is where consensus is determined. Note, too, that even without virtual presentations of the IETF meetings there are audio feeds and jabber rooms, and should be jabber scribes, for all sessions, and many sessions have active remote participants. Regards Marshall > > How much consensus do we need to build a charter? Surely the consensus > on implementation details is different from consensus on what we're > actually doing here? > > On Sat, Feb 21, 2009 at 9:55 AM, Meadhbh Hamrick (Infinity) > wrote: >> hey gareth... >> >> i think the IETF policy is we want to discuss it f2f before >> finalizing the >> charter. >> >> and MHO is we're still a ways away from enough consensus to declare >> work on >> the charter "done". >> >> On Feb 21, 2009, at 1:14 AM, Gareth Nelson wrote: >> >>> So, why don't we get on with voting on a charter? >>> As for discussing implementation details now - nothing wrong with >>> doing so if it's in the same basic area as the formal working group >>> would be >>> >>> On Sat, Feb 21, 2009 at 8:18 AM, Dan Olivares >>> wrote: >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From morgaine.dinova@googlemail.com Sat Feb 21 07:04:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287123A6843 for ; Sat, 21 Feb 2009 07:04:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8KPMfL5t2zZ for ; Sat, 21 Feb 2009 07:04:48 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 9D81A3A69F2 for ; Sat, 21 Feb 2009 07:04:44 -0800 (PST) Received: by bwz5 with SMTP id 5so3511952bwz.13 for ; Sat, 21 Feb 2009 07:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=38iJLq5ooYkU59DMncMibWwacFun5uzlTpdzrKFwJuE=; b=F5/m4sYZRh5dgtOk9T+l6BY9WX2PmsPQRdQUDnThtlBdWiCe++fEWDXcse/cDxHY0v bfor06a0gCLt0/yo2cJib3HL+eWvkCjkVy0KWlta5OuGkyJxcSLNhXPxXzoOByOPUs/d MZs7xHPKVfeeoyfW58gvkJ6pFAISVnI1Ugv6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wna+YjBowknLNPtDrHNaYsEhX5M0ESzhHB02BQ0egermajhd8dZDvhWmtyZ4R5uXzi /HLYbW86FI1QFluxJLgzSSXumgUitf56Ag1iormWeansvf914KTNOsJ7Biv/hilZ2bfa QXyItldVPopa//iAcPNpfiVYSjJ71QcpGzodE= MIME-Version: 1.0 Received: by 10.181.227.9 with SMTP id e9mr721800bkr.133.1235228698159; Sat, 21 Feb 2009 07:04:58 -0800 (PST) In-Reply-To: <873917.52772.qm@web82607.mail.mud.yahoo.com> References: <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <873917.52772.qm@web82607.mail.mud.yahoo.com> Date: Sat, 21 Feb 2009 15:04:58 +0000 Message-ID: From: Morgaine To: Charles Krinke Content-Type: multipart/alternative; boundary=001636c5a73dc52c5204636f17b4 Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 15:04:49 -0000 --001636c5a73dc52c5204636f17b4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 2:00 AM, Charles Krinke wrote: > > So, to me, the debate about creating a new architecture is somewhat moot. > Very moot. :-) Indeed, it puzzles me why the debate has even arisen, since creating a new architecture has not been proposed by anyone. The draft charter has made it clear that the goal is much simpler and less prescriptive, and very vendor-neutral after some iterations. As this issue of architecture keeps coming up, I'll just reiterate a paragraph that I wrote for Jon which came out better than I expected. It shows the narrow but still helpful avenue we are pursuing towards interop, devoid of any prescriptive implementations and certainly no new architectures: "*In my own words and very much off the cuff, we are defining a protocol that allows entirely different virtual worlds to access and exchange data objects that are meaningful across a large spectrum of world types. This is achieved by limiting the protocol to common concepts such as login (for identity), location, teleport, travel, avatars, and messaging, as well as offering an extensible set of common 3D objects as building blocks that can be exchanged. It is a strongly abstracted approach, as independent of actual implementation details as we can make it, because there is no other way to embrace the current diversity of worlds let alone the future one.*" I don't think that I can improve on that. But no doubt others can. ;-) Morgaine. --001636c5a73dc52c5204636f17b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 21, 2009 at 2:00 AM, Charles= Krinke <cfk@pacbel= l.net> wrote:

So, to me, the debate about creating a new architecture is some= what moot.
 

Very moot. :-)

Indeed, it puzzles me why the debate has even arisen, since creating a = new architecture has not been proposed by anyone.  The draft charter h= as made it clear that the goal is much simpler and less prescriptive, and v= ery vendor-neutral after some iterations.

As this issue of architecture keeps coming up, I'll just reiterate = a paragraph that I wrote for Jon which came out better than I expected.&nbs= p; It shows the narrow but still helpful avenue we are pursuing towards int= erop, devoid of any prescriptive implementations and certainly no new archi= tectures:

"In my own words and very much off the cuff, we are defining a = protocol that allows entirely different virtual worlds to access and exchange data objects that are meaningful across a large spectrum of world types.  This is achieved by limiting the protocol to common concepts such as login (for identity), location, teleport, travel, avatars, and messaging, as well as offering an extensible set of common 3D objects as building blocks that can be exchanged.  It is a strongly abstracted approach, as independent of actual implementation details as we can make it, because there is no other way to embrace the current diversity of worlds let alone the future one."

I don't think that= I can improve on that.  But no doubt others can. ;-)

Morgaine.=
--001636c5a73dc52c5204636f17b4-- From cs@comlounge.net Sat Feb 21 09:00:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059CC3A693E for ; Sat, 21 Feb 2009 09:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulXi4gQ7ixr9 for ; Sat, 21 Feb 2009 09:00:35 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 3405D3A68F0 for ; Sat, 21 Feb 2009 09:00:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id A05E06F405A; Sat, 21 Feb 2009 18:00:49 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTLY-b+gvh0Y; Sat, 21 Feb 2009 18:00:48 +0100 (CET) Received: from [192.168.178.34] (pD9EBF278.dip.t-dialin.net [217.235.242.120]) by post.comlounge.net (Postfix) with ESMTP id 9CF6B1CE0001; Sat, 21 Feb 2009 18:00:46 +0100 (CET) Message-ID: <49A0333B.2050407@comlounge.net> Date: Sat, 21 Feb 2009 18:00:43 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Hurliman, John" References: <1E40CE05-15D1-4970-9B0F-CD4AD11A074A@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D501FDC38@rrsmsx506.amr.corp.intel.com> <499C5415.7060400@cox.net> <62BFE5680C037E4DA0B0A08946C0933D501FE124@rrsmsx506.amr.corp.intel.com> <2bd5b7f10902181356l64dd8366n2b5e57ef4242ae0f@mail.gmail.com> <676211.48955.qm@web82608.mail.mud.yahoo.com> <499CA916.1090008@gmail.com> <488F29D4-F071-4725-B1B6-FFC17C220F8D@duke.edu> <62BFE5680C037E4DA0B0A08946C0933D501FE800@rrsmsx506.amr.corp.intel.com> <499DE5A4.50705@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D502630AC@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D502630AC@rrsmsx506.amr.corp.intel.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] where is identity @ in all this? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 17:00:37 -0000 Hurliman, John wrote: >> -----Original Message----- From: Christian Scholz >> [mailto:cs@comlounge.net] Sent: Thursday, February 19, 2009 3:05 PM >> To: Hurliman, John Cc: mmox@ietf.org Subject: Re: [mmox] where is >> identity @ in all this? >> >> Hurliman, John schrieb: >>> That is the identity proposal I'm working on. OpenID + OpenID >>> Token >> Exchange* + OpenID Attribute Exchange == VW Identity Service. >>> * OAuth was specifically designed for a three legged scenario, >>> and >> when you start adding in more services such as content, messaging, >> voice, etc. it no longer becomes feasible. OpenID Token Exchange >> solves this problem nicely though. >> >> Can you elaborate what the specific problem with OAuth is? Is it >> that you'd need to authorize each and every service as a user? (the >> same problem is coming up on the web as well though if you think >> about data in all sorts of places you might want to give somebody >> access to) >> > > OAuth seems to be solving a different problem. OAuth is great for > putting identity+authorization into a token, but in many cases (at > least in the virtual world scenario) your identity provider and the > authorization provider for a resource are two separate domains. What > is needed is a way to pass around identity in a token, which is what > the OpenID Token Exchange protocol does. The fact that every > authorized token request in OAuth flows through the end user is great > for authorization requests and the use cases it was designed for, but > makes it a non starter for providing a temporary identity-only token > between services. In my understanding OAuth[1] is actually meant to just do authorization, not authentication and is invented for the case that your identity provider and authorization provider is in fact not the same service. It basically lets service A access resources of service B on behalf of the user without requiring a password. And looking now at the OpenID Token exchange[2] isn't this actually binding the token to the OpenID provider? I wonder what happens if that provider does not support this extension (and my guess is that only few do)? I agree that OAuth has it's issues in that it requires user interaction to authorize each access. But this also seems to come up now in the discussion about the twitter API now being changed to do OAuth only[3] and maybe this can be brought up in the OAuth list as well. Maybe this can also be some sort of extension to OAuth. If available the auth step can be automatic, if not the client needs to open up some web browser. Whatever we use in the end though I think it's important to keep whatever provides tokens separate from the OpenID provider (actually I'd suggest to keep everything except the authentication step away from it). > The use case I've drawn up for virtual worlds involves a user, an > identity provider, a content provider, and a world simulator (doesn't > matter how many separate services this is, assume a single trust > domain for now). The user tells the world simulator that it has an > identity at http://identityprovider.com/user which initiates the > OpenID authentication sequence. Logging into a world simulator is > implicitly giving it access to a minimum set of your profile > information on the identity provider and appearance data on the > content provider. This is facilitated with an identity token request > from the world simulator to the identity service, and that token is > passed to the content service. The content service can then confirm > the validity of the token and grant access to a minimum set of > content. Ok, I see the point here in that it would be possible then to at least cerate whitelist or blacklists instead of making this public in the first place. The main problem is again though to be able to automatically grant access to certain resources. This means that there maybe needs to be a way to identify resources (like "a limited set of my profile") and some way to exchange tokens. Maybe also 2-legged OAuth can help here (see [4] and [5]). With 2-legged OAuth you don't need to ask the user for permission. All what is done is that the pre-shared API key is checked. This way you might be able to do whitelisting/blacklisting as well. That being said, I haven't though in detail about all this as time was a bit limited recently. I hope to spend some time soon thinking and implementing examples though (and discussing it of course). > OAuth definitely has wider adoption than OpenID Token Exchange, and > if you see a way to make this scenario work with OAuth (without too > many contortions) please let me know. I will and maybe we can also find some solution together. I would suggest though that if we cannot find a way to make this work with OAuth we better use some extra service to check the token (if that's possible) in order to not rely on features not deployed widely. >> And what are you planning to use Attribute Exchange (AX) for? We >> discussed using this in the DataPortability Group a while back for >> storing the URL to your service catalogue that way but the problem >> was a bit lack of adoption. I also tried to do some tests with >> myopenid but it seemed that I couldn't store new fields. >> >> If it's for profile retrieval the OpenSocial REST API is IMHO a >> better fit as it's a) easier to implement and b) more discussed and >> already adopted by e.g. myspace (and yahoo is talking about it). >> > > I doubt any identity provider will let you start storing arbitrary > data on their server. My understanding of AX is that identity > providers can map their existing identity+profile information to well > recognized AX fields and provide whatever information they have. > Avatars will likely require unique fields, such as the URL of > appearance data. If OpenSocial provides a better or better adopted > way of doing that then it's worth investigation. It might also mean > that it's premature to standardize on one or the other. That seems to > leave the options: 1) leave attribute retrieval out of scope (doesn't > do much to solve interoperability), 2) make up our own standard based > on LLSD/LLIDL (makes the situation even worse, and goes against the > proposed goals of the draft MMOX charter), or 3) support multiple > implementations (increases the complexity of the spec, and creates > excess cruft once one of the competing proposals dies out). I doubt the same ;-) But note that your OpenID provider does not necessarily be your primary source for profile information. But I agree that OpenSocial does not have all necessary data available and in fact it should be more extensible in it's nature. Right now it really seems like the sum of all possible fields of all the social network providers involved in the effort. As for AX IMHO it's bound again a bit too much to the OpenID provider and maybe also means that cannot support other means of authentication. I also actually think that e.g. the appearance URL should not be coming from your profile but a separate service catalogue (e.g. based on XRDS) which lists things like your profile URL, your special VW related services and all other possible services. Using such a catalogue would also enable us to be flexible in what services to support for various tasks. You could even list multiple services with priorities and the client can check what is supported for each VW. That all being said it's probably all too early to discuss in all that detail as we first need to have that charter. But the topic definitely is a hot one not only in the MMOX context but also the web context in general. [1] http://oauth.net [2] http://dev.aol.com/OpenidTokenExchange [3] https://twitter.pbwiki.com/oauth-desktop-discussion [4] http://sites.google.com/site/oauthgoog/2leggedoauth/2opensocialrestapi [5] http://groups.google.com/group/oauth-extensions/browse_thread/thread/d46f4775d25e0c9d -- 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 cs@comlounge.net 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 dyerbrookme@juno.com Sat Feb 21 09:47:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59283A6894 for ; Sat, 21 Feb 2009 09:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqgL0mkCYJTj for ; Sat, 21 Feb 2009 09:47:54 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 51A943A6878 for ; Sat, 21 Feb 2009 09:47:54 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail10.vgs.untd.com [10.181.12.150]) by smtpout06.vgs.untd.com with SMTP id AABE4ARTQAPNMMZ2 for (sender ); Sat, 21 Feb 2009 09:47:26 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNBA6QtvwDo+UCgLdA4z5A5w== Received: (from dyerbrookme@juno.com) by webmail10.vgs.untd.com (jqueuemail) id N9XM7D6V; Sat, 21 Feb 2009 09:46:28 PST Received: from [68.161.198.3] by webmail10.vgs.untd.com with HTTP: Sat, 21 Feb 2009 17:45:44 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 21 Feb 2009 17:45:44 GMT To: infinity@lindenlab.com X-Mailer: Webmail Version 4.0 Message-Id: <20090221.124544.9172.0@webmail10.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 6:3:2577695559 X-UNTD-Peer-Info: 10.181.12.150|webmail10.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 17:47:55 -0000 >ann. i've yet to see this mandated in any protocol suggested here or = by the AWG. please do not mis-represent the work going on here. this = is a forum for the discussion and development of technical standards. No, this is Prokofy Neva speaking, not ann, you've mixed up the posters,= although clearly marked. >again. there are no protocols being considered by this group that = would REQUIRE the abandonment of the transport of permissions metadata. Infinity, I never can understand why this statement is always put in the= negative when these discussions come up, "there are no protocols being = considered that would REQUIRE the abandonment. etc.". Is there a reason = why you can't put this in the positive, "We will make sure that the prot= ocols INCLUDE the transport of permissions metadata". Because otherwise,= it appears that you are saying essentially this, as you've implied on t= he LL blog: "We aren't going to deliberately take out permissions" -- bu= t then implicitly, "But we won't work to uphold them with a technical so= lution, either." This seems like an important distinction, and putting t= he operation in the positive is important to create a real situation of = real free choice, otherwise, not working to include the metadata means t= hat suddenly, you can later say "Oh, well, other people didn't want it s= o we had to go along with it but it's not our fault". = >this is not a forum for you to complain about the permissions system = currently deployed on the second life main grid or linden lab's = policies regarding digital asset creator's intellectual property = rights. there _are_ other forums where this is appropriate and i = encourage you to participate in them. I'm not complaining about the current permissions system, I'm celebratin= g it as a good thing and urging that it be used as the standard. It's no= t about privileging one company over another, as I think the c/m/t regim= e is a pretty workable and remarkably successful regime that works far b= etter than other solutions that companies have come up with (no UGC allo= wed, all UGC cleared through a central committee, corporate firewalls on= private grids, etc.) Sure, there are other forums to discuss these things, where you can push= concerned people out of sight and out of mind, but if you are going to = go about interoperability by refusing to uphold c/m/t at the outset as a= positive project, and only taking a passive stance that you won't activ= ely strip it out (but you will not work to uphold it), then it very much= becomes *all about* interoperability. Unlike the corporate DRM's that p= eople complain about so much that don't have flexibility for individual = users, the "DRM" of c/m/t SL-style is controlled individually by each in= dividual creator, and that's the reason for its success. I don't think I will need to speak on this subject again, as I think it'= s fairly well established now that a) Linden Lab will not work to uphold= the permissions regime of c/m/t outside its grid, but will enthusiastic= ally hook up to other grids that do not uphold this regime merely for th= e sake of interoperability, that the inclusion of c/m/t will *not* be on= the menu of "trustworthyness"; b) other companies with different IP pro= tection solutions like central clearance or no UGC at all will also not = work to uphold a permissions regime of c/m/t. = Now that we've established those two things, the public then understands= the vast implications of interoperability serving corporate rather than= public interests. All you need to do is be clear about this, and then t= he conversation is over. Then the consumer votes with their feet, as nee= ded. ____________________________________________________________ Click to learn about options trading and get the latest information. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIzQb3SJVlegeN9XYLKXO6= KzAzRPRmJgtPHGiGx5KlBfH4Slo7bxu/ From cfk@pacbell.net Sat Feb 21 10:06:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAE0E3A6AA2 for ; Sat, 21 Feb 2009 10:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UW9IqbXc+O7P for ; Sat, 21 Feb 2009 10:06:56 -0800 (PST) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id E37DB3A6878 for ; Sat, 21 Feb 2009 10:06:55 -0800 (PST) Received: (qmail 14728 invoked by uid 60001); 21 Feb 2009 18:07:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=XGPHSTvd6xaIMhLnoVXRnkuLrAeCu3Hxjw7XK0aoYBQaYhB3PedVUQ0GD6JYnaTP/zYQp9bvjO2xoGLDMTRaNDt/xFo+7V2mXfZTarE41aERzwFFUvFVA2kOFO1c0rFe7eXNIqiXNiaGLfa1WwDgVSJTa6KP2YE0Aht2oFqrhUs=; X-YMail-OSG: il1os.sVM1nAfrNe5R1z1kbsvrYRr1Dxwi1yu.8SuZgLO6dZlobgY8.HqiViLh6.FlF7Qm52h4zXslq.YZoiZ43H8zCgYHElw3Ulcd.p4IS9OBIVGJkFxiBGfU7RUgGYvwPnrThPYCNAHeo4ZjO_IVnSwUzC_oRsKVX03A7oB2y0urIyHySfHfoxku4i Received: from [67.120.11.69] by web82605.mail.mud.yahoo.com via HTTP; Sat, 21 Feb 2009 10:07:10 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 Date: Sat, 21 Feb 2009 10:07:10 -0800 (PST) From: Charles Krinke To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1268465823-1235239630=:10197" Message-ID: <989654.10197.qm@web82605.mail.mud.yahoo.com> Subject: [mmox] Getting more virtual worlds participating X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:06:57 -0000 --0-1268465823-1235239630=:10197 Content-Type: text/plain; charset=us-ascii It seems to me that we become more strong and useful by finding one or more representatives from other virtual worlds. It appears to me that we have a significant (and vocal) presence from LL, OpenSim and Fortrerra. I believe we have an interested party from Croquet, although I would like to hear more from the Croquet folks to understand how interop can help them. We need to find a way to involve folks from Wonderland and Wow amongst others. It doesnt matter if it is a representative from "Blizzard" so much as at least one or two user representatives. After all, we have user representatives from SecondLife and OpenSim on this channel, so we have a precendent and it seems a reasonable precedent. Perhaps we should encourage some of Fortrerra's users as well to join us to get a slightly different perspective. So, how to we get some more representatives of virtual worlds software developers, virtual worlds/grid implementors and users/citizens of more virtual worlds into this furball so we can discuss the group charter and find a way to "interop" a bit. Charles Krinke OpenSim Core Developer OSGrid Director --0-1268465823-1235239630=:10197 Content-Type: text/html; charset=us-ascii
It seems to me that we become more strong and useful by finding one or more representatives from other virtual worlds. It appears to me that we have a significant (and vocal) presence from LL, OpenSim and Fortrerra. I believe we have an interested party from Croquet, although I would like to hear more from the Croquet folks to understand how interop can help them.

We need to find a way to involve folks from Wonderland and Wow amongst others. It doesnt matter if it is a representative from "Blizzard" so much as at least one or two user representatives. After all, we have user representatives from SecondLife and OpenSim on this channel, so we have a precendent and it seems a reasonable precedent. Perhaps we should encourage some of Fortrerra's users as well to join us to get a slightly different perspective.

So, how to we get some more representatives of virtual worlds software developers, virtual worlds/grid implementors and users/citizens of more virtual worlds into this furball so we can discuss the group charter and find a way to "interop" a bit.

Charles Krinke
OpenSim Core Developer
OSGrid Director
--0-1268465823-1235239630=:10197-- From jwatte@gmail.com Sat Feb 21 10:08:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59713A6AB2 for ; Sat, 21 Feb 2009 10:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwi0Yh1241om for ; Sat, 21 Feb 2009 10:08:00 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 865263A6AA2 for ; Sat, 21 Feb 2009 10:08:00 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1726749wfd.31 for ; Sat, 21 Feb 2009 10:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=dKlF3IyQh1zmJK/JIJ2aLRq903g73DN2FW8M9Zes03A=; b=PGxjWuYa4I320f361jqZ6LmZrzhi0MezndN89++OXjSLz7TbYY6lcrKF/7BrNsGsfq NN1puF8vfbRw6vLJcq7dFAP8a4cAHBH898172n+SEpOXCY5y97sUiAfCTk7PfALyYLeE fFc0FV+foZKjKlHtXcSSMHcNxcm3TCxgd2SGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=E2i/ztcDU4MHmwpA28WYFQ7b1zbKEEVUzWJrqliovpJBG3qF/hsvjjytAuoZ88erKf JJaVFRnaBZvMnIK+J9M8sjkj1GthxLNIsaONmmmrODjqfHrwhx7LERQb2YPd/NqaG5Wg 3bOueu+KslkKGoFJ1AnLNi+jRWn/LJFhpuXqA= Received: by 10.142.214.11 with SMTP id m11mr1051229wfg.183.1235239694753; Sat, 21 Feb 2009 10:08:14 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id 24sm5862455wfc.57.2009.02.21.10.08.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 10:08:14 -0800 (PST) Message-ID: <49A0430E.5030404@gmail.com> Date: Sat, 21 Feb 2009 10:08:14 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com><80E946E9-5C62-4E00-BE8C-A15513898F99@lindenla b.com><62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com><29656.28734.qm@web82607.mail.mud.yahoo.com><61320.78349.qm@web82607.mail.mud.yahoo.com><962799.66993.qm@web82608.mail.mud.yahoo.com> <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> <88DFFC67-0B59-4D65-86FB-8776899B794A@lindenlab.com> <499F10D7.5080605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD and content schema X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:08:01 -0000 Meadhbh Hamrick (Infinity) wrote: > > > success > true > something_i_like_to_eat_on_sundays > bananas > > > IMO, that's a terrible serialization, because it depends on ordering. While XML is ordered, this particular serialization makes it hard to write XPath that selects "the string that comes after key success but before key something_i_like_to_eat_on_sundays". > >> If I want to send a piece of data from point A to point B, and point >> A and point B know exactly what this data will be, then data type >> information does not need to be sent as part of the serialization. In >> fact, including data type information is redundant and consumes >> network bandwidth unnecessarily. > > however, sending type information in the serialization allows > intermediary systems to reason about the content of the data they are > receiving and potentially make routing and caching decisions based on > the content. > I believe that, for the high-volume real-time binary stream, the bandwidth requirements outweigh the "caching" requirements -- nobody's going to be caching the real-time data anyway. > LLSD is intended to be used in a "loosely coupled" environment. one > "feature" of such an environment is that systems be resilient in the > face of heterogeneity in terms of component version. for example, > consider a logging system that received logging messages from a number > of clients and stores them for later analysis. when the system is > initially deployed, messages may be defined as the tuple (source, > severity, description). it is not difficult to imagine the situation > where one It turns out we have a logging system in OLIVE, and it stores the actual framed data without needing to know the internals at all. The clients need to know and understand the internals, but they can do that because they have the schema. Now, in OLIVE, the schema is described largely in code, not dynamically, as proposed in my proposal, but I think a dynamic schema is actually the right thing to do for interoperability -- it, too, makes it possible to update the protocol without recompiling anything. And it doesn't require sending "here comes a float" for each component of each position vector of each object in each packet sent... I guess I don't see the applicability of LLSD. It's too little to be useful for a "verbose" format (like XML documents), and it's too much overhead for the real-time stuff. By contrast, XDR uses external schema, which is good, but the existing schema tools are not dynamic, which is less good. If LLSD can be adapted in one of two directions (or both!) then I'd be much less resistive. Either make it support external schema encodings in a binary efficient way (see http://www.interopworld.com/node/29) and use it for real-time stuff, or make it support proper, Xpath compatible XML and use it for the XML-RPC stuff. Sincerely, jw From jwatte@gmail.com Sat Feb 21 10:12:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8163A6A64 for ; Sat, 21 Feb 2009 10:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM1k0fo--Vwa for ; Sat, 21 Feb 2009 10:12:30 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 635A53A6878 for ; Sat, 21 Feb 2009 10:12:30 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1281147rvb.49 for ; Sat, 21 Feb 2009 10:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=R2ig7iiF8XUqHnuKKl6Bvd276abfjZZQonFaHUlV0cU=; b=PGQHgxWLFJK4BI6OgwogqKBMQxL56LpA8EWTMJTY5SAU61t38G5KAXPCU55rGWnmjK f7ko2048or3fp5dsey4KEgiuSDLAa4d8JXprW9rXQnZf6kllzOD5yiGrUyHjdwmC8Gc7 ae6aaWqDEOchaGgv4yXw4koyp/4AzxWfMDK2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dwRtvEo+VwKuyaeXfyozUDjpPSsxnv1l43dNQ/FIEiMBgdxzl4bwz01Hc36tbO9CjT gviMJekBxC5P3q7coowxP31vVzRd3s3tFncfHgLU0t4XG9PLs6QkDmExGUZhHq/oxUvE 8B3LAKLAAXm3MeH7jFb8dNokQ+ttXGoodkY1E= Received: by 10.141.114.19 with SMTP id r19mr1099902rvm.24.1235239965444; Sat, 21 Feb 2009 10:12:45 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id f21sm9213551rvb.2.2009.02.21.10.12.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 10:12:44 -0800 (PST) Message-ID: <49A0441C.5000103@gmail.com> Date: Sat, 21 Feb 2009 10:12:44 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke References: <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <873917.52772.qm@web82607.mail.mud.yahoo.com> <189086.57376.qm@web82601.mail.mud.yahoo.com> In-Reply-To: <189086.57376.qm@web82601.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Other groups X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:12:31 -0000 Ideally, every company from the following list of 11 should be represented: http://cleverzebra.com/book/virtual-worlds/166 Note that the fact that we have users not involved in the actual technical work does not mean that that's the best structure for actual standards documents. Users are crucial when doing requirements gathering (which is what we're doing now), but once the "this bit goes there" work starts, I believe implementation considerations are going to weigh much heavier. Sincerely, jw Charles Krinke wrote: > It seems to me that we become more strong and useful by finding one or > more representatives from other virtual worlds. It appears to me that > we have a significant (and vocal) presence from LL, OpenSim and > Fortrerra. I believe we have an interested party from Croquet, > although I would like to hear more from the Croquet folks to > understand how interop can help them. > > We need to find a way to involve folks from Wonderland and Wow amongst > others. It doesnt matter if it is a representative from "Blizzard" so > much as at least one or two user representatives. After all, we have > user representatives from SecondLife and OpenSim on this channel, so > we have a precendent. > > So, how to we get some more virtual worlds into this furball so we can > discuss the group charter and find a way to "interop" a bit. > > Charles Krinke > OpenSim Core Developer > OSGrid Director From gareth@litesim.com Sat Feb 21 10:14:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF8A3A6878 for ; Sat, 21 Feb 2009 10:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RLn7Z2OGBoD for ; Sat, 21 Feb 2009 10:14:00 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 4AEC63A6ACB for ; Sat, 21 Feb 2009 10:14:00 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1281379rvb.49 for ; Sat, 21 Feb 2009 10:14:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.29.16 with SMTP id g16mr1099306rvj.92.1235240054854; Sat, 21 Feb 2009 10:14:14 -0800 (PST) In-Reply-To: <989654.10197.qm@web82605.mail.mud.yahoo.com> References: <989654.10197.qm@web82605.mail.mud.yahoo.com> Date: Sat, 21 Feb 2009 18:14:14 +0000 Message-ID: <61dbdd7d0902211014m29684a55va88d87a64f8b1d30@mail.gmail.com> From: Gareth Nelson To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Getting more virtual worlds participating X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:14:01 -0000 What use are user reps if they can't actually speak to changes on WoW? Personally, I realise this may be controversial, I do not believe that we should focus on games too much - games are by their very nature not going to benefit from a lot of the interop work. Who wants to TP from SL into WoW and then TP out of WoW into a game of counterstrike? On Sat, Feb 21, 2009 at 6:07 PM, Charles Krinke wrote: > It seems to me that we become more strong and useful by finding one or more > representatives from other virtual worlds. It appears to me that we have a > significant (and vocal) presence from LL, OpenSim and Fortrerra. I believe > we have an interested party from Croquet, although I would like to hear more > from the Croquet folks to understand how interop can help them. > > We need to find a way to involve folks from Wonderland and Wow amongst > others. It doesnt matter if it is a representative from "Blizzard" so much > as at least one or two user representatives. After all, we have user > representatives from SecondLife and OpenSim on this channel, so we have a > precendent and it seems a reasonable precedent. Perhaps we should encourage > some of Fortrerra's users as well to join us to get a slightly different > perspective. > > So, how to we get some more representatives of virtual worlds software > developers, virtual worlds/grid implementors and users/citizens of more > virtual worlds into this furball so we can discuss the group charter and > find a way to "interop" a bit. > > Charles Krinke > OpenSim Core Developer > OSGrid Director > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From jwatte@gmail.com Sat Feb 21 10:28:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6843A6992 for ; Sat, 21 Feb 2009 10:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yz6npga9zVvA for ; Sat, 21 Feb 2009 10:28:32 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 40DC73A6920 for ; Sat, 21 Feb 2009 10:28:32 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1283909rvb.49 for ; Sat, 21 Feb 2009 10:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=F1uq2jfkgFLuI5jIdI+xVjgjgsfW0fHAxMQqACGawaM=; b=pyIpLCZ0XlrexrDYTIcmmKoguyej/mVKa/5oQi3+DZvgTb4mz+gD1gtNeGgMIP+MMu WjDU9XcGjBgGmngIIpHNrdK7WMhvNa5Bcze1PTol3FIge82+yY9gCMi0DNBC17/isTvg 7rj+SlKvT7pHtbCnYiJFtuT5MI07pU1iIohe0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hZteAmYfJlXP85mcG/6gCNrwchH1fivYPwAC8VMQgUF4gg4mDvJRIDWPgVGMIL2DHM gvwc64PpE9RgJmWEhQi57zWhm6hC4WejyDhA+zae27Z+XktrQ2rVs9mrR/OvOyFhSlRw vZH4lVQafiT0eJLwg/ARIbinN2ve4iL3CCLSY= Received: by 10.141.33.19 with SMTP id l19mr1087233rvj.294.1235240927147; Sat, 21 Feb 2009 10:28:47 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id f21sm9243754rvb.2.2009.02.21.10.28.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 10:28:46 -0800 (PST) Message-ID: <49A047DE.40802@gmail.com> Date: Sat, 21 Feb 2009 10:28:46 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090221.020609.27043.1@webmail04.vgs.untd.com> In-Reply-To: <20090221.020609.27043.1@webmail04.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 71 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:28:33 -0000 dyerbrookme@juno.com wrote: > There is only one Linden Lab, it's not "Linden Labs" -- not yet, anyway. > > Sorry, I didn't include the possessive apostrophe: "Linden Lab's people." I submit that English is not my first language, and ask for your forgiveness for this lapse. > It's not about any "beef" with LL or any "trust". These are generic issues. If you do not require of each and every interoperability partner or candidate that they follow a minimal set of rules, like implementing c/m/t, then the sender cannot expect that the receiver will feel any restraint whatsoever. If another grid strips out c/m/t or doesn't implement it, Do you understand that the IETF has no civil or criminal enforcement power? We, as a standards community, can specify the mechanism, and the intended semantics. Whether a particular implementer chooses to implement those or not is beyond the control of any of us individually. It seems to me that you're asking for something that simply can't be guaranteed, barring action of Congress (and, evenso, that only affects the US, not the other 95% of the world). > This seems arbitrary, and I think the generic issue remains: will the technology vendors, in their push toward interoperability, respect technical implementations of IP or not, or will they cast it aside as an impossible DRM scheme they are unable or unwilling to implement. This is an important issue to decide early on, now that the cart is before the horse anyway, so that the public can understand sooner rather than later what is likely going to happen to their IP. > > I can't predict the future, so I cannot answer that question. I can, however, say that carrying metadata (including usage rights) with content is something I want to see in the specification. Another thing that might be useful would be a negotiated trust up front: a system can tell another system what kinds of licenses it is prepared to enforce, so that an "unrestricted" system would say "I won't enforce proprietary licenses, so don't send any of that." This would be useful, because it allows the source system to avoid sending data that would be discarded on the other end. However, there is nothing that prevents a malicious or ignorant system provider from telling lies. If strong IP protection is important to a particular user, then that user will likely gravitate towards a service provider that, say, implements a certification scheme for each system it decides to interoperate with. This is a business and market decision, not something you can solve technically. > Are you or are you not for having that metadata not just signalled as an intent, but implemented as a technical, engineering solution on the receiving grid? And it seems to me that for any "copylefted sticky semantics" you already have: c/ > > Prokofy Neva > Any system that I personally implement will respect the capabilities. Unfortunately, there are other people in the world who will implement systems -- most of whom are not even on this mailing list. I can't speak for them. It is my understanding that "c/" just says it can be copied; it doesn't say that "if you make a copy, you have to make your copy follow the same copyleft license." Look at how SourceForge lets you choose one of many licenses, with subtly different semantics, for any SourceForge project you own. I'm imagining something similar, where degrees of left-ism and right-ism are enumerated, and the content creator makes a determination at the point of object creation. There are many dimensions here: Attribution, Modification, Moral Rights, Stickiness, Restriction, Use, Sale, ... Sincerely, jw From jwatte@gmail.com Sat Feb 21 10:30:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB9E3A693E for ; Sat, 21 Feb 2009 10:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQH1fqebPyaz for ; Sat, 21 Feb 2009 10:30:05 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 7D8A33A6978 for ; Sat, 21 Feb 2009 10:30:05 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1284153rvb.49 for ; Sat, 21 Feb 2009 10:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=GirCbVOQkpLRNSLk6ejCQ2L+QylX8Zt5Gr73BJYSuGM=; b=VqFxjs6w1IxvnY7HJz0QKlr4MUfdfjW2I4GuFNpcHg6nZJf4dIs10aTjLS+WtJ/JhK aG8oV8yM69RpdQrTXWoqLKx7IaeviSFppQIgFTX/Dr7iJfttzy++obJYajhZVJwC1XRT WxHUWc57u5qtf/aExuu1rdvJQxaY9KmJih3pU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rx5GDQJLJWT51yukDdSzDN9JfFuMMk8UGiqwzTmFcftaiIvzQLHXRhUok9Fz9N4UYu uapLsT/q0op+GwyHi9gfElhohlmmMfsHX1RyDAAEX17QTikoN3g00sYoIUqiGOZHPw5X sNqDngBVjOsCG4anOPcvHEpUKv0Re1Q/bFI78= Received: by 10.140.170.21 with SMTP id s21mr1092488rve.205.1235241020836; Sat, 21 Feb 2009 10:30:20 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id l31sm9237079rvb.5.2009.02.21.10.30.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 10:30:20 -0800 (PST) Message-ID: <49A0483C.5060106@gmail.com> Date: Sat, 21 Feb 2009 10:30:20 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <20090220.134403.24682.0@webmail05.vgs.untd.com> <499F0DEE.7090107@gmail.com> <833718.32681.qm@web59103.mail.re1.yahoo.com> <2FC34C0A-AC59-465C-9BB1-E01339EC35A8@lindenlab.com> <34264.99944.qm@web59104.mail.re1.yahoo.com><1235175079.7560.172.camel@localhost> <499F49F3.7050508@gmail.com> <8C1B1116-D820-4398-982A-E5F5A24A154A@lindenlab.com> In-Reply-To: <8C1B1116-D820-4398-982A-E5F5A24A154A@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kajikawa Jeremy , "mmox@ietf.org" Subject: Re: [mmox] Content metadata through interoperability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:30:06 -0000 Meadhbh Hamrick (Infinity) wrote: > so again... mechanism, not policy. we can define how two different > administrative domains might communicate about your avatar appearance, > while at the same time NOT requiring the target domain to honor the > information. Absolutely! My point is that the mechanism should be defined -- we shouldn't leave it undefined, just because some particular vendor may choose to not follow or use it. Sincerely, jw From cfk@pacbell.net Sat Feb 21 10:31:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 531C63A6992 for ; Sat, 21 Feb 2009 10:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8G08VWKj6y5 for ; Sat, 21 Feb 2009 10:31:18 -0800 (PST) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id 2D8E43A6920 for ; Sat, 21 Feb 2009 10:31:18 -0800 (PST) Received: (qmail 34396 invoked by uid 60001); 21 Feb 2009 18:31:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=fMeg9Wp1yb2gwV5jgqZp+8MdfggSi27bNEeYy+RMfTuojKHvXdgt6hkL2KGSTNglenh68VEEWvn9B7glBx6PA9d7Hrmd+WvOzDUMNRBJQgmawUzY3HO42XwtjCdpBx5mb9ErSLmPQl3c259dmcOmjRh6bACcsqXVp8eCeXzFaA8=; X-YMail-OSG: Cy5tKt0VM1lLTsXIIakmhJJ20_CRYSXnyrzH.qwAvPzyZem0ZRiL1KpbIImMt4qwIw-- Received: from [67.120.11.69] by web82605.mail.mud.yahoo.com via HTTP; Sat, 21 Feb 2009 10:31:30 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <989654.10197.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902211014m29684a55va88d87a64f8b1d30@mail.gmail.com> Date: Sat, 21 Feb 2009 10:31:30 -0800 (PST) From: Charles Krinke To: Gareth Nelson MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1272963466-1235241090=:34323" Message-ID: <402515.34323.qm@web82605.mail.mud.yahoo.com> Cc: mmox@ietf.org Subject: Re: [mmox] Getting more virtual worlds participating X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:31:19 -0000 --0-1272963466-1235241090=:34323 Content-Type: text/plain; charset=us-ascii Ok, thats fine. My only point was that this group has more credibility if it includes more virtual worlds. Right now, I see a few, but not a lot. So, whether the list is from some companies perception of reality like cleverzebra, or the number of users, or he who can type the fastest, it doesnt really matter so much as we have a broad representation of users, developers and operators to give this group more credence. Charles ________________________________ From: Gareth Nelson To: Charles Krinke Cc: mmox@ietf.org Sent: Saturday, February 21, 2009 10:14:14 AM Subject: Re: [mmox] Getting more virtual worlds participating What use are user reps if they can't actually speak to changes on WoW? Personally, I realise this may be controversial, I do not believe that we should focus on games too much - games are by their very nature not going to benefit from a lot of the interop work. Who wants to TP from SL into WoW and then TP out of WoW into a game of counterstrike? On Sat, Feb 21, 2009 at 6:07 PM, Charles Krinke wrote: > It seems to me that we become more strong and useful by finding one or more > representatives from other virtual worlds. It appears to me that we have a > significant (and vocal) presence from LL, OpenSim and Fortrerra. I believe > we have an interested party from Croquet, although I would like to hear more > from the Croquet folks to understand how interop can help them. > > We need to find a way to involve folks from Wonderland and Wow amongst > others. It doesnt matter if it is a representative from "Blizzard" so much > as at least one or two user representatives. After all, we have user > representatives from SecondLife and OpenSim on this channel, so we have a > precendent and it seems a reasonable precedent. Perhaps we should encourage > some of Fortrerra's users as well to join us to get a slightly different > perspective. > > So, how to we get some more representatives of virtual worlds software > developers, virtual worlds/grid implementors and users/citizens of more > virtual worlds into this furball so we can discuss the group charter and > find a way to "interop" a bit. > > Charles Krinke > OpenSim Core Developer > OSGrid Director > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --0-1272963466-1235241090=:34323 Content-Type: text/html; charset=us-ascii
Ok, thats fine. My only point was that this group has more credibility if it includes more virtual worlds. Right now, I see a few, but not a lot. So, whether the list is from some companies perception of reality like cleverzebra, or the number of users, or he who can type the fastest, it doesnt really matter so much as we have a broad representation of users, developers and operators to give this group more credence.

Charles

From: Gareth Nelson <gareth@litesim.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: mmox@ietf.org
Sent: Saturday, February 21, 2009 10:14:14 AM
Subject: Re: [mmox] Getting more virtual worlds participating

What use are user reps if they can't actually speak to changes on WoW?
Personally, I realise this may be controversial, I do not believe that
we should focus on games too much - games are by their very nature not
going to benefit from a lot of the interop work. Who wants to TP from
SL into WoW and then TP out of WoW into a game of counterstrike?

On Sat, Feb 21, 2009 at 6:07 PM, Charles Krinke <cfk@pacbell.net> wrote:
> It seems to me that we become more strong and useful by finding one or more
> representatives from other virtual worlds. It appears to me that we have a
> significant (and vocal) presence from LL, OpenSim and Fortrerra. I believe
> we have an interested party from Croquet, although I would like to hear more
> from the Croquet folks to understand how interop can help them.
>
> We need to find a way to involve folks from Wonderland and Wow amongst
> others. It doesnt matter if it is a representative from "Blizzard" so much
> as at least one or two user representatives. After all, we have user
> representatives from SecondLife and OpenSim on this channel, so we have a
> precendent and it seems a reasonable precedent. Perhaps we should encourage
> some of Fortrerra's users as well to join us to get a slightly different
> perspective.
>
> So, how to we get some more representatives of virtual worlds software
> developers, virtual worlds/grid implementors and users/citizens of more
> virtual worlds into this furball so we can discuss the group charter and
> find a way to "interop" a bit.
>
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
>
--0-1272963466-1235241090=:34323-- From dyerbrookme@juno.com Sat Feb 21 10:35:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570933A6ACA for ; Sat, 21 Feb 2009 10:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqgMaoRMNr92 for ; Sat, 21 Feb 2009 10:35:24 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 672063A6992 for ; Sat, 21 Feb 2009 10:35:24 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail06.vgs.untd.com [10.181.12.146]) by smtpout02.vgs.untd.com with SMTP id AABE4AUM2AJ5EWP2 for (sender ); Sat, 21 Feb 2009 10:35:36 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkN3DgB47/DAwcbQ8fdgvYGNw== Received: (from dyerbrookme@juno.com) by webmail06.vgs.untd.com (jqueuemail) id N9XQY92P; Sat, 21 Feb 2009 10:35:33 PST Received: from [68.161.198.3] by webmail06.vgs.untd.com with HTTP: Sat, 21 Feb 2009 18:34:17 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 21 Feb 2009 18:34:17 GMT To: infinity@lindenlab.com X-Mailer: Webmail Version 4.0 Message-Id: <20090221.133417.2658.0@webmail06.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 5:2:536175587 X-UNTD-Peer-Info: 10.181.12.146|webmail06.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 71 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:35:25 -0000 X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F693A6ACA for ; Sat, 21 Feb 2009 10:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObaZucTW1J+g for ; Sat, 21 Feb 2009 10:40:29 -0800 (PST) Received: from web82606.mail.mud.yahoo.com (web82606.mail.mud.yahoo.com [68.142.201.123]) by core3.amsl.com (Postfix) with SMTP id 80ED23A6992 for ; Sat, 21 Feb 2009 10:40:29 -0800 (PST) Received: (qmail 52375 invoked by uid 60001); 21 Feb 2009 18:40:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=MIE+39maZhVlyg7znCgZv6YJcpQYKL3ZCokjXq/hgFO4kTT22qiE8SbiZ7QPNxX6xC6jH2BkQn5tSpT7K/h0shm/cESaSCo8gWO9/pR/vub9WpXNe4JQtZxAmtkt0aeU9ox8wTgSB5g+mHvMGSqGVfAt852u3LXc4Tj8rEI734Y=; X-YMail-OSG: 7b2kJnMVM1m.pcyUkQTnJ0.eZ31xqYOhtUPwXcSxnXXucMBSwCnsV20uLvNcWwOd7uWafTXKgBszcjkzB4zPTsymdjmk318YCNVFIE64vVlezfnLcGU9mCTdL6hvKkD5_DD.mB2QGrbWgqVGZhnAchZF_zX_S5FF6_uuzomuiYwKkUFhs74SKy5yp4rVCxvcJ3h.ryUyJk70xLsXt4F8bIjn3FE- Received: from [67.120.11.69] by web82606.mail.mud.yahoo.com via HTTP; Sat, 21 Feb 2009 10:40:44 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 Date: Sat, 21 Feb 2009 10:40:44 -0800 (PST) From: Charles Krinke To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-762445809-1235241644=:52284" Message-ID: <639687.52284.qm@web82606.mail.mud.yahoo.com> Subject: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:40:34 -0000 --0-762445809-1235241644=:52284 Content-Type: text/plain; charset=us-ascii I am reading the group charter again at : http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter I guess the action item for the near term is to make this charter as acceptable as possible to gain some credence from the IETF? Do I get that right? Is this our main action item at this point? Charles --0-762445809-1235241644=:52284 Content-Type: text/html; charset=us-ascii
I am reading the group charter again at :

http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter

I guess the action item for the near term is to make this charter as acceptable as possible to gain some credence from the IETF?

Do I get that right? Is this our main action item at this point?

Charles
--0-762445809-1235241644=:52284-- From jwatte@gmail.com Sat Feb 21 10:45:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B27913A693E for ; Sat, 21 Feb 2009 10:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgK5HIsrCGuU for ; Sat, 21 Feb 2009 10:45:15 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 8FA8F3A6920 for ; Sat, 21 Feb 2009 10:45:15 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1286715rvb.49 for ; Sat, 21 Feb 2009 10:45:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pde+IWUWz4z7bpQxXIIqxU/dA+Hr05X10og2pUrGRS8=; b=NSoaMRCXlMNIGF8x/3qEXPv9JEcYywfI7Gj6TweuD5sgAmNvXhg7YQi5rwTE9dzy0S MI9XjqW9ZdAGTTEWaCDw2zuH/mGbFEcac+dK8ssTwZn5o+wk7r2g1SejvuFq8yNB0Gnd bBcgNYAhe1bzKPhy2y/53qTDPyoUfMdL5Q9iA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PcwXAhxbfhRn2w7AzT1bWx0kYowAcS+QXo+RdlcFeYk+HOChgGqZl5Mb8bK90cXF/F nEp8aLz9hvcjHpIN5WY8adomdt69ttpILTE+TWIZKnhG1+b/4wWZ+AgHiEe9w+8jJDox iX9I9GIU+KOfv/i6mfHaGbewS52Ab0lJwXMUg= Received: by 10.141.201.1 with SMTP id d1mr1105280rvq.94.1235241930740; Sat, 21 Feb 2009 10:45:30 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id g22sm4211890rvb.0.2009.02.21.10.45.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 10:45:30 -0800 (PST) Message-ID: <49A04BC9.9050304@gmail.com> Date: Sat, 21 Feb 2009 10:45:29 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com> <499CA9BB.8070506@gmail.com> <499DD634.3050101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] User Accounts / "Object" Transfer. X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:45:16 -0000 Morgaine wrote: > You describe your system as follows: > > > If people from 8 different virtual world service providers meet in > one physical space ("my room"), then there will be 8 copies of "my > room" temporarily running on the greater internet, but each of > those copies just simulate one user in that room. The cost of > physical space ("my room") is very cheap, compared to the cost of > managing an active, simulated user. Each server will connect to 7 > peer servers, and send the telemetry data for the one user it > simulates, and receive interactions from those 7 peers for things > that affect that one user. > > Hang on, there are no copies of your room simulated by those 7 other > providers: you made that clear to avoid my point about local > simulation not being scalable --- those 7 other worlds would have to > have access to your own world simulation code to be able to simulate > your room, since your room is a different world to theirs and in the > general case has its own special rules and physics. > Maybe it's a matter of nomenclature? There has to be a shared, registered (in the sense of "everyone agrees that the ground is at local height Z at this point") static world geometry. Everybody loads the same static world geometry. This is not "simulated," per se, as it just sits there as a big collision mesh. Things like wind strength and gravity and viscosity (for underwater scenes, say) needs to be agreed on (or accepted but ignored) by all the participants. This is why I believe that the proper model is that one system "hosts" the particular "room" (or area, or island, or planet) for a given interoperability scenario. That system provides the static geometry and parameters to the other systems on contact (or, more likely, references to the resources that make up those things). This means that special physics; say a spherical harmonic description of localized gravity; won't affect other objects. A simulator could choose to send force interactions to the other (remote) objects if it wishes, but that would necessarily include some latency. > So what you must mean is not that your room is simulated by those > other 7, but that they send you their objects (including their > avatars) for you to manage within your own room simulation (and you > send them telemetry in return), since they do not have access to your > world simulation code. Presumably the scheme is symmetrical, so that > when you wish to join them in one of their shared rooms, you have to > send your avatar and objects there too, since you do not have access > to the world simulation code of their rooms either. Those objects > they receive from you are then managed by them within their own > individual world simulations. If so, that is exactly what the Linden > Lab and Opensim models do as well. > I send telemetry and mesh/proxy information. I do not send behavior. Behavior is simulated only on the home world. Additionally, the "host" for the system provides the static geometry and "ground rules" description. Each host does as well as it can with those rules. If some system doesn't implement gravity, then the entities from that host won't have gravity. Again, we want to get to the 90% case, without complicating things too much. I think there is a bit of a communication gap here. An "object," to me, is the full monty: behavioral code, context within the simulation system, assets, user input, etc. That's not what gets sent. What gets sent is, perhaps, a "proxy." > internal behaviour controlled by your home world but external > behaviour controlled by the remote world simulations. You haven't > described any internal/external behaviour split that way, but it's a > necessary conclusion given that you also deny that everyone has to run > everyone else's world simulation. > The only external acts on "my" objects are those that get sent from the remote worlds using "interactions." "Interactions" are defined, and typically include "collision" or "force" or "user X triggered command Y" and perhaps "is set on fire" or "takes 20 points slashing damage" (clearly, different classes of systems need different supersets of defined interactions). Note that it's up to the home server to actually apply the interaction, or discard it, and to update the proxy objects that everyone else sees with the appropriate property changes on the object. > If my analysis above is incorrect, then I'd most appreciate you > shedding a bit more light on the shared space paradigm, and how it > would operate in a metaverse with potentially unbounded virtual world > simulation diversity. There will always be effects that are specific to a given world, and can't really be transported to everyone. For example, the Blue Mars people use the Far Cry engine, which gives them certain render capabilities that most other worlds don't have. In the interoperability scenario, those features will be missed for non-Blue-Mars participants. Similarly for simulation: the common core of gravity, wind and viscosity (as found in most physics simulation packages) will be shared and understood, whereas more esoteric features will either not be understood, or will be shared using lower-level defined interactions, rather than simulation code. As technology moves on, and things that were "special" become "commonplace," those features will start becoming specified in extensions to the standard, and finally be folded into some later required core. That's how these things work in any other long-lived standard (B/W TV, followed by color TV, followed by closed captioning, followed by Stereo, ...). Sometime in the distant future, we'll find that the entire model is no longer sufficient -- perhaps all computation is expressed in terms of JVM code, or the x86 with virtualization is the prevailing computing paradigm. At that point, we need a new standard -- just like digital/HDTV is finally replacing analog TV. Sincerely, jw From jwatte@gmail.com Sat Feb 21 10:50:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74AF3A693E for ; Sat, 21 Feb 2009 10:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcsqSptsv3HG for ; Sat, 21 Feb 2009 10:50:16 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id A22C73A6920 for ; Sat, 21 Feb 2009 10:50:16 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1287503rvb.49 for ; Sat, 21 Feb 2009 10:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=OOnJsGsJKS0utdASaBCA1C3IgFt+ldvIbm+GL5sVJpY=; b=RS9dLHLmV9Z4JmtX5uQCPurVAX18PBycW6uSuiPtnPdC5hgjAQkaKKLI81KQSblue8 BRbBfEC7UzfD2x3YIROvdK32aI3hSYpAiZMwQ+D2cuLoDmGt3BgTsqQGaaYwBPCdYpx4 P4InjweFlKPBkYgAKp403eL4aJjgAl51sacyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=iPHJdamAv3e0nXnUnxCy3it2iz1UHmtb8ayRu4PeKSJi461ivs389ycyPyBglbLN/L f106N0ZeebDPkt3RuLm1UCE1pda4QO3G/0KaCGd1FO50RkGrzYDPjEfpoIr1mQFmUyQa x/Fh+QJHa9zg2hhIA27JG874KU/1/trsNyqPQ= Received: by 10.141.194.21 with SMTP id w21mr1095109rvp.262.1235242231831; Sat, 21 Feb 2009 10:50:31 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b8sm9271979rvf.8.2009.02.21.10.50.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 10:50:31 -0800 (PST) Message-ID: <49A04CF6.5090900@gmail.com> Date: Sat, 21 Feb 2009 10:50:30 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com><548919.2383. qm@web82607.mail.mud.yahoo.com><1234917818.6664.51.camel@localhost><77186.32658.qm@web59104.mail.re1.yahoo.com><499C7FAD.408000 9@gmail.com><2bd5b7f10902181404l40f2608fy6152ced5829a88ec@mail.gmail.com><499CA9BB.8070506@gmail.com><647098.76086.qm@web82602.mail.mud.yahoo.com><719A6D8A-1198-4A96-804B-5803165C5510@lindenlab .com><499DDEED.2000109@gmail.com><499F0B85.8060807@gmail.com><314782.22040. qm@web82601.mail.mud.yahoo.com><499F3667.4000901@gmail.com><244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:50:21 -0000 Meadhbh Hamrick (Infinity) wrote: > um. jon. are we reading the same documents? there are no published OGP > specs that cover most of the items you list below, so i'm wondering > how you came to the conclusion that OGP is "a mixture of things that > came out from the SL Things like "Rez avatar" is SL specific -- how a particular user comes to life in a particular system is up to that system, not something that interoperability actually needs to concern itself with. I also said "it doesn't specify enough," because all those things I enumerated, I believe have to be specified for useful interoperability to be achieved. More "SL-specific" parts are where the white space is filled in by something like OpenSim, using existing SL protocols. Sincerely, jw From jwatte@gmail.com Sat Feb 21 10:54:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC1E83A6A49 for ; Sat, 21 Feb 2009 10:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hw6MDIB+pZiT for ; Sat, 21 Feb 2009 10:54:23 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 7D3E23A6867 for ; Sat, 21 Feb 2009 10:54:21 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1288213rvb.49 for ; Sat, 21 Feb 2009 10:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=g/t4x2IPvKo+3Wi+2tJGM7TF2BtHyJv0+FjC2BILYsg=; b=CbwM0LR2mklv5FvpHa1X1W1AjftahT7kfzlSFWcUmyeYkE6TJ5gBixIe/1z/M+Hgo5 2lopnIGJzxl111YAFkAZ1HVuhaaH6zlu+qTJemOX9u/hsoM/B9g5jVk4XX1RupwgxcUD VgAQBi4szeAYWQyMwg1mZt2OYsR8qSvbg9dek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=F2AHHq5Hk6Qa+tazkt8vYTEuQu65U7RVFbnem1vqC1+fF2HNAD2iKLu2vWybSMy1Jk q2QFIHeHpzBBAhC1QLNqrp4PzqNSiNbq5KilORUgOXmi2sJY3qqDQjNWkTAB6AHebs3q xGKEX87cYRp2BXAw3kRiGN14wduXefLrdD5ec= Received: by 10.140.162.21 with SMTP id k21mr1103064rve.191.1235242476255; Sat, 21 Feb 2009 10:54:36 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id f21sm9297290rvb.2.2009.02.21.10.54.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 10:54:35 -0800 (PST) Message-ID: <49A04DEB.4060301@gmail.com> Date: Sat, 21 Feb 2009 10:54:35 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dan Olivares References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:54:24 -0000 Dan Olivares wrote: > At this point in time, are there any more proposals for the working > group draft? Should we move on to establishing rough consensus and > BOF? > Here is a proposal for subjects for standardization and a general understanding of what the "common ground" would be. I believe that without standardizing at least all of these things, broad and useful interoperability cannot be achieved: - User identity is provided by an identity provider, which may be the "home" world of the user, or some other provider. Users should not need identity tied to the specific world they want to visit. Some worlds may choose to not accept certain specific credentials, just like certain real-world stores may not accept Candian dollars for payment. The market will work out a few major credential systems in the end (such as OpenID, perhaps). As long as each system is accessed uniformly, the specifics of the back end don't matter. - Geometry is based on regular meshes, possibly with LOD switches and lower-resolution physics meshes/proxies/hulls. I understand that this may be a sticking point for the SL-derived worlds (or do they actually support arbitrary meshes as an option now? I haven't kept up.) - Texturing is based on a regular Phong model with various defined texture maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on their own). Turns out, once you have the possibility of gloss maps, normal maps, emission maps, opacity maps, diffuse maps and ambient maps, you have 90% of the "look" of any one technology, which is about as good as you can hope for through interoperability. - Telemetry (entity movement) needs to be sent on a position/orientation/velocity basis, with dead reckoning. Delta compression and lower update rates can be used to keep bandwidth usage in check. This is a big difference for OLIVE, because we are input-synchronous, similar to City of Heroes or Age of Empires. However, again, this is the common denominator and experience speaking. - Animating objects need to use a common, widespread interchange format, using named animation clips and skeletal animation. Morph deformation is likely too big a payload to make sense, at least in the early stages. COLLADA is a good format for this, but there are other possibilities (FBX, X3D and X come to mind). I think that making at least one format required is a good idea, because that ensures a minimum level of interoperability is always present. - Simulation and script execution for a given object needs to be done on the "home" system for that object, because objects may be constructed assuming wildly disparate execution environments (X3D with JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, etc). - Objects need to be marked up with simple, well defined possible interactions, so that a user interface can be generated on each client based on those interactions. Interactions are typically "set this property to this value" or "execute this command." Such interactions need to be forwarded to the server that runs the object in question. Similarly, specific interactions ("emote animation," "collision," "damage," "two-party animation," "flight" etc) need to be defined. - Non-time-critical requests should go over HTTP and/or HTTPS, using XML-RPC or a similarly well understood protocol. - Time-critical and high-bandwidth data (such as entity telemetry and user inputs) should be sent using explicit (separate) schema, and binary representation, for the same reason that we don't send streaming video as XML, or mark each pixel with a color space identifier. Sincerely, Jon Watte Forterra Systems From jwatte@gmail.com Sat Feb 21 10:57:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83E6228C0F3 for ; Sat, 21 Feb 2009 10:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jr1pUoTcP8vp for ; Sat, 21 Feb 2009 10:57:48 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 7E39F3A6B78 for ; Sat, 21 Feb 2009 10:57:48 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1288747rvb.49 for ; Sat, 21 Feb 2009 10:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=GhguZ4sLH03wH+ANLsmIXowWj5j6jSVGTREsB0rvUCE=; b=nKxtyGKyAhmKbB7jMDHea953GRuoEWZOs0nnRO8+Lufuoph0kbSI97sI+Z+PMWgYiW KGZVFCaaJBA9nF9k0WiH1A+JFrvNqTGIt85WRYUo4DY+jFM20K3v6goHf9bQN/wU/U1J E89UVUAWiOk37cWZCDQo9ETwy2LticOVWoqKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xIErwQLm4uPTykWzgyNrU8MyagEfT9v5bIL/I+jun550nWJbPQsYZVFmG+MVQ6qyuf 0Jb6xe4lQ/AwP+u5O/ZcJF2JLGJLF7ktpjf4ewDCRLifBJFE3lksNaxRbFapAoPSanCc Bxy5EB0Q1AORKrqwM8SDCgh7CtFSMQ+z26RMo= Received: by 10.140.157.5 with SMTP id f5mr1106534rve.122.1235242683319; Sat, 21 Feb 2009 10:58:03 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k41sm4221053rvb.6.2009.02.21.10.58.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 10:58:03 -0800 (PST) Message-ID: <49A04EBA.6000404@gmail.com> Date: Sat, 21 Feb 2009 10:58:02 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <62BFE5680C037E4DA0B0A08946C0933D50263405@rrsmsx506.amr.corp.intel.com> <499FB5C8.4030900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] My evaluation of LLSD+LLIDL X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:57:49 -0000 Morgaine wrote: > In general, I would tend to take the opposite approach to yours, and > define my foundations before trying to build more complex structures. > It's the usual bottom-up approach in engineering. > In engineering, you usually have the requirements before you start building. After all, if you start building a house, the way you've always built houses, and half-way through, you realize that the house is for Giraffes, then don't you feel foolish? > Admittedly LLSD is too narrow, but that's why we'll be extending it to > suit worlds beyond LL's. (/Proviso: unless someone proposes an > equally flexible alternative.)/ Google Protocol Buffers have been suggested by multiple people. That uses a compiled schema, though. Sincerely, jw From gareth@litesim.com Sat Feb 21 10:58:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6907D3A6B78 for ; Sat, 21 Feb 2009 10:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBPmMM-QUxHv for ; Sat, 21 Feb 2009 10:58:39 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id BA1C73A6867 for ; Sat, 21 Feb 2009 10:58:39 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1288886rvb.49 for ; Sat, 21 Feb 2009 10:58:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.114.19 with SMTP id r19mr1115470rvm.24.1235242735027; Sat, 21 Feb 2009 10:58:55 -0800 (PST) In-Reply-To: <639687.52284.qm@web82606.mail.mud.yahoo.com> References: <639687.52284.qm@web82606.mail.mud.yahoo.com> Date: Sat, 21 Feb 2009 18:58:54 +0000 Message-ID: <61dbdd7d0902211058p7a8bc8a5r9827ee5016bfa3c9@mail.gmail.com> From: Gareth Nelson To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:58:40 -0000 That appears to be the general consensus on what the current priority is, yes On Sat, Feb 21, 2009 at 6:40 PM, Charles Krinke wrote: > I am reading the group charter again at : > > http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter > > I guess the action item for the near term is to make this charter as > acceptable as possible to gain some credence from the IETF? > > Do I get that right? Is this our main action item at this point? > > Charles > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From gareth@litesim.com Sat Feb 21 11:00:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0326D28C10D for ; Sat, 21 Feb 2009 11:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k86gvKoBlJP7 for ; Sat, 21 Feb 2009 11:00:38 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 5ED0628C102 for ; Sat, 21 Feb 2009 11:00:38 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1289223rvb.49 for ; Sat, 21 Feb 2009 11:00:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.170.21 with SMTP id s21mr1102542rve.205.1235242853332; Sat, 21 Feb 2009 11:00:53 -0800 (PST) In-Reply-To: <639687.52284.qm@web82606.mail.mud.yahoo.com> References: <639687.52284.qm@web82606.mail.mud.yahoo.com> Date: Sat, 21 Feb 2009 19:00:53 +0000 Message-ID: <61dbdd7d0902211100x7451ee8dy536051dd32ccbe7c@mail.gmail.com> From: Gareth Nelson To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:00:39 -0000 Looking again, this is very very OGP-biased, is this not something we ought to correct? On Sat, Feb 21, 2009 at 6:40 PM, Charles Krinke wrote: > I am reading the group charter again at : > > http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter > > I guess the action item for the near term is to make this charter as > acceptable as possible to gain some credence from the IETF? > > Do I get that right? Is this our main action item at this point? > > Charles > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From jwatte@gmail.com Sat Feb 21 11:02:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB03F3A6A49 for ; Sat, 21 Feb 2009 11:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAJBj0kqGqK3 for ; Sat, 21 Feb 2009 11:02:08 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 08D483A6867 for ; Sat, 21 Feb 2009 11:02:07 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1289498rvb.49 for ; Sat, 21 Feb 2009 11:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mgpBhicakipqLsBv+VpLkCLLYOyr0rbCDWPYwa5yEmQ=; b=YkEwWLzKL6OCgBwpHZ4a4c6jzTtBqT+JSmvngn+aj70/0dHbD1jp3iLSRLg/+T505o 5JKSoFeizUVRfW9TxpuB3l0swCdG5UWpQN83861jXSG8HmelubRpYFXe8B9AkXmub4Gx X5idecPkm9dPVN0NKuX/w7WLHBG/vpxQiqPLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Bg4dg5leP+bb56LtWNCcCdIK7rfV+5GX44Axq5RlPlGKpYJbUHXV9sb9e0yXsEZick hx9gL/20W8BEmMYivWrD5gWfjTzKqWrqiA82ntVTeziGOOJDEywWbHaK4Ql7p5fjdlZC YIC9GNfSEjTi6nq44GmQCovrFIq/RbpW8hg9s= Received: by 10.140.170.21 with SMTP id s21mr1103130rve.205.1235242943442; Sat, 21 Feb 2009 11:02:23 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k41sm4234854rvb.6.2009.02.21.11.02.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 11:02:23 -0800 (PST) Message-ID: <49A04FBE.2080504@gmail.com> Date: Sat, 21 Feb 2009 11:02:22 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:02:08 -0000 Morgaine wrote: > > > On Sat, Feb 21, 2009 at 1:00 AM, Jon Watte > wrote: > > > - Geometry is based on regular meshes, possibly with LOD switches > and lower-resolution physics meshes/proxies/hulls. I understand > that this may be a sticking point for the SL-derived worlds (or do > they actually support arbitrary meshes as an option now? I haven't > kept up.) > > > We're defining mechanism, not policy, so there is no possible sticking > point for Linden Lab if the interop standard provides for interchange > of meshes as is so widely required. LL are free to not implement > meshes if they choose not to do so, that's all. I believe that such > a decision would impact on their business, but it is not up to me (nor > us) to make that call. > > By the same token, if we define interchange of SL-like "primitive" > objects to be in the standard, then anyone who wants to benefit from > the acceleration and standardized behaviour of such primitives is free > to implement them (the Opensim worlds certainly will), but nobody is > /required/ to do so. I think that's taking too much policy out of the equation. We need to define a minimum policy that any interoperating world will accept, so that an interoperating system will actually work. Defining just empty pipes, and letting people fill them with whatever, doesn't lead us anywhere closer towards actual, useful, working interoperability. Compare to MPEG 4: there are a few "profiles" defined, where any device that claims to support a given profile, knows that it can play back any content authored for that profile. And, this is important, there is a minimum profile that anything has to implement; if you want your content to be universally useful, then you author to that profile. Personally, I believe that regular meshes with physics proxies are that minimum profile, because that most closely matches how most if not all of the distributed simulations in the world do things. Sincerely, jw From infinity@lindenlab.com Sat Feb 21 11:03:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CDE63A6867 for ; Sat, 21 Feb 2009 11:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJObgYdTXhZA for ; Sat, 21 Feb 2009 11:03:31 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 90B0528C10D for ; Sat, 21 Feb 2009 11:03:31 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 071473DBC45D; Sat, 21 Feb 2009 11:03:47 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Gareth Nelson In-Reply-To: <61dbdd7d0902210322g3ac1e9d3na94284a3ca90504f@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 11:03:45 -0800 References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail. com> <61dbdd7d0902210322g3ac1e9d3na94284a3ca90504f@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:03:32 -0000 yup. this kind of QoS is definitely useful. in the current implementation of second life, there's quite a bit simulator to simulator communication. if all the simulators are inside the same data center, communicating with each other over a fiber ring, we have plenty of bandwidth, so we don't see a lot of QoS related problems. however... when two sims are in different data centers and their communications have to go over the public internet (rather than some private network with guaranteed bandwidth and latency characteristics) sim <-> sim QoS becomes VERY important. of course we're not saying we should standardize the exact same protocol we're using today at linden, but it's reasonable to assume that we would re-use some of the same design patterns, or at least support the same design pattern. ergo, it's probably in our best interest to think about QoS between all systems... -cheers -meadhbh On Feb 21, 2009, at 3:22 AM, Gareth Nelson wrote: > Thanks for the overview :) > My only comment with a quick glance is regarding this: > > "c) allow network layers to recognize VW traffic and make routing > decisions based on its characteristics." > > Is client<>server traffic for individual worlds not primarily > something for individual worlds rather than an interop issue? > For example, you might be on world A, and talking to world B via world > A's servers, but your client<>server traffic is still running A's > protocol. At the server<>server end is this kind of QoS actually > useful? > > On Sat, Feb 21, 2009 at 11:10 AM, Morgaine > wrote: >> >> >> On Sat, Feb 21, 2009 at 9:14 AM, Gareth Nelson >> wrote: >> >>> So, why don't we get on with voting on a charter? >>> As for discussing implementation details now - nothing wrong with >>> doing so if it's in the same basic area as the formal working group >>> would be >> >> >> That work has already started, Gareth, although the discussion >> might have >> preceded your joining the list. :-) >> >> To help your navigation, I'll unpick the messy email threading for >> you: >> >> 1) John Hurliman first pointed out the inappropriateness of >> references to >> OGP in the charter of a workgroup whose mission it is to examine >> what is >> appropriate in the first place: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00012.html >> >> 2) I agreed, and affirmed that we are definitely not here to >> rubberstamp >> Linden proposals, and hence that we should start immediately on >> improving >> the charter: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00013.html >> >> 3) Infinity responded extremely positively and noted that the >> initial draft >> was highly LL/IBM-specific since they were the two authors of the >> draft, but >> invited John and myself (and everyone else on the list of course) >> to submit >> concrete proposals for improvements: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00015.html >> >> 4) I responded with an offer to help directly: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00016.html >> >> 5) Based off the LL/IBM original (#1), John provided the first >> improved >> draft charter (#2): >> http://www.ietf.org/mail-archive/web/mmox/current/msg00032.html >> >> 6) Based off John's draft #2, I made improvements for clarity and >> removed an >> ambiguity, to give us draft #3: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00036.html >> >> 7) Infinity and I then exchanged several emails in the list to >> narrow down >> whether the word "proprietary" was substantive, or just a residue >> from the >> initial version. The clear conclusion was that it was highly >> substantive, >> and therefore I further modified my version with a clear statement >> that we >> are in the business of defining open, non-proprietary standards, >> which >> became draft #4: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html >> >> There have been no specific updates since then. >> >> Needless to say, if you or anyone else requires further changes, >> then pick >> up the baton and run with it! I look forward to draft #5. :-) >> >> I am sure the text will undergo numerous further iterations before we >> finally agree on an effective charter that can be passed at the >> BoF. The >> MMOX list is currently examining other issues, but it is certain to >> return >> to the charter as the BoF draws nearer. >> >> Morgaine. >> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From sempuki1@gmail.com Sat Feb 21 11:02:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A87F3A6A49 for ; Sat, 21 Feb 2009 11:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkvzYTWxOVKw for ; Sat, 21 Feb 2009 11:02:53 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by core3.amsl.com (Postfix) with ESMTP id EFAEB3A6867 for ; Sat, 21 Feb 2009 11:02:52 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d3so227191nfc.39 for ; Sat, 21 Feb 2009 11:03:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JcghJKHyrmriGoYAdY+lAZczHrxI+Dn11ThumnyL+7M=; b=EhmHDZjRsjoTjnF9jiKqGj3tK/Rqvf+98zMar6co21ovJpx03CyhbzOJyejePhsz4m MERwU5xvLHrE7ftmnR7cFNoNg5eRm3AbkeRvLDxdWTxrZcsImtQUnjcDYKlJK2324iUG 5s6GWiGt2682PyHSuZp+eChvZJ+br59QyFL70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Tb2b+m9InbINSbL4AxaC/ymFCyUxjn9aXgBjj0uGhN5xQ4Xxqs62QgGFAUtlJ13rjN sZngRE7Z8zny65M2fuh9ZcCjh94cVBLh6Dut5LAgw29crWNZ4HzT8gDHsIRIsxFCfBGO MrZoOaGeTY1JwkyEXCdHrx9zq5IUknnLvhyQE= MIME-Version: 1.0 Received: by 10.210.45.17 with SMTP id s17mr1811042ebs.93.1235242987494; Sat, 21 Feb 2009 11:03:07 -0800 (PST) In-Reply-To: <49A04DEB.4060301@gmail.com> References: <49A04DEB.4060301@gmail.com> Date: Sat, 21 Feb 2009 21:03:07 +0200 Message-ID: From: Ryan McDougall To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:03:43 -0000 On Sat, Feb 21, 2009 at 8:54 PM, Jon Watte wrote: > Dan Olivares wrote: >> >> At this point in time, are there any more proposals for the working >> group draft? Should we move on to establishing rough consensus and >> BOF? >> > > Here is a proposal for subjects for standardization and a general > understanding of what the "common ground" would be. I believe that without > standardizing at least all of these things, broad and useful > interoperability cannot be achieved: > > - User identity is provided by an identity provider, which may be the "home" > world of the user, or some other provider. Users should not need identity > tied to the specific world they want to visit. Some worlds may choose to not > accept certain specific credentials, just like certain real-world stores may > not accept Candian dollars for payment. The market will work out a few major > credential systems in the end (such as OpenID, perhaps). As long as each > system is accessed uniformly, the specifics of the back end don't matter. > > - Geometry is based on regular meshes, possibly with LOD switches and > lower-resolution physics meshes/proxies/hulls. I understand that this may be > a sticking point for the SL-derived worlds (or do they actually support > arbitrary meshes as an option now? I haven't kept up.) > > - Texturing is based on a regular Phong model with various defined texture > maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on > their own). Turns out, once you have the possibility of gloss maps, normal > maps, emission maps, opacity maps, diffuse maps and ambient maps, you have > 90% of the "look" of any one technology, which is about as good as you can > hope for through interoperability. > > - Telemetry (entity movement) needs to be sent on a > position/orientation/velocity basis, with dead reckoning. Delta compression > and lower update rates can be used to keep bandwidth usage in check. This is > a big difference for OLIVE, because we are input-synchronous, similar to > City of Heroes or Age of Empires. However, again, this is the common > denominator and experience speaking. > > - Animating objects need to use a common, widespread interchange format, > using named animation clips and skeletal animation. Morph deformation is > likely too big a payload to make sense, at least in the early stages. > COLLADA is a good format for this, but there are other possibilities (FBX, > X3D and X come to mind). I think that making at least one format required is > a good idea, because that ensures a minimum level of interoperability is > always present. > > - Simulation and script execution for a given object needs to be done on the > "home" system for that object, because objects may be constructed assuming > wildly disparate execution environments (X3D with JavaScript; Prims with SL > Script, C++ with XML, Java with JSR 184, etc). > > - Objects need to be marked up with simple, well defined possible > interactions, so that a user interface can be generated on each client based > on those interactions. Interactions are typically "set this property to this > value" or "execute this command." Such interactions need to be forwarded to > the server that runs the object in question. Similarly, specific > interactions ("emote animation," "collision," "damage," "two-party > animation," "flight" etc) need to be defined. > > - Non-time-critical requests should go over HTTP and/or HTTPS, using XML-RPC > or a similarly well understood protocol. > > - Time-critical and high-bandwidth data (such as entity telemetry and user > inputs) should be sent using explicit (separate) schema, and binary > representation, for the same reason that we don't send streaming video as > XML, or mark each pixel with a color space identifier. > > Sincerely, > > Jon Watte > Forterra Systems Sounds very agreeable to me. :) Ryan McDougall, RealXtend.org From jwatte@gmail.com Sat Feb 21 11:06:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842DC3A69F0 for ; Sat, 21 Feb 2009 11:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zl1DksSvYe0Z for ; Sat, 21 Feb 2009 11:06:48 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id 8BC0B3A6867 for ; Sat, 21 Feb 2009 11:06:48 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so739192wag.5 for ; Sat, 21 Feb 2009 11:07:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=qA0Xb8TNZ0TyCG0U+lALv+DsAlP0ZwADsExoD+CHbac=; b=k/eGixLG3M2VTIHJqSV9Oy4EMe7LmxVdbKQQ11yJJh3QTJX2VAnTsphMHN2CfVYCWg 8gh3SjUwnjuRsriI5i8cDlLReR9AFfhPhundB99X8eQ+ObDBeLltgsRztT4tzGsQo2Xa N9YEYs972BlpaDunQL6oLNvDKqqddGCqXTAeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Gl7H/ThkSgtRjxM6wr1CHPF+QHjUDP12wEeyh03PG8eC22ByJo8+CEJxXYSsRfkXqz xKO1xAwj+WlLkTgvwaqdwtKdRkvjih1INCFZ5C7OHJW+/A0z6qLiepWToHgsX+bx7xNK t944ymNspK+kO4hXAE8j/OqhQxHlqMJ6vQDTA= Received: by 10.114.208.20 with SMTP id f20mr937294wag.46.1235243223990; Sat, 21 Feb 2009 11:07:03 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k37sm1141334rvb.1.2009.02.21.11.07.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 11:07:03 -0800 (PST) Message-ID: <49A050D6.9070604@gmail.com> Date: Sat, 21 Feb 2009 11:07:02 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail.com> <61dbdd7d0902210322g3ac1e9d3na94284a3ca90504f@mail.gmail.com> <61dbdd7d0902210325n69f8bec1t5e029ace2d5d7f40@mail.gmail.com> In-Reply-To: <61dbdd7d0902210325n69f8bec1t5e029ace2d5d7f40@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:06:49 -0000 Gareth Nelson wrote: > 2 more comments (Apologies for the multiple replies style, it's a bit > of a habit) > > October 2009 Publication of LLSD Draft as an Informational RF > > Is there a reason this milestone is set so late? LLSD is already > fairly well defined. I would go so far as to say that the existing > specs and code can be RFC-alised as-is with only some subtle changes > as compatibility dictates. > I'm of the opinion that LLSD needs to either undergo substantial changes, or something else needs to be defined, before it should be accepted. Specifically, the XML serialization is not Xpath friendly, and there is no "external schema" compact form. At a minimum, I think that "publication of LLSD draft" should be changed to something worded like "publication of a basic data description and serialization formats RFC." Sincerely, jw From jwatte@gmail.com Sat Feb 21 11:13:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92CCA3A687C for ; Sat, 21 Feb 2009 11:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK7MgzTkGDkv for ; Sat, 21 Feb 2009 11:13:28 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 9E01428C132 for ; Sat, 21 Feb 2009 11:13:28 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1291343rvb.49 for ; Sat, 21 Feb 2009 11:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=X9zb4Bcgv/zQldKsd00RjCBz0ZvUG8EfzP0iQ4hRI5w=; b=nppc3zJqg5Yi6SR61DPAXDLfqYXFRRVEJ32HMGkr1wlY/htaPowSKb+y2BRCNFRsxA bOJkbcfamjLQSRz3l0PgKIt0jh2esF27trJPvnb32+x5KLsDikhRDw7wbORebmtQFPhm /T6/GHMI+5i6kLijZrdtA0T/79qksHr3gfU7Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=XJf05BXA6e2eMUqlDDBXKvkih1Fh96SNiOvSepeLzE9kgfQ4gCwCg5tC0NP+kzHr9n VjbUrGonOAPIPtUS0D3IUJ3NRVEUjV2+vUM7BLlopTzhlI1qjyNX0SRI5XshZW6Se8q/ YnVaExXsvDdrBm3ZIS56up1v9N1CnNZZ/l96s= Received: by 10.141.137.6 with SMTP id p6mr1112702rvn.133.1235243623334; Sat, 21 Feb 2009 11:13:43 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id l31sm9332495rvb.5.2009.02.21.11.13.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 11:13:42 -0800 (PST) Message-ID: <49A05265.1050703@gmail.com> Date: Sat, 21 Feb 2009 11:13:41 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090221.124544.9172.0@webmail10.vgs.untd.com> In-Reply-To: <20090221.124544.9172.0@webmail10.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:13:29 -0000 dyerbrookme@juno.com wrote: > the menu of "trustworthyness"; b) other companies with different IP protection solutions like central clearance or no UGC at all will also not work to uphold a permissions regime of c/m/t. > > Now that we've established those two things, the public then understands the vast You have established nothing of the sort. I just discussed this with some people I know at There.com, and they would be favorable to upholding technical permissions, /in additional to/ their central clearing system that often catches these problems already. View it as belt AND suspenders. I've seen you trying to put words in the mouth of others several times on this list, and I think it's unbecoming. Sincerely, jw From cfk@pacbell.net Sat Feb 21 11:13:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160C03A6B8B for ; Sat, 21 Feb 2009 11:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-y+Wu5PHPnl for ; Sat, 21 Feb 2009 11:13:28 -0800 (PST) Received: from web82606.mail.mud.yahoo.com (web82606.mail.mud.yahoo.com [68.142.201.123]) by core3.amsl.com (Postfix) with SMTP id 038D23A6A49 for ; Sat, 21 Feb 2009 11:13:27 -0800 (PST) Received: (qmail 80167 invoked by uid 60001); 21 Feb 2009 19:13:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=mBiJYuMWPP3oYfx8BukD/uY9bt08rfcMAzXS2IQBC7Qp0kCRQKDOctZWVuCySi8L0bp8ey6H+dufW3snaQey+hQCvgngHLmcxFUeGlOA75+tAVfOMM+hmPCSzpjSBJi8jwI64CgUfc3HvhS7LhKahIHzri88qB0mgQyvjjs2I9U=; X-YMail-OSG: ktg_ox8VM1nW3Bs1iE4aNsIKxTsCrc6XxiAVttomPnwJwC268NlM0zA1NwQbb1TCcmwRxI0yQ1MGe8J9MM4wcPuVvLxXcENuzyBNZvXoS3dCT.1ZydNx._x9hAe4DKy3Lvq4XXBibkU29Ldehu_SVlz4AI643JPd._Y52H5rtHoE3d6cIFBVa7EmHBt6dtAGZwxgvJpXUeH5Obwh4a8oKhDJVLA- Received: from [67.120.11.69] by web82606.mail.mud.yahoo.com via HTTP; Sat, 21 Feb 2009 11:13:43 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail. com> <61dbdd7d0902210322g3ac1e9d3na94284a3ca90504f@mail.gmail.com> Date: Sat, 21 Feb 2009 11:13:43 -0800 (PST) From: Charles Krinke To: "Meadhbh Hamrick \(Infinity\)" , Gareth Nelson MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-5620717-1235243623=:75955" Message-ID: <797749.75955.qm@web82606.mail.mud.yahoo.com> Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:13:30 -0000 --0-5620717-1235243623=:75955 Content-Type: text/plain; charset=us-ascii +1, Infinity. We find a similar thing happening with OpenSim on various grids, of which there must be dozens now. Of the 2000 sims on OSGrid spread across 500 different servers currently, one finds adjacent sims on opposite sides of the planet where the network RTT becomes significant. So, considering network RTT in interop will be of some importance, I believe. Charles ________________________________ From: Meadhbh Hamrick (Infinity) To: Gareth Nelson Cc: "mmox@ietf.org" Sent: Saturday, February 21, 2009 11:03:45 AM Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart yup. this kind of QoS is definitely useful. in the current implementation of second life, there's quite a bit simulator to simulator communication. if all the simulators are inside the same data center, communicating with each other over a fiber ring, we have plenty of bandwidth, so we don't see a lot of QoS related problems. however... when two sims are in different data centers and their communications have to go over the public internet (rather than some private network with guaranteed bandwidth and latency characteristics) sim <-> sim QoS becomes VERY important. of course we're not saying we should standardize the exact same protocol we're using today at linden, but it's reasonable to assume that we would re-use some of the same design patterns, or at least support the same design pattern. ergo, it's probably in our best interest to think about QoS between all systems... -cheers -meadhbh On Feb 21, 2009, at 3:22 AM, Gareth Nelson wrote: > Thanks for the overview :) > My only comment with a quick glance is regarding this: > > "c) allow network layers to recognize VW traffic and make routing > decisions based on its characteristics." > > Is client<>server traffic for individual worlds not primarily > something for individual worlds rather than an interop issue? > For example, you might be on world A, and talking to world B via world > A's servers, but your client<>server traffic is still running A's > protocol. At the server<>server end is this kind of QoS actually > useful? > > On Sat, Feb 21, 2009 at 11:10 AM, Morgaine > wrote: >> >> >> On Sat, Feb 21, 2009 at 9:14 AM, Gareth Nelson wrote: >> >>> So, why don't we get on with voting on a charter? >>> As for discussing implementation details now - nothing wrong with >>> doing so if it's in the same basic area as the formal working group >>> would be >> >> >> That work has already started, Gareth, although the discussion might have >> preceded your joining the list. :-) >> >> To help your navigation, I'll unpick the messy email threading for you: >> >> 1) John Hurliman first pointed out the inappropriateness of references to >> OGP in the charter of a workgroup whose mission it is to examine what is >> appropriate in the first place: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00012.html >> >> 2) I agreed, and affirmed that we are definitely not here to rubberstamp >> Linden proposals, and hence that we should start immediately on improving >> the charter: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00013.html >> >> 3) Infinity responded extremely positively and noted that the initial draft >> was highly LL/IBM-specific since they were the two authors of the draft, but >> invited John and myself (and everyone else on the list of course) to submit >> concrete proposals for improvements: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00015.html >> >> 4) I responded with an offer to help directly: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00016.html >> >> 5) Based off the LL/IBM original (#1), John provided the first improved >> draft charter (#2): >> http://www.ietf.org/mail-archive/web/mmox/current/msg00032.html >> >> 6) Based off John's draft #2, I made improvements for clarity and removed an >> ambiguity, to give us draft #3: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00036.html >> >> 7) Infinity and I then exchanged several emails in the list to narrow down >> whether the word "proprietary" was substantive, or just a residue from the >> initial version. The clear conclusion was that it was highly substantive, >> and therefore I further modified my version with a clear statement that we >> are in the business of defining open, non-proprietary standards, which >> became draft #4: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html >> >> There have been no specific updates since then. >> >> Needless to say, if you or anyone else requires further changes, then pick >> up the baton and run with it! I look forward to draft #5. :-) >> >> I am sure the text will undergo numerous further iterations before we >> finally agree on an effective charter that can be passed at the BoF. The >> MMOX list is currently examining other issues, but it is certain to return >> to the charter as the BoF draws nearer. >> >> Morgaine. >> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-5620717-1235243623=:75955 Content-Type: text/html; charset=us-ascii
+1, Infinity. We find a similar thing happening with OpenSim on various grids, of which there must be dozens now.

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

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

Charles
From: Meadhbh Hamrick (Infinity) <infinity@lindenlab.com>
To: Gareth Nelson <gareth@litesim.com>
Cc: "mmox@ietf.org" <mmox@ietf.org>
Sent: Saturday, February 21, 2009 11:03:45 AM
Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart

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

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

-cheers
-meadhbh

On Feb 21, 2009, at 3:22 AM, Gareth Nelson wrote:

> Thanks for the overview :)
> My only comment with a quick glance is regarding this:
>
> "c) allow network layers to recognize VW traffic and make routing
> decisions based on its characteristics."
>
> Is client<>server traffic for individual worlds not primarily
> something for individual worlds rather than an interop issue?
> For example, you might be on world A, and talking to world B via world
> A's servers, but your client<>server traffic is still running A's
> protocol. At the server<>server end is this kind of QoS actually
> useful?
>
> On Sat, Feb 21, 2009 at 11:10 AM, Morgaine
> <morgaine.dinova@googlemail.com> wrote:
>>
>>
>> On Sat, Feb 21, 2009 at 9:14 AM, Gareth Nelson <gareth@litesim.com> wrote:
>>
>>> So, why don't we get on with voting on a charter?
>>> As for discussing implementation details now - nothing wrong with
>>> doing so if it's in the same basic area as the formal working group
>>> would be
>>
>>
>> That work has already started, Gareth, although the discussion might have
>> preceded your joining the list. :-)
>>
>> To help your navigation, I'll unpick the messy email threading for you:
>>
>> 1) John Hurliman first pointed out the inappropriateness of references to
>> OGP in the charter of a workgroup whose mission it is to examine what is
>> appropriate in the first place:
>> http://www.ietf.org/mail-archive/web/mmox/current/msg00012.html
>>
>> 2) I agreed, and affirmed that we are definitely not here to rubberstamp
>> Linden proposals, and hence that we should start immediately on improving
>> the charter:
>> http://www.ietf.org/mail-archive/web/mmox/current/msg00013.html
>>
>> 3) Infinity responded extremely positively and noted that the initial draft
>> was highly LL/IBM-specific since they were the two authors of the draft, but
>> invited John and myself (and everyone else on the list of course) to submit
>> concrete proposals for improvements:
>> http://www.ietf.org/mail-archive/web/mmox/current/msg00015.html
>>
>> 4) I responded with an offer to help directly:
>> http://www.ietf.org/mail-archive/web/mmox/current/msg00016.html
>>
>> 5) Based off the LL/IBM original (#1), John provided the first improved
>> draft charter (#2):
>> http://www.ietf.org/mail-archive/web/mmox/current/msg00032.html
>>
>> 6) Based off John's draft #2, I made improvements for clarity and removed an
>> ambiguity, to give us draft #3:
>> http://www.ietf.org/mail-archive/web/mmox/current/msg00036.html
>>
>> 7) Infinity and I then exchanged several emails in the list to narrow down
>> whether the word "proprietary" was substantive, or just a residue from the
>> initial version.  The clear conclusion was that it was highly substantive,
>> and therefore I further modified my version with a clear statement that we
>> are in the business of defining open, non-proprietary standards, which
>> became draft #4:
>> http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html
>>
>> There have been no specific updates since then.
>>
>> Needless to say, if you or anyone else requires further changes, then pick
>> up the baton and run with it!  I look forward to draft #5. :-)
>>
>> I am sure the text will undergo numerous further iterations before we
>> finally agree on an effective charter that can be passed at the BoF.  The
>> MMOX list is currently examining other issues, but it is certain to return
>> to the charter as the BoF draws nearer.
>>
>> Morgaine.
>>
>>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--0-5620717-1235243623=:75955-- From dyerbrookme@juno.com Sat Feb 21 11:24:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9127F3A6B83 for ; Sat, 21 Feb 2009 11:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99EdVRiCFvhG for ; Sat, 21 Feb 2009 11:24:51 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 969283A6A49 for ; Sat, 21 Feb 2009 11:24:51 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail06.vgs.untd.com [10.181.12.146]) by smtpout03.vgs.untd.com with SMTP id AABE4AXHKAZWEEM2 for (sender ); Sat, 21 Feb 2009 11:24:25 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNv7F+lhwQ5Uz2Y5y55jX2tA== Received: (from dyerbrookme@juno.com) by webmail06.vgs.untd.com (jqueuemail) id N9XTRMUM; Sat, 21 Feb 2009 11:23:49 PST Received: from [68.161.198.3] by webmail06.vgs.untd.com with HTTP: Sat, 21 Feb 2009 19:22:32 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 21 Feb 2009 19:22:32 GMT To: jwatte@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090221.142232.2658.1@webmail06.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:60979106 X-MAIL-INFO: 5630a99530208931208d31b431e1315169e55961e579e52d61 X-UNTD-Peer-Info: 10.181.12.146|webmail06.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:24:52 -0000 Dear Jon, I haven't put words into any mouths, in a setting where everybody's word= s are on the record for all to see, but open, of course, to debate and i= nterpretation if indeed the debate is free and not controlled only by te= chnology vendors with a business interest in inoperability, as you state= d. I'm glad my restatement of what it sounded like I was hearing compelled = you to talk to There.com and come forward now with a more robust belt-AN= D-suspenders statement. Good! That's why such re-statements are useful. = = Again, I can only ask what it means, for LL or any other "vendor," if yo= u do not actively affirm technical permissions, i.e. like c/m/t, and say= you will merely not actively defeat them, then...why is it good enough = for your platform, but not good enough for the Metaverse? And if it is d= esirable for the Metaverse, why isn't it instantly instated on your plat= form? = Morgaine's restatement of the paragraph about exchanging protocols and 3= -d object data still sounds to me as a non-technician as if she is first= installing interoperability and the ability to exchange all data and pr= otocols and objects freely, and "getting the job done" and laying out th= e bridges, but then only later, tacking on as a module the problem of ho= w to protect IP. First make all content exchangeable, then later, after = that technical marvel is accomplished among very disparate platforms wit= h different tecnologies and cultures, tacking on an IP concern in the fo= rm of "call your lawyer or tuck a CC license into your prim". Oh, you ha= ve to hope the other worlds will have prims and that no one will delete = your card. ____________________________________________________________ Looking to buy or refinance? Receive up to 4 offers, all credit http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIqFyk63Re70BlzLAilxUP= c58lVdLtG1y3xXpqwzvgeBOPROWvjpi/ From infinity@lindenlab.com Sat Feb 21 11:28:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C913A6BB5 for ; Sat, 21 Feb 2009 11:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.179 X-Spam-Level: X-Spam-Status: No, score=-3.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0R8WKwOYdAmu for ; Sat, 21 Feb 2009 11:28:12 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id D35973A69F4 for ; Sat, 21 Feb 2009 11:28:12 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id BDAB43DBC45D; Sat, 21 Feb 2009 11:28:28 -0800 (PST) Message-Id: <96E4BCCD-5963-4C1A-87FF-B90159218087@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Gareth Nelson In-Reply-To: <61dbdd7d0902210325n69f8bec1t5e029ace2d5d7f40@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 11:28:26 -0800 References: <61dbdd7d0902210114gc838cc1qa34b8aae7455d241@mail.gmail. com><61dbdd7d0902210322g3ac1e9d3na94284a3ca90504f@mail.gmail.com> <61dbdd7d0902210325n69f8bec1t5e029ace2d5d7f40@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:28:14 -0000 right. this is a non-starter. if any protocol that uses LLSD to describe it's protocol interactions is to have a hope of being anything other than an informational RFC, LLSD must be a standards track document. this is because normative references in RFCs MUST have the same level of maturity as the RFC itself. ergo, you can't have a standards track document that references an informational RFC as a normative reference. but why is it set so late? first off.. remember it's a draft charter (and in the original draft, LLSD was listed as a standards track document but to move from being an ID to being an RFC at about the same time.) so there's still time to modify stuff. we were originally going to simply submit LLSD as an information RFC, but eventually came around to the believe that the IETF is a great place to develop standards. as an informational RFC, we could simply have published it and moved on with our lives. instead we wanted to include the community as a whole which is where the idea of the MMOX working group came from. cause if you're just going to publish informational RFCs, why do you need a working group? okay.. this is probably a lot longer answer than what you were expecting to get. let me get back to the answer. we were thinking that LLSD would require a lot of commentary and discussion as peeps implement it in their language of choice, and we wanted to have time to get that feedback. so... i figured we would have at least one and possibly two more drafts of the LLSD doc with three or four months between them. Also... october is just before the November IETF meeting, and i was hoping we could have our work on LLSD finished by then so we could concentrate on the more interesting things (like an actual protocol) in that meeting. -cheers -meadhbh On Feb 21, 2009, at 3:25 AM, Gareth Nelson wrote: > 2 more comments (Apologies for the multiple replies style, it's a bit > of a habit) > > October 2009 Publication of LLSD Draft as an Informational RF > > Is there a reason this milestone is set so late? LLSD is already > fairly well defined. I would go so far as to say that the existing > specs and code can be RFC-alised as-is with only some subtle changes > as compatibility dictates. > > On Sat, Feb 21, 2009 at 11:22 AM, Gareth Nelson > wrote: >> Thanks for the overview :) >> My only comment with a quick glance is regarding this: >> >> "c) allow network layers to recognize VW traffic and make routing >> decisions based on its characteristics." >> >> Is client<>server traffic for individual worlds not primarily >> something for individual worlds rather than an interop issue? >> For example, you might be on world A, and talking to world B via >> world >> A's servers, but your client<>server traffic is still running A's >> protocol. At the server<>server end is this kind of QoS actually >> useful? >> >> On Sat, Feb 21, 2009 at 11:10 AM, Morgaine >> wrote: >>> >>> >>> On Sat, Feb 21, 2009 at 9:14 AM, Gareth Nelson >>> wrote: >>> >>>> So, why don't we get on with voting on a charter? >>>> As for discussing implementation details now - nothing wrong with >>>> doing so if it's in the same basic area as the formal working group >>>> would be >>> >>> >>> That work has already started, Gareth, although the discussion >>> might have >>> preceded your joining the list. :-) >>> >>> To help your navigation, I'll unpick the messy email threading for >>> you: >>> >>> 1) John Hurliman first pointed out the inappropriateness of >>> references to >>> OGP in the charter of a workgroup whose mission it is to examine >>> what is >>> appropriate in the first place: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00012.html >>> >>> 2) I agreed, and affirmed that we are definitely not here to >>> rubberstamp >>> Linden proposals, and hence that we should start immediately on >>> improving >>> the charter: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00013.html >>> >>> 3) Infinity responded extremely positively and noted that the >>> initial draft >>> was highly LL/IBM-specific since they were the two authors of the >>> draft, but >>> invited John and myself (and everyone else on the list of course) >>> to submit >>> concrete proposals for improvements: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00015.html >>> >>> 4) I responded with an offer to help directly: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00016.html >>> >>> 5) Based off the LL/IBM original (#1), John provided the first >>> improved >>> draft charter (#2): >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00032.html >>> >>> 6) Based off John's draft #2, I made improvements for clarity and >>> removed an >>> ambiguity, to give us draft #3: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00036.html >>> >>> 7) Infinity and I then exchanged several emails in the list to >>> narrow down >>> whether the word "proprietary" was substantive, or just a residue >>> from the >>> initial version. The clear conclusion was that it was highly >>> substantive, >>> and therefore I further modified my version with a clear statement >>> that we >>> are in the business of defining open, non-proprietary standards, >>> which >>> became draft #4: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html >>> >>> There have been no specific updates since then. >>> >>> Needless to say, if you or anyone else requires further changes, >>> then pick >>> up the baton and run with it! I look forward to draft #5. :-) >>> >>> I am sure the text will undergo numerous further iterations before >>> we >>> finally agree on an effective charter that can be passed at the >>> BoF. The >>> MMOX list is currently examining other issues, but it is certain >>> to return >>> to the charter as the BoF draws nearer. >>> >>> Morgaine. >>> >>> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Sat Feb 21 11:33:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB4323A6A49 for ; Sat, 21 Feb 2009 11:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XWXKQquLfH1 for ; Sat, 21 Feb 2009 11:33:19 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 3C9073A67AF for ; Sat, 21 Feb 2009 11:33:19 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 5C3293DBC45D; Sat, 21 Feb 2009 11:33:35 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Catherine Pfeffer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 11:33:33 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Schedule for marshalling / unmarshalling foundation X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:33:19 -0000 On Feb 21, 2009, at 5:28 AM, Catherine Pfeffer wrote: > Perharps October is a bit far away for this, yes. But some people > have expressed serious concerns about details like all integers > being 32 bits and signed. I think that simply rubberstamping > "existing specs and code" would be a mistake. There is not even an > agreement on the xxSD name. Not to say there is still an ongoing > debate about whether LLSD is the way to go, or whether an existing > mechanism like ASN should be preferred. Even though I think LLSD has > a lot of merits, I think such questioning should not be evacuated > with the back of the hand. +1 cathy. our aim is "consensus + working code" and i don't think we'll get consensus without extensive discussion. however... i would point out... no one has published a draft for an abstract type system under a different name, so i think the LLSD name is probably going to stick. and ASN.1 / BER encoding is not appropriate for loosely coupled systems. From infinity@lindenlab.com Sat Feb 21 11:39:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E126E28C13F for ; Sat, 21 Feb 2009 11:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldOhOQHN2efV for ; Sat, 21 Feb 2009 11:39:48 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 1911228C132 for ; Sat, 21 Feb 2009 11:39:27 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id E4C8B3DBC45D; Sat, 21 Feb 2009 11:39:42 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Catherine Pfeffer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 11:39:41 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Schedule for marshalling / unmarshalling foundation X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:39:49 -0000 On Feb 21, 2009, at 5:28 AM, Catherine Pfeffer wrote: > As for the attempt to eject pseudonymous users like me from this > mailing list. it is not appreciated. While I recognize IETF will > never provide attribution for intellectual material suggested by > anonymous and pseudonymous users, I think that external persons who > have no business interests in this all affair but only their love > for virtual worlds and intellectual honesty to bring in should be > allowed to lurk and comment on this mailing list. let me be clear about this. there has been NO attempt to eject users simply because they wish to participate pseudonymously. the policy is to allow pseudonymous participation in the list. but pseudonymous participation does NOT relieve you of your requirement to disclose your IPR as outlined in the frequently mentioned NOTEWELL page at http://www.ietf.org/NOTEWELL.html and the IETF IPR disclosure page at https://datatracker.ietf.org/ipr/about/ . IETF policy also requires the use of legal names on internet drafts and rfcs. but yes. pseudonymous participation, as long as it remains constructive and on-topic, is allowed and welcomed. -cheers -meadhbh From lisa.dusseault@messagingarchitects.com Fri Feb 20 11:19:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2369728C14B for ; Fri, 20 Feb 2009 11:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hCcFyYYSxXuh for ; Fri, 20 Feb 2009 11:19:30 -0800 (PST) Received: from mplus1.messagingarchitects.com (bastille.messagingarchitects.com [216.94.112.120]) by core3.amsl.com (Postfix) with ESMTP id 84A263A67E7 for ; Fri, 20 Feb 2009 11:19:29 -0800 (PST) Received: from [192.168.1.100] lisad@messagingarchitects.com [74.95.2.169] by mplus1.messagingarchitects.com with M+ Extreme Email Engine 2008.4.debug; Fri, 20 Feb 2009 14:19:43 -0500 X-MailFrom: lisa.dusseault@messagingarchitects.com Message-Id: <363AEEBB-2B2F-494F-BFDB-04CD6114AB12@messagingarchitects.com> From: Lisa Dusseault To: mmox@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-17--847661080 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 20 Feb 2009 11:19:36 -0800 References: <913D54FAAD0B4F40A6C67321B4091B1B3095091E8B@NOK-EUMSG-04.mgdnok.nokia.com> X-Mailer: Apple Mail (2.930.3) X-Mplus-Virus-Scanned: mplusversion: 2008.4.debug ; timestamp: Fri, 20 Feb 2009 14:19:44 -0500 engine: XCFAntiVirus1 Engine; version: 3874 (20090220)/1082 (20090213)/1089 (20090219)/1.009 (20070910) result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus2 Engine; version: 5.1.00/5530 result: 0 ; ref: none; status: success; error: none engine: XCFAntiVirus3 Engine; version: 5.07.0001 result: 0 ; ref: str=0001.0A010205.499F024B.006E,ss=1,fgs=0; status: success; error: none X-Mplus-Spam-Scanned: mplusversion: 2008.4.debug ; timestamp: Fri, 20 Feb 2009 14:19:45 -0500 engine: XCFSPAM1 Engine ; version: Not Available ; level: 0 ref: 0-0-0-15519-c status: success ;error: none engine: XCFSPAM4 Engine ; version: 5.1.2/2009.02.20.15.13.22/2005.02.11.04.44.13/0/0/2007.01.28.16.09.00/2007.02.13.01.23.26/0/0/2009.01.22.21.42.10/2009.02.20.19.01.00/2009.02.20.02.40.00/2009.02.20.19.12.39/0/0/2009.02.14.00.34.21/; level: 1 ref: status: success ;error: none X-Mailman-Approved-At: Sat, 21 Feb 2009 11:39:56 -0800 Subject: [mmox] Fwd: Suggestions for AppArea meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:19:31 -0000 --Apple-Mail-17--847661080 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable FYI -- some education of the IETF community seems in order! I went =20 through a process not unlike Zoltans and still have a long way to go. Lisa Begin forwarded message: > From: > Date: February 20, 2009 12:21:34 AM PST > To: , > Cc: > Subject: RE: Suggestions for AppArea meeting > > Hi Lisa, > I am new to virtual worlds, therefore I was wondering about this =20 > myself. > > My initial guesses were: > - Chat. But chat does not make sense - why would a Star Wars guy =20 > talk with a guy from Warcraft? They are immersed in their own =20 > virtual worlds; what can these two individuals possibly have in =20 > common; why would they care about the other? Unless of course they =20 > know each other from the real world - in which case they have dozens =20= > of existing tools they can use to talk with each other. > - Moving between virtual worlds (the player could leave things =20 > behind and walk through a teleport or something that takes him to =20 > another world). But then again, what would a level 12 orc warrior =20 > become in the Star Wars world? Would the old character be discarded? =20= > Where would "his story" begin in the new virtual world? Usually it =20 > starts with a "birth" - which he obviously already had. > - Trading property. Actually, trading would make sense but the =20 > property should not be transferable between the virtual worlds =20 > (otherwise the first warrior with a Star Destroyer would rule the =20 > virtual world in Warcraft until a decent wizard brings over a =20 > lightsaber and an X-Wing - ruining the virtual world for everyone). =20= > So, if the property was to stay in the virtual world, why would a =20 > Warcraft player buy a Millenium Falcon in the other virtual world? > > Then, I decided to give up speculation - thinking I am surely off =20 > the track. > > I would prefer having a general introduction during the Apps Opening =20= > as well - a few use cases should put me on the right track. > > Thank you. > > Best regards: Zolt=E1n =D6rd=F6gh > E-mail: zoltan dot ordogh at nokia dot com > Phone: +358 50 386 0566 > > -----Original Message----- > From: apps-discuss-bounces@ietf.org = [mailto:apps-discuss-bounces@ietf.org=20 > ] On Behalf Of ext Lisa Dusseault > Sent: 19 February, 2009 19:15 > To: apps-discuss@ietf.org > Cc: Chris Newman > Subject: Suggestions for AppArea meeting > > > Any suggestions for using the AppArea time on Monday morning? > > So far, I would like to have MMOX people explain in very general =20 > terms the opportunities for interoperability between virtual =20 > worlds. Neal Stephenson's Metaverse, here we come! > > LIsa > > --- Scanned by M+ Guardian Messaging Firewall --- Messaging =20 > Architects sponsors The Spamhaus Project. > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. --Apple-Mail-17--847661080 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI -- some education of the = IETF community seems in order!  I went through a process not unlike = Zoltans and still have a long way to = go.

Lisa

Begin forwarded = message:

Date: February 20, 2009 12:21:34 AM = PST
To: <lisa.dusseault@mess= agingarchitects.com>, <apps-discuss@ietf.org>
Cc: <Chris.Newman@Sun.COM>
Subject: = RE: Suggestions for AppArea meeting

Hi = Lisa,
I am new to virtual worlds, therefore I was wondering about = this myself.

My initial guesses were:
- Chat. But chat does = not make sense - why would a Star Wars guy talk with a guy from = Warcraft? They are immersed in their own virtual worlds; what can these = two individuals possibly have in common; why would they care about the = other? Unless of course they know each other from the real world - in = which case they have dozens of existing tools they can use to talk with = each other.
- Moving between virtual worlds (the player could leave = things behind and walk through a teleport or something that takes him to = another world). But then again, what would a level 12 orc warrior become = in the Star Wars world? Would the old character be discarded? Where = would "his story" begin in the new virtual world? Usually it starts with = a "birth" - which he obviously already had.
- Trading property. = Actually, trading would make sense but the property should not be = transferable between the virtual worlds (otherwise the first warrior = with a Star Destroyer would rule the virtual world in Warcraft until a = decent wizard brings over a lightsaber and an X-Wing - ruining the = virtual world for everyone). So, if the property was to stay in the = virtual world, why would a Warcraft player buy a Millenium Falcon in the = other virtual world?

Then, I decided to give up speculation - = thinking I am surely off the track.

I would prefer having a = general introduction during the Apps Opening as well - a few use cases = should put me on the right track.

Thank you.

Best regards: = Zolt=E1n =D6rd=F6gh
E-mail: zoltan dot ordogh at nokia dot = com
Phone: +358 50 386 0566

-----Original = Message-----
From: apps-discuss-bounces@ietf.or= g [mailto:apps-discuss-bounces@= ietf.org] On Behalf Of ext Lisa Dusseault
Sent: 19 February, 2009 = 19:15
To: apps-discuss@ietf.org
Cc: = Chris Newman
Subject: Suggestions for AppArea meeting


Any = suggestions for using the AppArea time on Monday morning?

So far, = I would like to have MMOX people explain in very general terms the = opportunities for interoperability between virtual worlds.  Neal = Stephenson's Metaverse, here we come!

LIsa

--- Scanned by = M+ Guardian Messaging Firewall --- Messaging Architects sponsors The = Spamhaus = Project.

_______________________________________________
Apps-Di= scuss mailing list
Apps-Discuss@ietf.org
https://www.ie= tf.org/mailman/listinfo/apps-discuss

<= /div>= --- Scanned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors The Spamhaus Project. --Apple-Mail-17--847661080-- From yesha.sivan@gmail.com Sat Feb 21 11:45:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F4AF3A6C3C for ; Sat, 21 Feb 2009 11:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9T-Czl0WHy1 for ; Sat, 21 Feb 2009 11:45:38 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.187]) by core3.amsl.com (Postfix) with ESMTP id C1C3E3A69F4 for ; Sat, 21 Feb 2009 11:45:37 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w9so1315922mue.9 for ; Sat, 21 Feb 2009 11:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=MHXr0R0i5PYlAiCIDiUMdHmP877x5R23Dn8a0ULFdTA=; b=QW93UTl2hvDeZQ06Efry77j6Y+5IgNgBGZGGxpCrUsvaFpJAJR5DrUur3QJ5Z3DPSj 1kuJQU8ZojAW+YhD+GJF6ISCuHQZZJsBeaXbajtSwiNvzWAr8SZj2oAbfuZ+6rNsbhai m7S/3W12jle7KZ/Gvj1QIJgeyn3cpJOmzjzew= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=pmYejRPbbo57wof/Mp5Aomm+/kgXLTM8SxMDV870SoMdFiFCVJw9f6R917TOZqvvab X3mpk/m3onrQR8llItUZa6swsYYs0EbIRH0NhNyyKp4qzBxSmCQ0ZJbOh7L9dCOWiZEx DJ4VFHVJPSf5mTHYdnkRjJgLKxMRsUPhpiHhk= MIME-Version: 1.0 Sender: yesha.sivan@gmail.com Received: by 10.103.189.15 with SMTP id r15mr2489244mup.126.1235245551865; Sat, 21 Feb 2009 11:45:51 -0800 (PST) In-Reply-To: <61dbdd7d0902211100x7451ee8dy536051dd32ccbe7c@mail.gmail.com> References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <61dbdd7d0902211100x7451ee8dy536051dd32ccbe7c@mail.gmail.com> Date: Sat, 21 Feb 2009 21:45:51 +0200 X-Google-Sender-Auth: 1f27af96bab5838b Message-ID: <3e3ef2f00902211145q28460ae3jcb94cf809d9de5b2@mail.gmail.com> From: Yesha Sivan To: Gareth Nelson Content-Type: multipart/alternative; boundary=001636417e19544e7c04637304e1 Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:45:39 -0000 --001636417e19544e7c04637304e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Could someone send a reference to what is OGP? --Yesha Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual Worlds. On Sat, Feb 21, 2009 at 9:00 PM, Gareth Nelson wrote: > Looking again, this is very very OGP-biased, is this not something we > ought to correct? > > On Sat, Feb 21, 2009 at 6:40 PM, Charles Krinke wrote: > > I am reading the group charter again at : > > > > http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter > > > > I guess the action item for the near term is to make this charter as > > acceptable as possible to gain some credence from the IETF? > > > > Do I get that right? Is this our main action item at this point? > > > > Charles > > > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --001636417e19544e7c04637304e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Could someone send a reference to what is OGP?

--Ye= sha

Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual Worlds.


On Sat, Feb 21, 2009 at 9:00 PM, Gareth = Nelson <gareth@l= itesim.com> wrote:
Looking again, this is very very OGP-biased, is this not something we
ought to correct?

On Sat, Feb 21, 2009 at 6:40 PM, Charles Krinke <cfk@pacbell.net> wrote:
> I am reading the group cha= rter again at :
>
> http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter
>
> I guess the action item for the near term is to make this charter as > acceptable as possible to gain some credence from the IETF?
>
> Do I get that right? Is this our main action item at this point?
>
> Charles
>
> ____________________= ___________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
>
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--001636417e19544e7c04637304e1-- From cfk@pacbell.net Sat Feb 21 11:57:28 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AD628C155 for ; Sat, 21 Feb 2009 11:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfvCKWw7C1QZ for ; Sat, 21 Feb 2009 11:57:27 -0800 (PST) Received: from web82608.mail.mud.yahoo.com (web82608.mail.mud.yahoo.com [68.142.201.125]) by core3.amsl.com (Postfix) with SMTP id 25B4D28C147 for ; Sat, 21 Feb 2009 11:57:26 -0800 (PST) Received: (qmail 28315 invoked by uid 60001); 21 Feb 2009 19:57:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=gn72Z/xJCAzcHVRt3cIIq2qDlvFqs9Y3v6QTDuK3Y6mqcAr+7v+gSOCl7xzIhgKGiA8ICgZ+rV0W6B/ar5JdCHuXf4QcI3twmifNIMjLarKzRCKOKdFi124ddKaxz0IDR6kUGVVyYsfE7zRvlA3+YdSethe8SBy9IiGSS+jiEXo=; X-YMail-OSG: .mpsWfUVM1nY3IDaIjtGS7iTElJ7tRxzmI82Ff8hrb06vgyKvgC56.zd71u9x8iNmAdJS796u1hfUwXrIDBAPWE4r8V8OcMxx3_fBSpMKdRll2jR7eYTqSZpIaQhnuVmITu50Flp4em0m0Nr3bLxEIAKxtQv2msB4bc.5giyY0ZFnZIcm7A7NFfa7cLpK2IxqSDHK1MCQ8RVkeX9J58yknnzEg-- Received: from [67.120.11.69] by web82608.mail.mud.yahoo.com via HTTP; Sat, 21 Feb 2009 11:57:41 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <913D54FAAD0B4F40A6C67321B4091B1B3095091E8B@NOK-EUMSG-04.mgdnok.nokia.com> <363AEEBB-2B2F-494F-BFDB-04CD6114AB12@messagingarchitects.com> Date: Sat, 21 Feb 2009 11:57:41 -0800 (PST) From: Charles Krinke To: Lisa Dusseault , mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1808498681-1235246261=:27847" Message-ID: <906244.27847.qm@web82608.mail.mud.yahoo.com> Subject: Re: [mmox] Fwd: Suggestions for AppArea meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 19:57:28 -0000 --0-1808498681-1235246261=:27847 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0ADear Zoltan:=0A=0AWell, one can certainly imagine use cases where int= erop does not matter and I suspect games are one of those for the most part= .=0A=0AMost of what we are working on is not a game, however, so we are int= erested in trade more analagous to trade between independent countries. =0A= =0AWhere one VW or "grid" might wish to trade in vehicles, buildings, furni= ture perhaps to setup educational sims, corporate meeting places, simulatio= ns of operating room etiquete, for instance.=0A=0AOr, we find that meetings= may be appropriate in one sim on one grid for a common presence. For insta= nce, on OSGrid, we have weekly meetings for the C# software developers and = we have a C# class that meets.=0A=0AThere are avatars that HyperGrid intero= p now from other grids running OpenSim to both of those meetings and they t= end to be very useful.=0A=0ACharles Krinke=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A___= _____________________________=0AFrom: Lisa Dusseault =0ATo: mmox@ietf.org=0ASent: Friday, February 20, 2009 11= :19:36 AM=0ASubject: [mmox] Fwd: Suggestions for AppArea meeting=0A=0AFYI -= - some education of the IETF community seems in order! I went through a pr= ocess not unlike Zoltans and still have a long way to go.=0A=0ALisa=0A=0A= =0A=0ABegin forwarded message:=0A=0AFrom: =0ADate:= February 20, 2009 12:21:34 AM PST=0ATo: , =0ACc: =0ASubject: RE:= Suggestions for AppArea meeting=0A=0AHi Lisa,=0AI am new to virtual worlds= , therefore I was wondering about this myself.=0A=0AMy initial guesses were= :=0A- Chat. But chat does not make sense - why would a Star Wars guy talk w= ith a guy from Warcraft? They are immersed in their own virtual worlds; wha= t can these two individuals possibly have in common; why would they care ab= out the other? Unless of course they know each other from the real world - = in which case they have dozens of existing tools they can use to talk with = each other.=0A- Moving between virtual worlds (the player could leave thing= s behind and walk through a teleport or something that takes him to another= world). But then again, what would a level 12 orc warrior become in the St= ar Wars world? Would the old character be discarded? Where would "his story= " begin in the new virtual world? Usually it starts with a "birth" - which = he obviously already had.=0A- Trading property. Actually, trading would mak= e sense but the property should not be transferable between the virtual wor= lds (otherwise the first warrior with a Star Destroyer would rule the virtu= al world in Warcraft until a decent wizard brings over a lightsaber and an = X-Wing - ruining the virtual world for everyone). So, if the property was t= o stay in the virtual world, why would a Warcraft player buy a Millenium Fa= lcon in the other virtual world?=0A=0AThen, I decided to give up speculatio= n - thinking I am surely off the track.=0A=0AI would prefer having a genera= l introduction during the Apps Opening as well - a few use cases should put= me on the right track.=0A=0AThank you.=0A=0ABest regards: Zolt=E1n =D6rd= =F6gh=0AE-mail: zoltan dot ordogh at nokia dot com=0APhone: +358 50 386 056= 6=0A=0A-----Original Message-----=0AFrom: apps-discuss-bounces@ietf.org [ma= ilto:apps-discuss-bounces@ietf.org] On Behalf Of ext Lisa Dusseault=0ASent:= 19 February, 2009 19:15=0ATo: apps-discuss@ietf.org=0ACc: Chris Newman=0AS= ubject: Suggestions for AppArea meeting=0A=0A=0AAny suggestions for using t= he AppArea time on Monday morning?=0A=0ASo far, I would like to have MMOX p= eople explain in very general terms the opportunities for interoperability = between virtual worlds. Neal Stephenson's Metaverse, here we come!=0A=0ALI= sa=0A=0A--- Scanned by M+ Guardian Messaging Firewall --- Messaging Archite= cts sponsors The Spamhaus Project.=0A=0A___________________________________= ____________=0AApps-Discuss mailing list=0AApps-Discuss@ietf.org=0Ahttps://= www.ietf.org/mailman/listinfo/apps-discuss=0A=0A--- Scanned by M+ Guardian = Messaging Firewall ---=0AMessaging Architects sponsors The Spamhaus Project= . --0-1808498681-1235246261=:27847 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Dear Zoltan:

Well, one can certainly imagine use cas= es where interop does not matter and I suspect games are one of those for t= he most part.

Most of what we are working on is not a game, however,= so we are interested in trade more analagous to trade between independent = countries.

Where one VW or "grid" might wish to trade in vehicles, = buildings, furniture perhaps to setup educational sims, corporate meeting p= laces, simulations of operating room etiquete, for instance.

Or, we = find that meetings may be appropriate in one sim on one grid for a common p= resence. For instance, on OSGrid, we have weekly meetings for the C# softwa= re developers and we have a C# class that meets.

There are avatars that HyperGrid interop now from other grids running OpenSim to both of tho= se meetings and they tend to be very useful.

Charles Krinke

<= br>




From: Lisa Dusseault &= lt;lisa.dusseault@messagingarchitects.com>
To: mmox@ietf.org
Sent: Friday, February 20, 2009 11:19:36 AM
Subject: [mmox] Fwd: Suggestions for= AppArea meeting

=0AFYI -- some education of the IETF communi= ty seems in order!  I went through a process not unlike Zoltans and st= ill have a long way to go.

Lisa

Begin f= orwarded message:

Date: February 20, 2009 12:21:3= 4 AM PST
<= div style=3D"margin: 0px;">Subject: RE: Suggestions for AppArea meeting

=
Hi Lisa,
I am new to virtual worlds, therefore I was w= ondering about this myself.

My initial guesses were:
- Chat. But= chat does not make sense - why would a Star Wars guy talk with a guy from = Warcraft? They are immersed in their own virtual worlds; what can these two= individuals possibly have in common; why would they care about the other? = Unless of course they know each other from the real world - in which case t= hey have dozens of existing tools they can use to talk with each other.
= - Moving between virtual worlds (the player could leave things behind and = walk through a teleport or something that takes him to another world). But = then again, what would a level 12 orc warrior become in the Star Wars world= ? Would the old character be discarded? Where would "his story" begin in th= e new virtual world? Usually it starts with a "birth" - which he obviously already had.
- Trading property. Actually, trading would mak= e sense but the property should not be transferable between the virtual wor= lds (otherwise the first warrior with a Star Destroyer would rule the virtu= al world in Warcraft until a decent wizard brings over a lightsaber and an = X-Wing - ruining the virtual world for everyone). So, if the property was t= o stay in the virtual world, why would a Warcraft player buy a Millenium Fa= lcon in the other virtual world?

Then, I decided to give up speculat= ion - thinking I am surely off the track.

I would prefer having a ge= neral introduction during the Apps Opening as well - a few use cases should= put me on the right track.

Thank you.

Best regards: Zolt=E1n= =D6rd=F6gh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50= 386 0566

-----Original Message-----
From: apps-discuss-bounces@ietf.or= g [mailto:app= s-discuss-bounces@ietf.org] On Behalf Of ext Lisa Dusseault
Sent: 19= February, 2009 19:15
To: apps= -discuss@ietf.org
Cc: Chris Newman
Subject: Suggestions for AppAr= ea meeting


Any suggestions for using the AppArea time on Monday = morning?

So far, I would like to have MMOX people explain in very ge= neral terms the opportunities for interoperability between virtual worlds. =  Neal Stephenson's Metaverse, here we come!

LIsa

--- Sca= nned by M+ Guardian Messaging Firewall --- Messaging Architects sponsors Th= e Spamhaus Project.

_______________________________________________
Apps-Di= scuss mailing list
Apps-Discus= s@ietf.org
https://www.ietf.org/mailman/listi= nfo/apps-discuss

--- Scanned by M= + Guardian Messaging Firewall ---=0AMessaging Architects sponsors The Spamh= aus Project.=0A=0A
--0-1808498681-1235246261=:27847-- From morgaine.dinova@googlemail.com Sat Feb 21 12:17:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DB73A69EE for ; Sat, 21 Feb 2009 12:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAHB0a8FIxhL for ; Sat, 21 Feb 2009 12:17:47 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 920D63A6917 for ; Sat, 21 Feb 2009 12:17:46 -0800 (PST) Received: by bwz5 with SMTP id 5so3658364bwz.13 for ; Sat, 21 Feb 2009 12:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Sc+htYbFOTRYWCSxO7ZRPIkHQ8GfvsmLV+jA0d+uE8I=; b=EsoeE58HpQywdYN3tUOl7EiEAnF/Yws+Wy6DhcNpsOUvUk9DGDVhoMNfmAbjIZpGq3 gf8KjwJxY5PHMPFBHDNqNfoqbEMcbE+bb4eLF7WcvAFLFK6TeJnBahtRqWinzZCprLdI iuW7qtXnv3kmpCKCFDQhC3XBowBHcNPu1h7q0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iuO3+dWn+B4pwDy1VJhzRNDeqe4OM4zerrddEzV08RJ/yveBqJZ33VwMYYj44Pf0mT CZWS4FfUkgB2C3k0SGcZ3TYZ7raRY0LAVTIuaPbdUmHPS7iXHGKBKsSNkvWvf6DlfWqb YYrkF9xMclDDucJuDZ+PTWvalds4F2yPKFzYU= MIME-Version: 1.0 Received: by 10.181.234.5 with SMTP id l5mr816904bkr.124.1235247481076; Sat, 21 Feb 2009 12:18:01 -0800 (PST) In-Reply-To: <49A04FBE.2080504@gmail.com> References: <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> Date: Sat, 21 Feb 2009 20:18:01 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=001636c5a2f751bc4104637377f5 Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 20:17:48 -0000 --001636c5a2f751bc4104637377f5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 7:02 PM, Jon Watte wrote: > > Personally, I believe that regular meshes with physics proxies are that > minimum profile, because that most closely matches how most if not all of > the distributed simulations in the world do things. > I'm afraid we have to do better than that. There is huge interest in what we call Limited Capability Clients (*LCC*s), which are typically gadget-type devices such as cellphones or PDAs used as virtual world clients, but they could in principle be absolutely anything, even scripted objects within a world itself. These tiny clients only pick those parts of a virtual world service that they need and no more --- indeed, quite often they could not cope with more. Support for such LCCs is important, both for flexibility and for accessibility. Typical use cases for LCCs are audio-only clients for attending live concerts in-world without needing visual presence, or braille clients for attending in-world textual lectures. LCCs with hardware able to display 3D visuals may choose to restrict download to only certain classes of object to avoid overload (or just to save bandwidth costs), and disabling meshes can easily be forseen as a requirement. So no, there is no minimum profile. This is one reason why LL/AWG took a capability-based approach to resource access, potentially allowing clients to pick and choose what is sent to them, although that work has not borne fruit yet. In our work here, we will have to take the needs of LCCs into account as well. Morgaine. --001636c5a2f751bc4104637377f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 21, 2009 at 7:02 PM, Jon Wat= te <jwatte@gmail.c= om> wrote:

Personally, I believe that regular meshes with physics proxies are that min= imum profile, because that most closely matches how most if not all of the = distributed simulations in the world do things.


I'm afraid we have to do better than that.&nb= sp; There is huge interest in what we call Limited Capability Clients (L= CCs), which are typically gadget-type devices such as cellphones or PDA= s used as virtual world clients, but they could in principle be absolutely = anything, even scripted objects within a world itself.   These ti= ny clients only pick those parts of a virtual world service that they need = and no more --- indeed, quite often they could not cope with more.

Support for such LCCs is important, both for flexibility and for access= ibility.  Typical use cases for LCCs are audio-only clients for attend= ing live concerts in-world without needing visual presence, or braille clie= nts for attending in-world textual lectures.  LCCs with hardware able = to display 3D visuals may choose to restrict download to only certain class= es of object to avoid overload (or just to save bandwidth costs), and disab= ling meshes can easily be forseen as a requirement.

So no, there is no minimum profile.  This is one reason why LL/AWG= took a capability-based approach to resource access, potentially allowing = clients to pick and choose what is sent to them, although that work has not= borne fruit yet.  In our work here, we will have to take the needs of= LCCs into account as well.

Morgaine.
--001636c5a2f751bc4104637377f5-- From cfk@pacbell.net Sat Feb 21 12:30:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AB6728C181 for ; Sat, 21 Feb 2009 12:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jc11PZY869hW for ; Sat, 21 Feb 2009 12:30:55 -0800 (PST) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id CC4E728C174 for ; Sat, 21 Feb 2009 12:30:55 -0800 (PST) Received: (qmail 35557 invoked by uid 60001); 21 Feb 2009 20:31:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=m19iGOoZI2EMz4K1Je+bMK9iBC+dXAE3dOMHFvVYUUavDBZjxptw8i8OlmiQ+8olXNCXy98PpXwSRBirPE/lpOebGEQRKZRUTpbwmRtDD1GguRhqooM9XjFcqJyA0qUv8CMnnouAz3lHjedqLkRORrQ9u69I0QyWTXpyW+oDALA=; X-YMail-OSG: LlTI.1oVM1nxc2Xvr6nprh4N9FTSHCUc9wI5GCr15DE717oouNHT5304gQrx4QksWsxkHGfWELsNFC4Y_bD.vvegqaJ08JZySo2i0q4vvJI8FAJXsOr2fEtDfQjpKnmvT_zmMc2msevpPxw0uQAu_.wx25lfpPjjRbPLbGRObMmhw9yovVM26OaXyYbAEab1RXU.xwKr8yz7S3_lCxWByml_ziA- Received: from [67.120.11.69] by web82605.mail.mud.yahoo.com via HTTP; Sat, 21 Feb 2009 12:31:11 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> Date: Sat, 21 Feb 2009 12:31:11 -0800 (PST) From: Charles Krinke To: Morgaine , Jon Watte MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1122346208-1235248271=:34427" Message-ID: <300431.34427.qm@web82605.mail.mud.yahoo.com> Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 20:30:57 -0000 --0-1122346208-1235248271=:34427 Content-Type: text/plain; charset=us-ascii That is a very good point, Morgaine. As we consider the notion of interop between virtual worlds, having each sim, region, grid or *whatever* be able to supply its capabilities or "CAPS" to use the LL notion to such LCC devices will certainly enhance the ability to use something like a cell-phone to have a limited prescence in SecondLife, OpenSim and others. So, perhaps as we move forward, specifiying the login steps for virtual worlds in this working group along with the responses to build up the capabilities for a particular session could be very interesting. What we need to do is specify those steps and capabilities and let the client and server negotiate a connection consistent with each capability that both the client and the server advertise to each other. Those capabilities that are mutually agreed to, can be used for a client and a server in a particular virtual world. Those which are not agreed to between the client and the server, by definition, cannot be used. Charles Krinke ________________________________ From: Morgaine To: Jon Watte Cc: Charles Krinke ; "mmox@ietf.org" Sent: Saturday, February 21, 2009 12:18:01 PM Subject: Re: [mmox] Learning from the past; focusing on the future On Sat, Feb 21, 2009 at 7:02 PM, Jon Watte wrote: Personally, I believe that regular meshes with physics proxies are that minimum profile, because that most closely matches how most if not all of the distributed simulations in the world do things. I'm afraid we have to do better than that. There is huge interest in what we call Limited Capability Clients (LCCs), which are typically gadget-type devices such as cellphones or PDAs used as virtual world clients, but they could in principle be absolutely anything, even scripted objects within a world itself. These tiny clients only pick those parts of a virtual world service that they need and no more --- indeed, quite often they could not cope with more. Support for such LCCs is important, both for flexibility and for accessibility. Typical use cases for LCCs are audio-only clients for attending live concerts in-world without needing visual presence, or braille clients for attending in-world textual lectures. LCCs with hardware able to display 3D visuals may choose to restrict download to only certain classes of object to avoid overload (or just to save bandwidth costs), and disabling meshes can easily be forseen as a requirement. So no, there is no minimum profile. This is one reason why LL/AWG took a capability-based approach to resource access, potentially allowing clients to pick and choose what is sent to them, although that work has not borne fruit yet. In our work here, we will have to take the needs of LCCs into account as well. Morgaine. --0-1122346208-1235248271=:34427 Content-Type: text/html; charset=us-ascii
That is a very good point, Morgaine.

As we consider the notion of interop between virtual worlds, having each sim, region, grid or *whatever* be able to supply its capabilities or "CAPS" to use the LL notion to such LCC devices will certainly enhance the ability to use something like a cell-phone to have a limited prescence in SecondLife, OpenSim and others.

So, perhaps as we move forward, specifiying the login steps for virtual worlds in this working group along with the responses to build up the capabilities for a particular session could be very interesting.

What we need to do is specify those steps and capabilities and let the client and server negotiate a connection consistent with each capability that both the client and the server advertise to each other.

Those capabilities that are mutually agreed to, can be used for a client and a server in a particular virtual world. Those which are not agreed to between the client and the server, by definition, cannot be used.

Charles Krinke

From: Morgaine <morgaine.dinova@googlemail.com>
To: Jon Watte <jwatte@gmail.com>
Cc: Charles Krinke <cfk@pacbell.net>; "mmox@ietf.org" <mmox@ietf.org>
Sent: Saturday, February 21, 2009 12:18:01 PM
Subject: Re: [mmox] Learning from the past; focusing on the future



On Sat, Feb 21, 2009 at 7:02 PM, Jon Watte <jwatte@gmail.com> wrote:

Personally, I believe that regular meshes with physics proxies are that minimum profile, because that most closely matches how most if not all of the distributed simulations in the world do things.


I'm afraid we have to do better than that.  There is huge interest in what we call Limited Capability Clients (LCCs), which are typically gadget-type devices such as cellphones or PDAs used as virtual world clients, but they could in principle be absolutely anything, even scripted objects within a world itself.   These tiny clients only pick those parts of a virtual world service that they need and no more --- indeed, quite often they could not cope with more.

Support for such LCCs is important, both for flexibility and for accessibility.  Typical use cases for LCCs are audio-only clients for attending live concerts in-world without needing visual presence, or braille clients for attending in-world textual lectures.  LCCs with hardware able to display 3D visuals may choose to restrict download to only certain classes of object to avoid overload (or just to save bandwidth costs), and disabling meshes can easily be forseen as a requirement.

So no, there is no minimum profile.  This is one reason why LL/AWG took a capability-based approach to resource access, potentially allowing clients to pick and choose what is sent to them, although that work has not borne fruit yet.  In our work here, we will have to take the needs of LCCs into account as well.

Morgaine.
--0-1122346208-1235248271=:34427-- From eh2th-mmox@yahoo.com Sat Feb 21 12:47:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578E528C178 for ; Sat, 21 Feb 2009 12:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDUwjf6OYR1k for ; Sat, 21 Feb 2009 12:47:49 -0800 (PST) Received: from web65701.mail.ac4.yahoo.com (web65701.mail.ac4.yahoo.com [76.13.9.93]) by core3.amsl.com (Postfix) with SMTP id 11FD43A68BD for ; Sat, 21 Feb 2009 12:47:48 -0800 (PST) Received: (qmail 13315 invoked by uid 60001); 21 Feb 2009 20:48:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=R3YQ1HmjEcvQ2WJzB4Zu2kk/IkA6zbMl8DR64/uiMXXY8XirW8sOB60Xwig7JIGN5blXzyNoa4237aCfNok2tfQTSSqm2GakPw+Fa3SHmGgEoyBqSkU6Iek6KtYuuYcfsn6AhBpbibCP8HeTowFrhDcHNrgssLbJ7I2/anBP8s4=; X-YMail-OSG: fAXf1SEVM1n3QPQmhzUBY6oCn5m4m.16s2FkHrJ9hqm8mLTB_ho_7E.8IU7SXxOPnv_LOmGMp_OISE3w.KCDwQBhsm_4OaZewwTjL_MzgqTVK7YgoR2auI4eXGAxUU7DMz4SE48KvM03c6f70hiWOolbipDZadPjHXMMOgIwiEw4FNXjj8sShseG3q8UjiJRQ2mR.lbZG0k0B6rwHldvkGp1AA-- Received: from [72.220.236.152] by web65701.mail.ac4.yahoo.com via HTTP; Sat, 21 Feb 2009 12:48:03 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <61dbdd7d0902211100x7451ee8dy536051dd32ccbe7c@mail.gmail.com> <3e3ef2f00902211145q28460ae3jcb94cf809d9de5b2@mail.gmail.com> Date: Sat, 21 Feb 2009 12:48:03 -0800 (PST) From: eh2th-mmox@yahoo.com To: Yesha Sivan , Gareth Nelson MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-164429266-1235249283=:12200" Message-ID: <284544.12200.qm@web65701.mail.ac4.yahoo.com> Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 20:47:54 -0000 --0-164429266-1235249283=:12200 Content-Type: text/plain; charset=us-ascii Open Grid Protocol is the result of the effort between Linden Lab, IBM, and OpenSim (and other interested parties) to define a protocol to allow interaction between virtual worlds. http://wiki.secondlife.com/wiki/Open_Grid_Protocol Regards, Tom Hoff ________________________________ From: Yesha Sivan To: Gareth Nelson Cc: mmox@ietf.org Sent: Saturday, February 21, 2009 11:45:51 AM Subject: Re: [mmox] MMOX Group Charter Could someone send a reference to what is OGP? --Yesha Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual Worlds. On Sat, Feb 21, 2009 at 9:00 PM, Gareth Nelson wrote: Looking again, this is very very OGP-biased, is this not something we ought to correct? On Sat, Feb 21, 2009 at 6:40 PM, Charles Krinke wrote: > I am reading the group charter again at : > > http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter > > I guess the action item for the near term is to make this charter as > acceptable as possible to gain some credence from the IETF? > > Do I get that right? Is this our main action item at this point? > > Charles > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-164429266-1235249283=:12200 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Open Grid Protocol is the result of=A0the effort between Linden L= ab, IBM, and OpenSim (and other interested parties) to define a protocol to= allow interaction between virtual worlds.


Regards,
Tom Hoff
From: Yesha Sivan <yesha.sivan@metaverse-labs.com>To: Gareth Nelson <gareth@lites= im.com>
Cc: mmox@ietf.o= rg
Sent: Saturday, Febr= uary 21, 2009 11:45:51 AM
Subject:= Re: [mmox] MMOX Group Charter

=0A
Could someone send a reference to what is OGP?

--Yesha

Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Vir= tual Worlds.
=0A

On Sat, Feb 21, 2009 = at 9:00 PM, Gareth Nelson <gareth@litesim.com> wrote:
=0ALooking again, this is very very OGP-biased,= is this not something we
=0Aought to correct?
=0A

=0AOn Sat, Feb 21, 2009 at 6:40 PM, Charles Krinke <cfk@pacbell.net> wrote:
=0A
> I am reading the group charter again at :
=0A>
= =0A> http://trac.tools.ietf.org/bof/trac/wiki/Mmox= Charter
=0A>
=0A> I guess the action item for the near term is to= make this charter as
=0A> acceptable as possible to gain some credence = from the IETF?
=0A>
=0A> Do I get that right? Is this our main action= item at this point?
=0A>
=0A> Charles
=0A>
=0A
> _______________________________________= ________
=0A> mmox mailing list
=0A> mmox@i= etf.org
=0A> https://www.ietf.org/mailman/listinfo/mm= ox
=0A>
=0A>
=0A______________________________________________= _
=0Ammox mailing list
=0Ammox@ietf.org=
=0Ahttps://www.ietf.org/mailman/listinfo/mmox
=0A=

=0A
--0-164429266-1235249283=:12200-- From morgaine.dinova@googlemail.com Sat Feb 21 13:32:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5163E3A6917 for ; Sat, 21 Feb 2009 13:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6Y1yyZ21UQE for ; Sat, 21 Feb 2009 13:32:37 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id EDBAB3A69A8 for ; Sat, 21 Feb 2009 13:32:36 -0800 (PST) Received: by bwz5 with SMTP id 5so3689064bwz.13 for ; Sat, 21 Feb 2009 13:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NUDWdIs1GMRnn1p6f04oxOsCpQMPUsHBGFQzrGJPisU=; b=eD3jHB7iEllclkOJQaAtTd2Uy7WSx4p3eZ7DOKLB2ZcxvLCcK1FrnuTyVCA/dkby2B Idoy6ccrW+2ibJgMZCicT/lCPHvGYvDXMkWLAC/iM7HtWMvkucjDfKn4mI3oFLx4YQyU nxYgYw88XmL0MXSnidNtGjobCdITH1N4A/Pqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l5LsYxs0hDsWX+HfgDErLuURKaBo2wWnWWVpKIm2F57vyP2XY2lqzLzPieoJIdaFNF glAY7nySQNMJfjYp1+XyrvA2oGP4tqdr9/4nD02drqfc6qGF+jK/4lxbWCSBMOdtW3nF stpendQ7l47QLMC/7MJmGlo6Fi6G+L/4T1/ZY= MIME-Version: 1.0 Received: by 10.181.221.15 with SMTP id y15mr839334bkq.121.1235251971186; Sat, 21 Feb 2009 13:32:51 -0800 (PST) In-Reply-To: <49A04EBA.6000404@gmail.com> References: <62BFE5680C037E4DA0B0A08946C0933D50263405@rrsmsx506.amr.corp.intel.com> <499FB5C8.4030900@gmail.com> <49A04EBA.6000404@gmail.com> Date: Sat, 21 Feb 2009 21:32:51 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=001636c5a3edf35f77046374826f Cc: "mmox@ietf.org" Subject: Re: [mmox] My evaluation of LLSD+LLIDL X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 21:32:38 -0000 --001636c5a3edf35f77046374826f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 6:58 PM, Jon Watte wrote: > > In engineering, you usually have the requirements before you start > building. After all, if you start building a house, the way you've always > built houses, and half-way through, you realize that the house is for > Giraffes, then don't you feel foolish? > Nope, I don't feel foolish because they're both made of bricks. ;-) And that's not a joke, because in the paragraph that you didn't quote, I had written: "*We all have experience of one virtual world or several, and therefore we know the datatypes needed for interop: it is the superset of all the ones we use or imagine we might use, which is a rather small set of primitive types plus some composite construction material.*" So we already know what bricks we need, although we might think ahead a bit and add a few more likely candidates just for future proofing. It's the higher level requirements that we won't know until we start examining multiple virtual worlds in detail. While we don't know now what the payloads will be, we certainly know in what serializable form the payloads will be represented from cumulative experience within the group. Morgaine. --001636c5a3edf35f77046374826f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 21, 2009 at 6:58 PM, Jon Wat= te <jwatte@gmail.c= om> wrote:
 
In engineering, you usually have the requirements before you start building= . After all, if you start building a house, the way you've always built= houses, and half-way through, you realize that the house is for Giraffes, = then don't you feel foolish?


Nope, I don't feel foolish because they'r= e both made of bricks. ;-)

And that's not a joke, because in the= paragraph that you didn't quote, I had written:

 "= We all have experience of one virtual world or several, and therefore we know the datatypes needed for interop:  it is the superset of all the ones we use or imagine we might use, which is a rather small set of primitive types plus some composite construction material."
So we already know what bricks we need, although we might think ahead a bi= t and add a few more likely candidates just for future proofing.

It's the higher level requirements that we won't know until we star= t examining multiple virtual worlds in detail.  While we don't kno= w now what the payloads will be, we certainly know in what serializable for= m the payloads will be represented from cumulative experience within the gr= oup.

Morgaine.
--001636c5a3edf35f77046374826f-- From lenglish5@cox.net Sat Feb 21 13:46:53 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED71D3A6AE5 for ; Sat, 21 Feb 2009 13:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.468 X-Spam-Level: X-Spam-Status: No, score=0.468 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVt6jbeKcSsL for ; Sat, 21 Feb 2009 13:46:53 -0800 (PST) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id 19F0D3A6C54 for ; Sat, 21 Feb 2009 13:46:53 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090221214709.RIRY12540.fed1rmmtao106.cox.net@fed1rmimpo01.cox.net>; Sat, 21 Feb 2009 16:47:09 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id Jln81b0034N6T0Q03ln80U; Sat, 21 Feb 2009 16:47:08 -0500 X-Authority-Analysis: v=1.0 c=1 a=LDm9XwtCGnUA:10 a=3Avk7fh389cA:10 a=Wajolswj7cQA:10 a=0Gz1-RcceoGGGgeE3WwA:9 a=pZkUpulq4vdTALbnzwIA:7 a=PYc40ZhBtEHq0wLF63CYbMPAbpEA:4 a=8b0TY1xhFYQA:10 X-CM-Score: 0.00 Message-ID: <49A0765C.2080307@cox.net> Date: Sat, 21 Feb 2009 14:47:08 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Schedule for marshalling / unmarshalling foundation X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 21:46:54 -0000 Catherine Pfeffer wrote: > Gareth said: > > October 2009 Publication of LLSD Draft as an Informational RFC > > > > Is there a reason this milestone is set so late? LLSD is already > > fairly well defined. I would go so far as to say that the existing > > specs and code can be RFC-alised as-is with only some subtle changes > > as compatibility dictates. > > Perharps October is a bit far away for this, yes. But some people have > expressed serious concerns about details like all integers being 32 > bits and signed. I think that simply rubberstamping "existing specs > and code" would be a mistake. There is not even an agreement on the > xxSD name. Not to say there is still an ongoing debate about whether > LLSD is the way to go, or whether an existing mechanism like ASN > should be preferred. Even though I think LLSD has a lot of merits, I > think such questioning should not be evacuated with the back of the hand. > > As for the attempt to eject pseudonymous users like me from this > mailing list. it is not appreciated. While I recognize IETF will never > provide attribution for intellectual material suggested by anonymous > and pseudonymous users, I think that external persons who have no > business interests in this all affair but only their love for virtual > worlds and intellectual honesty to bring in should be allowed to lurk > and comment on this mailing list. > +1 Cathy. though, for some vague definition of "on topic" we should probably try to keep posts "on topic" (says the ultimate spamdroid of Second Life). L. From lenglish5@cox.net Sat Feb 21 14:02:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 854863A6929 for ; Sat, 21 Feb 2009 14:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.834 X-Spam-Level: X-Spam-Status: No, score=0.834 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23iIP2b9GSdp for ; Sat, 21 Feb 2009 14:02:48 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id 0F92A3A6878 for ; Sat, 21 Feb 2009 14:02:48 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090221220301.VUDP4363.fed1rmmtao103.cox.net@fed1rmimpo03.cox.net>; Sat, 21 Feb 2009 17:03:01 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id Jm311b0094N6T0Q04m31ro; Sat, 21 Feb 2009 17:03:01 -0500 X-Authority-Analysis: v=1.0 c=1 a=4g_lH8AF1Z8A:10 a=0vmOfoeZa2UA:10 a=Wajolswj7cQA:10 a=vTnJ1Te69Qtb7N302SMA:9 a=wuXmpAzALWzPyd0itS4H-ZbGEpsA:4 a=6UxOEEjT9BUA:10 X-CM-Score: 0.00 Message-ID: <49A07A15.1080303@cox.net> Date: Sat, 21 Feb 2009 15:03:01 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gareth Nelson References: <989654.10197.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902211014m29684a55va88d87a64f8b1d30@mail.gmail.com> In-Reply-To: <61dbdd7d0902211014m29684a55va88d87a64f8b1d30@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Getting more virtual worlds participating X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:02:52 -0000 Gareth Nelson wrote: > What use are user reps if they can't actually speak to changes on WoW? > Personally, I realise this may be controversial, I do not believe that > we should focus on games too much - games are by their very nature not > going to benefit from a lot of the interop work. Who wants to TP from > SL into WoW and then TP out of WoW into a game of counterstrike? > > You're not thinking "out of the box" and assuming all games in the mmox space will look like wow/eq/eve online. What about a meta game spanning hundreds of worlds supported by different vendors? A cross between spore, escape velocity/eve online, and Vampire: the masquerade, etc? Lawson From lenglish5@cox.net Sat Feb 21 14:32:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F263A6885 for ; Sat, 21 Feb 2009 14:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QC3XTFgjpBP3 for ; Sat, 21 Feb 2009 14:32:21 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id E36D33A677D for ; Sat, 21 Feb 2009 14:32:20 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090221223237.CGHN10385.fed1rmmtao107.cox.net@fed1rmimpo03.cox.net>; Sat, 21 Feb 2009 17:32:37 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id JmYc1b00J4N6T0Q04mYcYu; Sat, 21 Feb 2009 17:32:36 -0500 X-Authority-Analysis: v=1.0 c=1 a=cvwy08X6BTcA:10 a=goDEM_hwrrwA:10 a=Wajolswj7cQA:10 a=pGLkceISAAAA:8 a=evjuoLmxCxLojbJSu04A:9 a=FG9HQQ6zcx-8_C6nuW_gTy62NXMA:4 a=zUBsD6tbDSsA:10 a=MSl-tDqOz04A:10 X-CM-Score: 0.00 Message-ID: <49A08104.3020400@cox.net> Date: Sat, 21 Feb 2009 15:32:36 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> In-Reply-To: <49A04FBE.2080504@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:32:22 -0000 Jon Watte wrote: > Morgaine wrote: >> >> >> On Sat, Feb 21, 2009 at 1:00 AM, Jon Watte > > wrote: >> >> >> - Geometry is based on regular meshes, possibly with LOD switches >> and lower-resolution physics meshes/proxies/hulls. I understand >> that this may be a sticking point for the SL-derived worlds (or do >> they actually support arbitrary meshes as an option now? I haven't >> kept up.) >> >> >> We're defining mechanism, not policy, so there is no possible >> sticking point for Linden Lab if the interop standard provides for >> interchange of meshes as is so widely required. LL are free to not >> implement meshes if they choose not to do so, that's all. I believe >> that such a decision would impact on their business, but it is not up >> to me (nor us) to make that call. >> >> By the same token, if we define interchange of SL-like "primitive" >> objects to be in the standard, then anyone who wants to benefit from >> the acceleration and standardized behaviour of such primitives is >> free to implement them (the Opensim worlds certainly will), but >> nobody is /required/ to do so. > > > I think that's taking too much policy out of the equation. We need to > define a minimum policy that any interoperating world will accept, so > that an interoperating system will actually work. Defining just empty > pipes, and letting people fill them with whatever, doesn't lead us > anywhere closer towards actual, useful, working interoperability. > > Compare to MPEG 4: there are a few "profiles" defined, where any > device that claims to support a given profile, knows that it can play > back any content authored for that profile. And, this is important, > there is a minimum profile that anything has to implement; if you want > your content to be universally useful, then you author to that profile. > > Personally, I believe that regular meshes with physics proxies are > that minimum profile, because that most closely matches how most if > not all of the distributed simulations in the world do things. > > Sincerely, > > jw > "Most" by company count, but not necessarily by user count (unless you count the closed garden gameworlds) and certainly not by asset-count. There's more plywood boxes in SL than there are objects in the rest of the multiverse, I suspect. L. From jwatte@gmail.com Sat Feb 21 14:50:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3CC43A6917 for ; Sat, 21 Feb 2009 14:50:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJYQUd5pMkbb for ; Sat, 21 Feb 2009 14:50:54 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 3E2EA3A6774 for ; Sat, 21 Feb 2009 14:50:54 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1325189rvb.49 for ; Sat, 21 Feb 2009 14:51:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=dNObbBpIl1X1/bAvxkd8HjRGJ5y1kFyvvnJEWfLOS/M=; b=MRqPQBdh+spAa2TZGo9Dnw/hMk+PnXIkRq3nKo1NuhQVT9Mw+eGMfBCNRegLjIBHOm wxuyNy+RhJ2ij0F0WjyueVC5z3Pl+MvtbfNchMaqpZL7uvweaFCdXn4r/GLTTtpDjNkC jOXZclEBZoP0kPOFfYz+wRiUf/3Idfa/Hc5qc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=UXvVVE0L/Ze3b6FwH13T1Lj14w5SmWB1GG+8ie1DI29iUf8FmwxdPn4QhOdAkBqW8b 5PdBpZMlI+6C6AA2C+DMHQBf0yS8pS1nErk1Gua3qmh0/Z3RvZNJO4rPB5Ao/PDZlQXI ozDUfKX/oOE4wrKdk0joaFTsk431BeSmFviLI= Received: by 10.141.141.3 with SMTP id t3mr1196815rvn.3.1235256669631; Sat, 21 Feb 2009 14:51:09 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id g31sm9698296rvb.7.2009.02.21.14.51.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 14:51:09 -0800 (PST) Message-ID: <49A0855C.5030801@gmail.com> Date: Sat, 21 Feb 2009 14:51:08 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <989654.10197.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902211014m29684a55va88d87a64f8b1d30@mail.gmail.com> In-Reply-To: <61dbdd7d0902211014m29684a55va88d87a64f8b1d30@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Getting more virtual worlds participating X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:50:58 -0000 Gareth Nelson wrote: > Personally, I realise this may be controversial, I do not believe that > we should focus on games too much - games are by their very nature not > going to benefit from a lot of the interop work. Who wants to TP from > SL into WoW and then TP out of WoW into a game of counterstrike? > I agree. However, I hope we have enough games background collectively on the list to avoid precluding games in the future. Also, if we could get someone like Multiverse or Kaneva to show up, that might help with that perspective. Also, I'll ask some people I know at IMVU (which I believe is still within scope?) Sincerely, jw From cfk@pacbell.net Sat Feb 21 14:55:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241E73A6825 for ; Sat, 21 Feb 2009 14:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EA0h6sIjG3xs for ; Sat, 21 Feb 2009 14:55:56 -0800 (PST) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id E5BB03A6816 for ; Sat, 21 Feb 2009 14:55:55 -0800 (PST) Received: (qmail 55009 invoked by uid 60001); 21 Feb 2009 22:56:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=L2uzCfPP5Zbi/rDBo7qURm6nL+3sWoWIDoJfVQ4fAete2l2Q84NYzlcYzCrK/h97Xrw+U1fGjRb4G55ODRyk0VR3km2EVtTY35v+AlYX8NDNVujDen2A5RKvzEv2UfMAcGv/+WR1sXMnMhRh32mOdKKlpuz+Re9nLgu895ARrUY=; X-YMail-OSG: iRVLZYMVM1nabNBVJ01ZXbpvmEHD0NeBCIx6tYxItlMC7nhWIdCoIVAtBBDJCbdgpUL7YM__I0gkO3zzmXhRGwJZXnBvTy79kjpS1FS3vOdBACMaahEWJwYKxqcLiWGDdMByzN6tfavnqjjFwc3LcliQyGo6qMJzftK8aKbGSIHGWpOYcQ5jeeQ242X217qZDZgpSMigQ1t8odrY4xZf4LaRyfY- Received: from [67.120.11.69] by web82605.mail.mud.yahoo.com via HTTP; Sat, 21 Feb 2009 14:56:11 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <49A08104.3020400@cox.net> Date: Sat, 21 Feb 2009 14:56:11 -0800 (PST) From: Charles Krinke To: lenglish5@cox.net, Jon Watte MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1189999712-1235256971=:52962" Message-ID: <182040.52962.qm@web82605.mail.mud.yahoo.com> Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:55:57 -0000 --0-1189999712-1235256971=:52962 Content-Type: text/plain; charset=us-ascii Yes, I would have to agree with you Lawson. But, perhaps in doing interop, we can have a capabilities message that defines whether the world one is teleporting to has mesh or prim capabilities. That would allow us to have a way to tailor the client and server performance a bit to accomodate the differences. There are a considerable number of users in SecondLife and quite a few businesses using SecondLife, so the "prim" notion is not unreasonable for an interop protocol. However, as time goes on, it is also entirely reasonable that meshes may reign supreme. Charles Krinke OpenSim Core Developer OSGrid Director ________________________________ From: Lawson English To: Jon Watte Cc: "mmox@ietf.org" Sent: Saturday, February 21, 2009 2:32:36 PM Subject: Re: [mmox] Learning from the past; focusing on the future Jon Watte wrote: > Morgaine wrote: >> >> >> On Sat, Feb 21, 2009 at 1:00 AM, Jon Watte > wrote: >> >> >> - Geometry is based on regular meshes, possibly with LOD switches >> and lower-resolution physics meshes/proxies/hulls. I understand >> that this may be a sticking point for the SL-derived worlds (or do >> they actually support arbitrary meshes as an option now? I haven't >> kept up.) >> >> >> We're defining mechanism, not policy, so there is no possible sticking point for Linden Lab if the interop standard provides for interchange of meshes as is so widely required. LL are free to not implement meshes if they choose not to do so, that's all. I believe that such a decision would impact on their business, but it is not up to me (nor us) to make that call. >> >> By the same token, if we define interchange of SL-like "primitive" objects to be in the standard, then anyone who wants to benefit from the acceleration and standardized behaviour of such primitives is free to implement them (the Opensim worlds certainly will), but nobody is /required/ to do so. > > > I think that's taking too much policy out of the equation. We need to define a minimum policy that any interoperating world will accept, so that an interoperating system will actually work. Defining just empty pipes, and letting people fill them with whatever, doesn't lead us anywhere closer towards actual, useful, working interoperability. > > Compare to MPEG 4: there are a few "profiles" defined, where any device that claims to support a given profile, knows that it can play back any content authored for that profile. And, this is important, there is a minimum profile that anything has to implement; if you want your content to be universally useful, then you author to that profile. > > Personally, I believe that regular meshes with physics proxies are that minimum profile, because that most closely matches how most if not all of the distributed simulations in the world do things. > > Sincerely, > > jw > "Most" by company count, but not necessarily by user count (unless you count the closed garden gameworlds) and certainly not by asset-count. There's more plywood boxes in SL than there are objects in the rest of the multiverse, I suspect. L. _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-1189999712-1235256971=:52962 Content-Type: text/html; charset=us-ascii
Yes, I would have to agree with you Lawson. But, perhaps in doing interop, we can have a capabilities message that defines whether the world one is teleporting to has mesh or prim capabilities. That would allow us to have a way to tailor the client and server performance a bit to accomodate the differences.

There are a considerable number of users in SecondLife and quite a few businesses using SecondLife, so the "prim" notion is not unreasonable for an interop protocol. However, as time goes on, it is also entirely reasonable that meshes may reign supreme.

Charles Krinke
OpenSim Core Developer
OSGrid Director

From: Lawson English <lenglish5@cox.net>
To: Jon Watte <jwatte@gmail.com>
Cc: "mmox@ietf.org" <mmox@ietf.org>
Sent: Saturday, February 21, 2009 2:32:36 PM
Subject: Re: [mmox] Learning from the past; focusing on the future

Jon Watte wrote:
> Morgaine wrote:
>>
>>
>> On Sat, Feb 21, 2009 at 1:00 AM, Jon Watte <jwatte@gmail.com <mailto:jwatte@gmail.com>> wrote:
>>
>>
>>    - Geometry is based on regular meshes, possibly with LOD switches
>>    and lower-resolution physics meshes/proxies/hulls. I understand
>>    that this may be a sticking point for the SL-derived worlds (or do
>>    they actually support arbitrary meshes as an option now? I haven't
>>    kept up.)
>>
>>
>> We're defining mechanism, not policy, so there is no possible sticking point for Linden Lab if the interop standard provides for interchange of meshes as is so widely required.  LL are free to not implement meshes if they choose not to do so, that's all.  I believe that such a decision would impact on their business, but it is not up to me (nor us) to make that call.
>>
>> By the same token, if we define interchange of SL-like "primitive" objects to be in the standard, then anyone who wants to benefit from the acceleration and standardized behaviour of such primitives is free to implement them (the Opensim worlds certainly will), but nobody is /required/ to do so.
>
>
> I think that's taking too much policy out of the equation. We need to define a minimum policy that any interoperating world will accept, so that an interoperating system will actually work. Defining just empty pipes, and letting people fill them with whatever, doesn't lead us anywhere closer towards actual, useful, working interoperability.
>
> Compare to MPEG 4: there are a few "profiles" defined, where any device that claims to support a given profile, knows that it can play back any content authored for that profile. And, this is important, there is a minimum profile that anything has to implement; if you want your content to be universally useful, then you author to that profile.
>
> Personally, I believe that regular meshes with physics proxies are that minimum profile, because that most closely matches how most if not all of the distributed simulations in the world do things.
>
> Sincerely,
>
> jw
>

"Most" by company count, but not necessarily by user count (unless you count the closed garden gameworlds) and certainly not by asset-count.  There's more plywood boxes in SL than there are objects in the rest of the multiverse, I suspect.

L.



_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--0-1189999712-1235256971=:52962-- From jwatte@gmail.com Sat Feb 21 14:56:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4038F3A6955 for ; Sat, 21 Feb 2009 14:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgwEICpHg2YP for ; Sat, 21 Feb 2009 14:56:26 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 96B353A68DC for ; Sat, 21 Feb 2009 14:56:26 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1326003rvb.49 for ; Sat, 21 Feb 2009 14:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8Rl0Av3vVhq2Yeza7aifsP7mkmQL6uXEs7rDY+5BrG0=; b=VnuHKW6KostfrQzDqqFUAvDjGO4epoyD65BqTO4fOQ0YnYBd6cCJ0J3RaWDdxlfb9U wcV3ElGUEyIWNjpguwkPa4V+E6hWgGIrG5KOKF1NRBmJy1BO2cIHmDIIs0unTYBaGtDm e7rr1mpnu+m19yYiMTGsic0izy6AMePdbF7Dg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Hi02BAxWM2Wu/VkHhLbp/LzJBxY2pga/S82Hhb3ZochqW8ZjSoMPwX2rxYz6QIymWj lbyYC7Iq03y6G9sCHFRxR4ja/GxBvLM/h9uhTBI+CoXi2T1opAJWD7rSp6D/kCczo54E QzxNSRmydDL+jH3gvnxOr6qtkwi7oELDFIbsc= Received: by 10.141.98.18 with SMTP id a18mr1183500rvm.194.1235257001559; Sat, 21 Feb 2009 14:56:41 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b39sm4363303rvf.9.2009.02.21.14.56.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 14:56:41 -0800 (PST) Message-ID: <49A086A7.3080703@gmail.com> Date: Sat, 21 Feb 2009 14:56:39 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke References: <62BFE5680C037E4DA0B0A08946C0933D50263405@rrsmsx506.amr.corp.intel.com> <499FB5C8.4030900@gmail.com> <49A04EBA.6000404@gmail.com> <567408.22128.qm@web82604.mail.mud.yahoo.com> In-Reply-To: <567408.22128.qm@web82604.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] My evaluation of LLSD+LLIDL X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:56:27 -0000 Charles Krinke wrote: > Well, we already have interop with both OGP and HyperGrid between > multiple projects, companies and grids, so at this point the question > is how to seek consensus with other virtual worlds. > > As I have said before, the architecture exists, OGP exists, HyperGrid > exists. Folks are using them, folks are extending them. Folks are > moving forward. > > Our only hope is to add some personality into the mix as the train > gathers speed. It already appears to have left the station. With that kind of thinking, the train left the station when IEEE 1278 was ratified. There are a number of problems with OGP, which I have enumerated, when it comes to the architecture of "generic" virtual worlds, in the broad. The fact that a few worlds that use the SL architecture can talk together using the current OGP (is there a newer document than version 5?) does not mean that that protocol is, in itself, technology agnostic, or even suitable for a wider interoperability standard. In the end, everyone will have to write code to implement whatever standard comes out, I don't think we can avoid that. Sincerely, jw From morgaine.dinova@googlemail.com Sat Feb 21 15:00:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF763A6825 for ; Sat, 21 Feb 2009 15:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjICd0oQKm5u for ; Sat, 21 Feb 2009 15:00:56 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 1362B3A6816 for ; Sat, 21 Feb 2009 15:00:55 -0800 (PST) Received: by bwz5 with SMTP id 5so3721757bwz.13 for ; Sat, 21 Feb 2009 15:01:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NHx87EOAQjrYeFnppV53DS7ZZxau60rhoFfCz7nIwc0=; b=ibJcOfg6I8GJonW4rRJ/SNKD1vNp97hQdT9E1+OikucDK7uvLH1aj0kDXo0y80ksL2 QAX4gsUR/mPwlz19dJrgbPoDwFf+JYf2QB5LtQPuZeVvXg4rg0ETThCN1pPNXo6zvPdD nAPmGueDlKdPQB/05jmPa9qyz3Y624d1+Vw4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IQANobioFlN6NVH3HluP4TUy5jjgubxHEL5k4ybu+8ZVMNEDgNDBsswBumwYPdjddm xcgnm2pLO86b8FcbPBWXtpAGwL44biT1XwvZOIkjyQjm08RiAFwnlBBQDlAh2mPACtOp C8qIJvLBvhzb7MBHr3H/fFn35H7bMlf4Q2S4M= MIME-Version: 1.0 Received: by 10.181.209.5 with SMTP id l5mr868711bkq.86.1235257270004; Sat, 21 Feb 2009 15:01:10 -0800 (PST) In-Reply-To: <639687.52284.qm@web82606.mail.mud.yahoo.com> References: <639687.52284.qm@web82606.mail.mud.yahoo.com> Date: Sat, 21 Feb 2009 23:01:09 +0000 Message-ID: From: Morgaine To: Charles Krinke Content-Type: multipart/alternative; boundary=0016e6d460b8c8ed2e046375be2a Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:00:57 -0000 --0016e6d460b8c8ed2e046375be2a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 6:40 PM, Charles Krinke wrote: > I am reading the group charter again at : > > http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter > That's the original draft, #1. We're now at iteration #4, which is available in this post: http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html . The changes have been extremely important, particularly in respect of vendor neutrality. I've chronicled the group's work on the charter up to draft #4 in this post here: http://www.ietf.org/mail-archive/web/mmox/current/msg00349.html Further improvements are of course welcome and necessary. I'll try to keep people's versions chronicled, as the various mailers in use are playing havoc with the threading so finding the passage of the draft through our contributions is like picking up broken glass. I'm also maintaining a page of useful MMOX links outside IETF space which some might find helpful here: https://wiki.secondlife.com/wiki/MMOX . Under *MMOX Workgroup Charter Drafts* you can find links to the various iterations that we have made so far, as well as links to my chronicling posts. Morgaine. --0016e6d460b8c8ed2e046375be2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 21, 2009 at 6:40 PM, Charles= Krinke <cfk@pacbel= l.net> wrote:
I am reading the group charter again at :

http://tr= ac.tools.ietf.org/bof/trac/wiki/MmoxCharter


That's the original draft, = #1.  We're now at iteration #4, which is available in this post:&n= bsp; http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html .=   The changes have been extremely important, particularly in respect o= f vendor neutrality.

I've chronicled the group's work on the charter up = to draft #4 in this post here:  http://www.ietf.org/mail-archive/web/= mmox/current/msg00349.html

Further improvements are of course welcome and necessary.  I'l= l try to keep people's versions chronicled, as the various mailers in u= se are playing havoc with the threading so finding the passage of the draft= through our contributions is like picking up broken glass.

I'm also maintaining a page of useful MMOX links outside IETF space= which some might find helpful here:  https://wiki.secondlife.com/wiki/MMOX .  Under <= b>MMOX Workgroup Charter Drafts  you can find links to the various= iterations that we have made so far, as well as links to my chronicling po= sts.


Morgaine.
--0016e6d460b8c8ed2e046375be2a-- From jwatte@gmail.com Sat Feb 21 15:02:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982EB3A68DC for ; Sat, 21 Feb 2009 15:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4zy7vUXdoN2 for ; Sat, 21 Feb 2009 15:02:23 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id D72553A685F for ; Sat, 21 Feb 2009 15:02:23 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so1339646rvb.5 for ; Sat, 21 Feb 2009 15:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=VeDUe5L7ZEccTOjQXuOc6lij9CvYDkgawyxIck9wV9c=; b=U3B6Q0p8FBhgouUoCS4bRbrcgZ1CKhXD3a8rc4jwbvZ1XFaIEOA5iT12G1l/pKARKB QOlnxHK4TJsNx2JU7QQmYvuZ5IgUw+VREuHvf10r61k0N/uIvLJWoBuh5Ra0ycGk8fW1 M6yJtY1Tb9bL4gOe/k8LDliC5ij6XH23LLcSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=V0ua/QMXw5qm+mZUtNXqmdPPpJbhDt+v+baQA5JhojndzzzHzX1b//pO80MhWw6FWV 5/gMePU0/1uqqPE7Yh4FIWXHfiZ9nPXF4R3UjV7/5GyGW80JFU1JDYP6zgNL7AJ7RZps rNRndS5VU0KKa8caXloXmkm0wHFxgf9mhbrmY= Received: by 10.141.45.16 with SMTP id x16mr1184429rvj.227.1235257358934; Sat, 21 Feb 2009 15:02:38 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id g31sm9733915rvb.7.2009.02.21.15.02.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 15:02:38 -0800 (PST) Message-ID: <49A0880D.3020204@gmail.com> Date: Sat, 21 Feb 2009 15:02:37 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090221.142232.2658.1@webmail06.vgs.untd.com> In-Reply-To: <20090221.142232.2658.1@webmail06.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:02:24 -0000 dyerbrookme@juno.com wrote: > them, then...why is it good enough for your platform, but not good enough for the Metaverse? I have no idea whether it's good enough for Multiverse, Kaneva, IMVU, Linden Lab or Protosphere. They are each individual operators. If you want to enforce some global consistency metric, you have three options: 1) open bilateral agreements with each party, and sign separate agreements 2) produce a binding multi-party agreement, and get everyone to sign it at one time 3) enact a law of the land (through action of Congress) Note that 3) doesn't actually reach beyond the US, though, unless things like the Berne convention are involved. None of 1, 2 or 3 are appropriate for this list, so please take that discussion to the appropriate forum. We've already agreed that the technology should *enable* the carrying and enforcing of various diverse rights (of which c/m/t is a mere subset). You seem to ask of us, a group of a few dozen people, that we give you an iron-clad guarantee you that everyone in the world will obey by whatever conventions we adopt. Clearly, you must see why this is not possible? Sincerely, jw From tme@multicasttech.com Sat Feb 21 15:02:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5DC83A6955 for ; Sat, 21 Feb 2009 15:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.567 X-Spam-Level: X-Spam-Status: No, score=-103.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlnYdN7PrSzs for ; Sat, 21 Feb 2009 15:02:29 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id D71413A694E for ; Sat, 21 Feb 2009 15:02:28 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14736339; Sat, 21 Feb 2009 18:00:52 -0500 Message-Id: <371E52F1-061A-4660-BEA0-0E4482CEDE94@multicasttech.com> From: Marshall Eubanks To: Morgaine In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 18:02:43 -0500 References: <639687.52284.qm@web82606.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:02:29 -0000 On Feb 21, 2009, at 6:01 PM, Morgaine wrote: > > > On Sat, Feb 21, 2009 at 6:40 PM, Charles Krinke > wrote: > I am reading the group charter again at : > > http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter > > > That's the original draft, #1. We're now at iteration #4, which is > available in this post: http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html > . The changes have been extremely important, particularly in > respect of vendor neutrality. > Can't you update the wiki version ? Regards Marshall > I've chronicled the group's work on the charter up to draft #4 in > this post here: http://www.ietf.org/mail-archive/web/mmox/current/msg00349.html > > Further improvements are of course welcome and necessary. I'll try > to keep people's versions chronicled, as the various mailers in use > are playing havoc with the threading so finding the passage of the > draft through our contributions is like picking up broken glass. > > I'm also maintaining a page of useful MMOX links outside IETF space > which some might find helpful here: https://wiki.secondlife.com/wiki/MMOX > . Under MMOX Workgroup Charter Drafts you can find links to the > various iterations that we have made so far, as well as links to my > chronicling posts. > > > Morgaine. > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From morgaine.dinova@googlemail.com Sat Feb 21 15:04:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF1A3A685F for ; Sat, 21 Feb 2009 15:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-FuxuanEvqE for ; Sat, 21 Feb 2009 15:04:53 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 400473A6816 for ; Sat, 21 Feb 2009 15:04:53 -0800 (PST) Received: by fxm11 with SMTP id 11so786423fxm.13 for ; Sat, 21 Feb 2009 15:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WVk2wJf9TLxYAieo+W7eWpOPWb4Afk1xKz42ohHTyU8=; b=OT5fHpWI8HiEJqxPMZcyu0BDmiPqbX7RFhw3h1DC+9CuZp1VmqV5Cur8bTVFuAABTb I7Pz0wb/U29wZghjQ6GdMy5KU9YcrbyfDisqonqTBbdWKF9mCO6Jd4Kelex27LUx6NQr QHSc1J3fucYpBwwDo9UZhIDKeJB3BgFXnjE4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=G3gLn0ojnnTMKkBioFdBRjf0Fu6py5aUVVKnKvbdibxSOu6FclmrqdQhULdXaWz8Jf a2cB2T3ye37Nibb8WJpC9Z/2WW+UqRFc3ydH57LxfN73SEoTUtFSNDrCPy0JPhc2GXNn fNP59QSFyy08+f7Bkzh/wV1po49UdYvFRCOCk= MIME-Version: 1.0 Received: by 10.181.148.2 with SMTP id a2mr865023bko.117.1235257508112; Sat, 21 Feb 2009 15:05:08 -0800 (PST) In-Reply-To: <61dbdd7d0902211100x7451ee8dy536051dd32ccbe7c@mail.gmail.com> References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <61dbdd7d0902211100x7451ee8dy536051dd32ccbe7c@mail.gmail.com> Date: Sat, 21 Feb 2009 23:05:08 +0000 Message-ID: From: Morgaine To: Gareth Nelson Content-Type: multipart/alternative; boundary=0016e6de17a7fa2af2046375cc24 Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:04:54 -0000 --0016e6de17a7fa2af2046375cc24 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 7:00 PM, Gareth Nelson wrote: > Looking again, this is very very OGP-biased, is this not something we > ought to correct? > It's already been corrected --- I wrote this post for you this morning, you may recall: http://www.ietf.org/mail-archive/web/mmox/current/msg00349.html :-) Morgaine. --0016e6de17a7fa2af2046375cc24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 21, 2009 at 7:00 PM, Gareth = Nelson <gareth@l= itesim.com> wrote:
Looking again, this is very very OGP-biased, is this not something we
ought to correct?

It's already been cor= rected --- I wrote this post for you this morning, you may recall:  h= ttp://www.ietf.org/mail-archive/web/mmox/current/msg00349.html  :-= )


Morgaine.
--0016e6de17a7fa2af2046375cc24-- From jwatte@gmail.com Sat Feb 21 15:10:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942D53A694D for ; Sat, 21 Feb 2009 15:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdVi6ePpSYRq for ; Sat, 21 Feb 2009 15:10:00 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id B46A53A6816 for ; Sat, 21 Feb 2009 15:10:00 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1328118rvb.49 for ; Sat, 21 Feb 2009 15:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=5SeLz67pkLvBrt/VpxscP4HaDGeq2ZCAedqs7PclP+k=; b=mTh6lxXssoNqHWxGPu6kok+93bJFKAiOfLAi6EVkLF4OTG+3E6JPLqh2O/BTqLIthE h/RT3oha/BaCCnvqKtzd33otg7e3FpquIvt49fD/MLeqW3KzRBAURfkYADPeG2q5lcKC SXZhz/Ks6d6jJDmaQlvnxqDWUXgx+nuyEc5Q0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=iVuFAs9y4jZV3+gpfGSIOHf90ZfN83Hb0IlKLyq3depFJK0xrYuqrn86b0Le0MOq/+ kKpfV2fLcCgoUdgS+lIc4R+nrsZY7/Mfi+EQMuvJJvYQ2kBKA8dzR1acKE3SmJFIMQ/L 5nnJfns49Nglqs1UbEgnfcKLInXQY4dn3T4qk= Received: by 10.141.69.12 with SMTP id w12mr1194528rvk.108.1235257816385; Sat, 21 Feb 2009 15:10:16 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b8sm9740330rvf.8.2009.02.21.15.10.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 15:10:16 -0800 (PST) Message-ID: <49A089D6.7020104@gmail.com> Date: Sat, 21 Feb 2009 15:10:14 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:10:01 -0000 Morgaine wrote: > > > On Sat, Feb 21, 2009 at 7:02 PM, Jon Watte > wrote: > > > Personally, I believe that regular meshes with physics proxies are > that minimum profile, because that most closely matches how most > if not all of the distributed simulations in the world do things. > > > > I'm afraid we have to do better than that. There is huge interest in > what we call Limited Capability Clients (*LCC*s), which are typically > gadget-type devices such as cellphones or PDAs used as virtual world > clients, but they could in principle be absolutely anything, even > scripted objects within a world itself. These tiny clients only pick > those parts of a virtual world service that they need and no more --- > indeed, quite often they could not cope with more. > I knew this would come up, but I had to stop typing somewhere :-) I think it's fine for such clients to discard various kinds of data (or, rather, not request it), and for the services that serve those clients to synthesize something like an avatar for the more-capable clients they interact with. What I explicitly, specifically, do not wish, is for something like the data geometry interchange format to be loosely specified along the lines of: "You can choose an aggregation of prims, OR you can choose a regular mesh -- either is fine." That would end up with world A doing only prims, and world B doing only geometry, and they not being able to interoperate, even though they both claim to support the interoperability standard. Similarly, for voice chat, I think it is required that we say "you must support at least codec C, and may additionally support codecs X, Y or Z" -- else, again, you may find yourself not being able to "get there from here," even though the systems involved claim to be interoperable. I want profiles to be there to guarantee a high level of "plug and play." In my opinion, it's fine to define "if you do geometry, you MUST do meshes, but you COULD also do prims." Theoretically, it could be the reverse, but given that 99% of the 3D technology on Earth is mesh based, that would be a bit of cart-before-the-horse if we're looking for "common ground" consensus. Sincerely, jw From jwatte@gmail.com Sat Feb 21 15:15:00 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DEB3A6955 for ; Sat, 21 Feb 2009 15:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS+OvHYC2w9t for ; Sat, 21 Feb 2009 15:14:58 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 96E143A677D for ; Sat, 21 Feb 2009 15:14:58 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1328820rvb.49 for ; Sat, 21 Feb 2009 15:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=R/ln5Dv82yEuKlglRnIqLKdYQ1uT/ylufYIg6dtlv68=; b=Mu0tNDA58hUs+UJq8mGFvY8Xvi4PmePkoot1JVROY4f9WoWEo3eC/aH3WzPu245NuO 3wURmofyraHfoRiM5fU1CN2EILrrg4Caxp2ZTtGiW1PgEvRarRauT5uxNPYQzDXSPJz7 0wyi85GPz6X4dscrRNE/KJAHFKIzSIuJQLzRk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=eWcFmxyhIUSU5DYo1PEU+1glRLP5UEVK8MaU0YWQsi16Cl1Zy5Wup8E7Itu2yjpqmw b7tYcAdnBLi9Nu2bKQwTjF/rpbPoRt/ix6pLQqGnUBalSXkZhj4C4WWBSA2UCNox6TPz LviULHdRb1g3xfTOfY6bL1ND8rvt7l/2eE1Gk= Received: by 10.140.193.15 with SMTP id q15mr1196244rvf.78.1235258113737; Sat, 21 Feb 2009 15:15:13 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b8sm9757259rvf.8.2009.02.21.15.15.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 15:15:13 -0800 (PST) Message-ID: <49A08B00.5080302@gmail.com> Date: Sat, 21 Feb 2009 15:15:12 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Lisa Dusseault References: <913D54FAAD0B4F40A6C67321B4091B1B3095091E8B@NOK-EUMSG-04.mgdnok.nokia.com> <363AEEBB-2B2F-494F-BFDB-04CD6114AB12@messagingarchitects.com> In-Reply-To: <363AEEBB-2B2F-494F-BFDB-04CD6114AB12@messagingarchitects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Fwd: Suggestions for AppArea meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:15:00 -0000 Lisa Dusseault wrote: >> Then, I decided to give up speculation - thinking I am surely off the >> track. >> >> I would prefer having a general introduction during the Apps Opening >> as well - a few use cases should put me on the right track. For a concrete use case, check out: http://www.interopworld.com/members/node/22 Here's the important part, with some pre- and post-amble stripped: As a use case, to work through some of the areas needing attention, I use the following scenario, which is not far from what we're doing today, although without the benefit of interoperability standards: * Company A operates chemical plants. They also use virtual world platform Q for training and simulation. * City B uses virtual world platform S for city planning and emergency management. One of the plants of Company A is located in City B. * City B wants to run an emergency preparedness scenario involving a large fire at the chemical plant. * Company A has a nice, detailed simulation/model of the chemical plant in their virtual world. * City B has a virtual view of the city in their virtual world, but no specifics regarding the chemical plant. * Employees of Company A log into platform S to participate in the scenario, as usual (no big IT deployment needed). * Employees of City B log into platform Q to participate in the scenario, as usual (no big IT deployment needed). * Company A employees see city firetrucks pull up to the plant on the streets outside, and enter the plant. * City B employees (including emergency responders) can enter the chemical plant, and see the results of the high resolution simulation (which may simulate things like chemical fires and plume dispersal). To achieve this scenario, a system that interconnects the two back-ends of Company A and City B would have to deal with agreeing on the duration and "virtual area" of the exercise, agree on the content (terrain) used within the area, and agree on what entities take part of the simulation and how they interact. That's still a big mouthful, but it's something that has been done successfully in the military space for 20 years using the DIS protocol (*1). While DIS has served the military well, it is not quite suitable for an enterprise or consumer class virtual world interoperability protocol for two reasons. First, it hard-codes a lot of military knowledge into the protocol, while leaving a lot of things interesting to civilians out of the equation. Second, it is based on a peer-to-peer, trusted-network model with sizeable PDUs being broadcast between participating peers. However, taking the benefits of DIS, such as a well-defined wire protocol, a reasonable terrain/entity/interaction division, and the good results being had with an "entity telemetry" approach, should be seriously considered when defining a new protocol for virtual world interoperability. With that in mind, the areas that may need to be addressed by a back-end system integration include: 1. Physical connectivity between the instances of platform S and platform Q. May be as simple as a TCP tunnel using a firewall hole, or as complex as a PKI VPN or SSL solution. 2. Agreement on playbox (area of simulation) and duration of the scenario, to avoid a connection to linger longer than necessary, and to avoid problems like City B employees teleporting to other chemical plant areas in different cities of the virtual world of Company A. 3. Agreement on the terrain (ground and buildings) of the scenario, so everyone sees the same thing, and nobody "runs through a wall." 4. Agreement on high-level information about entities in the simulation ("people" vs "vehicles" vs "trees"). 5. Agreement on voice and text communications between the simulations. 6. Agreement on finer detail information about entities -- what do they look like; how do they animate. 7. Agreement on user interface for cross-simulation entities; for example how to present a simulated 2D plant status panel to a city worker. 8. Agreement on interaction between entities, for example: 1. what happens when a firetruck collides with a Company employee. 2. what happens when water is poured on a chemical fire. 3. what happens when a City employee pushes the "intercom" button at the gate of the plant. 9. Agreement on the exchange of instrumented data from the simulation, to help in run-time management and post-scenario analysis and review. This is certainly a large nut to crack, and probably can't be done in a single big effort. However, I believe there are pieces from this list that can be knocked down relatively easily, and provide good value to existing customers -- which means that implementation doesn't need to be on speculation, but can be driven by real needs, and real money, which is always a benefit when making sure that standards serve the needs of stakeholders. From lenglish5@cox.net Sat Feb 21 15:15:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7CC3A6955 for ; Sat, 21 Feb 2009 15:15:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqEzDpoB2wxw for ; Sat, 21 Feb 2009 15:15:33 -0800 (PST) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id 903593A677D for ; Sat, 21 Feb 2009 15:15:33 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090221231547.FFTM2948.fed1rmmtao101.cox.net@fed1rmimpo02.cox.net>; Sat, 21 Feb 2009 18:15:47 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id JnFn1b0044N6T0Q04nFnXh; Sat, 21 Feb 2009 18:15:47 -0500 X-Authority-Analysis: v=1.0 c=1 a=cvwy08X6BTcA:10 a=goDEM_hwrrwA:10 a=Wajolswj7cQA:10 a=1no9Du3ho-ngH1MGl_8A:9 a=_XIukQV1U7AmvDgTmOnNB-Ipy8cA:4 a=C35D7iIojSgA:10 X-CM-Score: 0.00 Message-ID: <49A08B23.7000003@cox.net> Date: Sat, 21 Feb 2009 16:15:47 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Charles Krinke References: <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <49A08104.3020400@cox.net> <182040.52962.qm@web82605.mail.mud.yahoo.com> In-Reply-To: <182040.52962.qm@web82605.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:15:34 -0000 Charles Krinke wrote: > Yes, I would have to agree with you Lawson. But, perhaps in doing > interop, we can have a capabilities message that defines whether the > world one is teleporting to has mesh or prim capabilities. That would > allow us to have a way to tailor the client and server performance a > bit to accomodate the differences. > > There are a considerable number of users in SecondLife and quite a few > businesses using SecondLife, so the "prim" notion is not unreasonable > for an interop protocol. However, as time goes on, it is also entirely > reasonable that meshes may reign supreme. My understanding is that prims save bandwidth, while meshes can be tailored to more efficiently use client-side resources. For a globe-trotting avatar that is constantly downloading new scenery, prims might be more efficient. For someone who plans on staying mostly in one world, meshes probably win hands down (assuming an efficient caching system in the client) . Lawson From morgaine.dinova@googlemail.com Sat Feb 21 15:24:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5343A677D for ; Sat, 21 Feb 2009 15:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsjBCCYUlyM6 for ; Sat, 21 Feb 2009 15:24:47 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id BEF513A6816 for ; Sat, 21 Feb 2009 15:24:46 -0800 (PST) Received: by bwz5 with SMTP id 5so3729161bwz.13 for ; Sat, 21 Feb 2009 15:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=C04LNU2OMJCtS3HqzgG+3Np5P9S4R0HfBSfi7xU9zk8=; b=KrDoJb6UEEw4wuzmNDNhtf0KniW3/oDf8K9bJyFM3Y8N6EwVCKbYDMO/BMs3VOIQpf Kr6PNo67AjiP8eGh+CrC6f6/WaP/XazBlG/EqwTk230cszip1ltl51GoUjfaysZAizuB MhyNTIuISNVJD1kNIuLacbMG3Ty3ngAiNEooU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=i9JP8++UbksCJhBiUpfrb7oLYsuSh8Jxjqk12RROVc6+L7XsAGDzg0kXNNGyfoTUYT 9Q/Ew5oMfpsxHMZAlpUOHkOL8rDrztpTik7O6QzIYW+NgitCyTfq9LAnAXJyzggt8anR RuGE+b9sSLEXeup679WizXXicsJ0/t4S9kd2Q= MIME-Version: 1.0 Received: by 10.181.145.7 with SMTP id x7mr866334bkn.177.1235258701231; Sat, 21 Feb 2009 15:25:01 -0800 (PST) In-Reply-To: <371E52F1-061A-4660-BEA0-0E4482CEDE94@multicasttech.com> References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <371E52F1-061A-4660-BEA0-0E4482CEDE94@multicasttech.com> Date: Sat, 21 Feb 2009 23:25:01 +0000 Message-ID: From: Morgaine To: Marshall Eubanks Content-Type: multipart/alternative; boundary=0016e65097fe17b86c04637614fd Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:24:48 -0000 --0016e65097fe17b86c04637614fd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 21, 2009 at 11:02 PM, Marshall Eubanks wrote: > > Can't you update the wiki version ? > I don't know. :-) I've asked for clarification of the rules on IETF draft update policy, but haven't received an answer yet. Clearly it would be far easier to let the IETF wiki do the history management, and far easier on the eye to look at wiki pages than emails, but I cannot proceed (even if I obtained a wiki login) until I know the rules. Morgaine. On Sat, Feb 21, 2009 at 11:02 PM, Marshall Eubanks wrote: > > On Feb 21, 2009, at 6:01 PM, Morgaine wrote: > > >> >> On Sat, Feb 21, 2009 at 6:40 PM, Charles Krinke wrote: >> I am reading the group charter again at : >> >> http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter >> >> >> That's the original draft, #1. We're now at iteration #4, which is >> available in this post: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html . The >> changes have been extremely important, particularly in respect of vendor >> neutrality. >> >> > Can't you update the wiki version ? > > Regards > Marshall > > > I've chronicled the group's work on the charter up to draft #4 in this >> post here: >> http://www.ietf.org/mail-archive/web/mmox/current/msg00349.html >> >> Further improvements are of course welcome and necessary. I'll try to >> keep people's versions chronicled, as the various mailers in use are playing >> havoc with the threading so finding the passage of the draft through our >> contributions is like picking up broken glass. >> >> I'm also maintaining a page of useful MMOX links outside IETF space which >> some might find helpful here: https://wiki.secondlife.com/wiki/MMOX . >> Under MMOX Workgroup Charter Drafts you can find links to the various >> iterations that we have made so far, as well as links to my chronicling >> posts. >> >> >> Morgaine. >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > --0016e65097fe17b86c04637614fd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 21, 2009 at 11:02 PM, Marshall Euban= ks <tme@multi= casttech.com> wrote:
 
Can't you update the wiki version ?


I don't know. :-)

I've asked for c= larification of the rules on IETF draft update policy, but haven't rece= ived an answer yet.  Clearly it would be far easier to let the IETF wi= ki do the history management, and far easier on the eye to look at wiki pag= es than emails, but I cannot proceed (even if I obtained a wiki login) unti= l I know the rules.

Morgaine.



 

On Sat, Feb 21, 2009 at 11:02 PM, Marshall Eubanks <= ;tme@multicasttech.com> wrote:

On Feb 21, 2009, at 6:01 PM, Morgaine wrote:



On Sat, Feb 21, 2009 at 6:40 PM, Charles Krinke <cfk@pacbell.net> wrote:
I am reading the group charter again at :

http://trac.tools.ietf.org/bof/trac/wiki/MmoxCharter


That's the original draft, #1.  We're now at iteration #4, whi= ch is available in this post:  http://www.ietf.org/= mail-archive/web/mmox/current/msg00066.html .  The changes ha= ve been extremely important, particularly in respect of vendor neutrality.<= br>

Can't you update the wiki version ?

Regards
Marshall


I've chronicled the group's work on the charter up to draft #4 in t= his post here:  http://www.ietf.org/mail-archive/we= b/mmox/current/msg00349.html

Further improvements are of course welcome and necessary.  I'll tr= y to keep people's versions chronicled, as the various mailers in use a= re playing havoc with the threading so finding the passage of the draft thr= ough our contributions is like picking up broken glass.

I'm also maintaining a page of useful MMOX links outside IETF space whi= ch some might find helpful here:  https://wiki.secondlife.com/wiki/MMOX&n= bsp;.  Under MMOX Workgroup Charter Drafts  you can find links to= the various iterations that we have made so far, as well as links to my ch= ronicling posts.


Morgaine.
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--0016e65097fe17b86c04637614fd-- From dyerbrookme@juno.com Sat Feb 21 15:54:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983363A67FC for ; Sat, 21 Feb 2009 15:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c22BIKT7FY4J for ; Sat, 21 Feb 2009 15:54:54 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id B01063A6889 for ; Sat, 21 Feb 2009 15:54:54 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail21.vgs.untd.com [10.181.12.161]) by smtpout06.vgs.untd.com with SMTP id AABE4BFA7ARJKYQ2 for (sender ); Sat, 21 Feb 2009 15:54:05 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNjHpgYxAssdTNtWio0kWwkw== Received: (from dyerbrookme@juno.com) by webmail21.vgs.untd.com (jqueuemail) id N9YA7LTT; Sat, 21 Feb 2009 15:53:35 PST Received: from [68.161.198.3] by webmail21.vgs.untd.com with HTTP: Sat, 21 Feb 2009 23:53:13 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 21 Feb 2009 23:53:13 GMT To: jwatte@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090221.185313.20130.1@webmail21.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:3545535784 X-MAIL-INFO: 3ad9e529e97459d9bd69d9717171a519c910497d4151b9511955a010cd0151f53029c005ede9f071ad2d89e01521596104e06974bdc0d90dbd0d35450df5a5b1b44545 X-UNTD-Peer-Info: 10.181.12.161|webmail21.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 23:54:55 -0000 Jon, By exaggerating my request for clarity regarding intentions on intellect= ual property into a request for a utopian world government with powers t= o enforce DRM and DMCA takedown absolutely and universally, you achieve = the result that no one party to this discussion then has to state what t= hey're up to regarding IP because you push it off to a utopian problem o= f utopian world government, which I don't at all myself believe in. In fact, as I study this problem more, I see that the IETF itself is not= without critics of its obvious governance issues, and that there is in = fact war in cyberheaven about what body should prevail with which princi= ples: http://www.internetmark2.org/study/Governance_analysis.html Re: "We've already agreed that the technology should *enable* the carryi= ng and enforcing of various diverse rights (of which c/m/t is a mere sub= set). Actually, your "we" didn't agree on this. Perhaps you have, in an abstac= t way. Perhaps others nod in asset. It's not an articulated policy and i= sn't in a written proposal, it's merely chat. By calling c/m/t a "mere subset" you're privileging the notion that the = default should be "sharing but getting credit" like the CC license, whic= h I believe is suspect, but that indeed is a separate discussion. Any in= vocation of CC is a cop-out however, as it's a social imperative, not a = technical solution. ____________________________________________________________ Great bargains. Homes from $10,000. Search new listings in your area. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTQyL1cXYIj4zHZDWF3ohMs= g5Tfw5LXryOsvCxmjl9lLCCBMBqFsmF/ From jwatte@gmail.com Sat Feb 21 16:11:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043953A67FC for ; Sat, 21 Feb 2009 16:11:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlXtmzQ-D9us for ; Sat, 21 Feb 2009 16:11:06 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 7162A3A677D for ; Sat, 21 Feb 2009 16:11:04 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1337249rvb.49 for ; Sat, 21 Feb 2009 16:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=PeTjLewTVwmMef/YUy9UOX/W/lg00UvvMXbI6KOmenw=; b=Zo9BS12PBXDfJMzJaXIkaJlcIjHhixYcB7pPlLGVPQRZQ+t02n6Q0UGVnGRMjn3+1l RBCd/fMC06Cn4MF+dnR5dF7a+hFB+rzus9e97bGu8Q29Bpry3rfmeOQPS+nReZc47B69 g/LIJkV61SZRIjxCNhas2Me6oHGx30oOIMUMQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Orp94BKYsZ61uybw2qE4xrk5BlUhaj2utxyjUUzFaSd5blW7ETb8zVu6N8VesOOBNT UI25A3bnKj94B3dcmkoi3mCfNR0tUMiht6DsqifvJNHQIZd/g7vyVjTybWwqsCbqDS+m HTbrXFkBCfDIjcXwoKcY+AaPqua6RKpQFdWn0= Received: by 10.141.88.3 with SMTP id q3mr1213491rvl.130.1235261479471; Sat, 21 Feb 2009 16:11:19 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id f21sm9869404rvb.2.2009.02.21.16.11.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 16:11:19 -0800 (PST) Message-ID: <49A09825.2040808@gmail.com> Date: Sat, 21 Feb 2009 16:11:17 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <639687.52284.qm@web82606.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 00:11:07 -0000 Morgaine wrote: > I'm also maintaining a page of useful MMOX links outside IETF space > which some might find helpful here: > https://wiki.secondlife.com/wiki/MMOX . Under *MMOX Workgroup Charter > Drafts* you can find links to the various iterations that we have > made so far, as well as links to my chronicling posts. Can we please move to a Wiki that doesn't require a Second Life login to edit? Sincerely, jw From jwatte@gmail.com Sat Feb 21 16:18:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EF23A680A for ; Sat, 21 Feb 2009 16:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud9EfRYe49jv for ; Sat, 21 Feb 2009 16:18:51 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.159]) by core3.amsl.com (Postfix) with ESMTP id A5D953A67FC for ; Sat, 21 Feb 2009 16:18:51 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so4756314poe.4 for ; Sat, 21 Feb 2009 16:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=fb8ubmgmigsG2k/ySAFAGEEZmvvzjIvSLsMh0StQI18=; b=i+pSc/O8nAkhnrYWS2mE5m8yUPKnGnnjB2eZLRygG3sXC55cY6kKwNitoMk/6tQHoi 7wbmdcO25JIgs9Xxy9yNojkB0ozFCyTEA0FuGMQi1RDuJ1TyfKgazt2JB8hmRz/yytoh smRRGXSQb7fc0bsFD6CUZv3nO15puXEfjtvcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=J1idOqqe8A6YJvUP1uE3TtV/SxU73m/4kk+kfG5Q2f8HtSW4/1kCWpRfyQdgG8Ti0A rg/bkq9TwncrG1S/fuWIUF495Z+fcPh13UAaD82W/Is1b6gKX8HvK8a0QwjE1/+e2AXP uAU6rVoBihfZTFfyCmo1ay82DBG2MtUYyqWbk= Received: by 10.141.195.5 with SMTP id x5mr1204618rvp.282.1235261946660; Sat, 21 Feb 2009 16:19:06 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id l31sm9854560rvb.5.2009.02.21.16.19.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 16:19:06 -0800 (PST) Message-ID: <49A099F9.9040809@gmail.com> Date: Sat, 21 Feb 2009 16:19:05 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <49A08104.3020400@cox.net> <182040.52962.qm@web82605.mail.mud.yahoo.com> <49A08B23.7000003@cox.net> In-Reply-To: <49A08B23.7000003@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 00:18:52 -0000 Lawson English wrote: > My understanding is that prims save bandwidth, while meshes can be > tailored to more efficiently use client-side resources. For a > globe-trotting avatar that is constantly downloading new scenery, > prims might be more efficient. For someone who plans on staying > mostly in one world, meshes probably win hands down (assuming an > efficient caching system in the client) . Prims have their uses, sure -- for example, almost all pysics simulations use proxy shapes (similar to prims, if I understand prims right), rather than the actual mesh. However, I would argue that 95% of all 3D content in the world (at large -- not just user generated content in a consumer-facing virtual world) is in the form of mesh data. All current 3D representation research is on how to generate meshes more effectively (from pictures, video, LIDAR data, etc), and how to code/transmit them more effectively. The only other format that comes close is good-old elevation data ("raster" or "heightmap" depending on where you're coming from). From what I understand, it's also reasonably easy to generate meshes from prim descriptions -- Second Life already does it, for display on the screen. Meanwhile, taking mesh data that exists and automatically generating prims out of that is intractable, so requiring that every interactive 3D system in the world do that is pretty much a non-starter. For an example, something as simple as an arched doorway is fairly common in regular meshes, yet can't be simply described ingeneral convex prims (of course you could create an arbitrary set of prims, like "teapot," for arbitrary special cases, but that still loses the generality of meshes). Or, to formulate it in a more direct way: Either the Second Life platforms have to add a way to display and transmit meshes (if it's not already there), OR the rest of the world has to add a way to automatically generate prims from existing meshes. One of those problems is a lot easier to solve than the other. I think requiring implementation of a generally unsolved research problems in an interoperability standard is unwise. Sincerely, jw From jwatte@gmail.com Sat Feb 21 16:23:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8A83A682F for ; Sat, 21 Feb 2009 16:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFnsUx2dAOpO for ; Sat, 21 Feb 2009 16:23:20 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 75F5C3A680A for ; Sat, 21 Feb 2009 16:23:20 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1817312wfd.31 for ; Sat, 21 Feb 2009 16:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=guYuzABIE3nwSknp9jWTq1bKBRd1dJUw31pMlxJ8llk=; b=QhFRwUkhgapnKLc4awBDVDrU+95k5t0uF0l5l/134pmmZdgaemAWFy0XhpgiBMYAO9 0+NuTnnXJ3ZyrMdh8fFarvhax4QlqK2rUIe0c/SJJOzX3n0DVoVSacPJeIyqaCXGh4F6 oLrA6lpzCDH64uLkRlMtZBk02pRwlYcBRUBmc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=mQfpW+S2qPdgvOX7le09GAQFpAfsMcEa1yYQw1aspwO8VFoRGOKHlSGxlnL4tO7VpK thU0B3fxvIFx7Qu8AZTE+Mfrzec31JVYOkUYtFYRqMv6cVD0pz6zpJFhA0/SmWhtooIP hPqESd2e+PnY9nC5s8fJzzk/2E8t2+pOwTYpg= Received: by 10.142.77.7 with SMTP id z7mr1192066wfa.18.1235262215639; Sat, 21 Feb 2009 16:23:35 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k37sm10524673rvb.1.2009.02.21.16.23.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 16:23:35 -0800 (PST) Message-ID: <49A09B06.6040303@gmail.com> Date: Sat, 21 Feb 2009 16:23:34 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090221.185313.20130.1@webmail21.vgs.untd.com> In-Reply-To: <20090221.185313.20130.1@webmail21.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 00:23:21 -0000 dyerbrookme@juno.com wrote: > Actually, your "we" didn't agree on this. Perhaps you have, in an abstact way. Perhaps others nod in asset. It's not an articulated policy and isn't in a written proposal, it's merely chat. > > I have heard lots of assent, and no dissent on the list. That's generally what "rough consensus" means. > By calling c/m/t a "mere subset" you're privileging the notion that the default should be "sharing but getting credit" like the CC license, which I believe is suspect, but that I have a hard time understanding the mind that jumps from my statement that "c/m/t is a subset of all possible permissions" to alleging that it means "notion X is privileged and should be the default." I simply did no such thing; it does not follow from logic. Anyway, I've written all I will write on that particular subject at this point, and I'll take it up again when time comes to put pen to specification. Sincerely, jw From cfk@pacbell.net Sat Feb 21 16:24:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DF93A68E4 for ; Sat, 21 Feb 2009 16:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DdF0x16xG38 for ; Sat, 21 Feb 2009 16:24:58 -0800 (PST) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id F11BD3A682F for ; Sat, 21 Feb 2009 16:24:57 -0800 (PST) Received: (qmail 90607 invoked by uid 60001); 22 Feb 2009 00:25:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=vIhZdoUBEeBb4tvF3JavzqUmJ+Ulhi8whCnTYb11XMbQLJ6QZnUBLCXrHQie8aK/H+zFw/8VY1BD60s4+FKEoskQMfkTIppDOsHBhEQETl0duNfnkH/EIQAK28u6/WcJfaLMiv/XjPGPpglg3eMy5bpCG0ZwuZdvGuYWXFop3OE=; X-YMail-OSG: Jq7jiaoVM1k6lSRmK8T0BcL7v6W3XuQ4S2S_Han2ehYVHhN_SjLS8YLoe81oSwqSmSWaIMt.r3theB64f4NnQUSmAsnHVLc75PuTQ6Bp7RAuWsze79bXhjf9TDLtV.WRFugJlyX7oWDxwZ5TUSD4n0xHgE1HVB.CJrC46uUOoWCnIM94x0J50s4NoTNqVnTnZRSi01e40msXWSHnSwqXYMqjQws- Received: from [67.120.11.69] by web82607.mail.mud.yahoo.com via HTTP; Sat, 21 Feb 2009 16:25:07 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> Date: Sat, 21 Feb 2009 16:25:07 -0800 (PST) From: Charles Krinke To: Jon Watte , Morgaine MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1789068117-1235262307=:73712" Message-ID: <492298.73712.qm@web82607.mail.mud.yahoo.com> Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 00:24:59 -0000 --0-1789068117-1235262307=:73712 Content-Type: text/plain; charset=us-ascii I see nothing wrong with Morgaine using her companies wiki for her companies draft proposals. I would say, Jon, that you could use your companies wiki for your companies draft proposals and it would be entirely fair. As I understand the process, there is a revision to the draft proposal which is on the secondlife wiki now at https://wiki.secondlife.com/wiki/MMOX and it is the one labeled draft #4. I also understand this "charter draft" does not mention LLSD or OGP at all and in reading it, it seems reasonable. Charles Krinke OpenSim Core Developer http://opensimulator.org OSGrid Director http://osgrid.org ________________________________ From: Jon Watte To: Morgaine Cc: Charles Krinke ; mmox@ietf.org Sent: Saturday, February 21, 2009 4:11:17 PM Subject: Re: [mmox] MMOX Group Charter Morgaine wrote: > I'm also maintaining a page of useful MMOX links outside IETF space which some might find helpful here: https://wiki.secondlife.com/wiki/MMOX . Under *MMOX Workgroup Charter Drafts* you can find links to the various iterations that we have made so far, as well as links to my chronicling posts. Can we please move to a Wiki that doesn't require a Second Life login to edit? Sincerely, jw --0-1789068117-1235262307=:73712 Content-Type: text/html; charset=us-ascii
I see nothing wrong with Morgaine using her companies wiki for her companies draft proposals.

I would say, Jon, that you could use your companies wiki for your companies draft proposals and it would be entirely fair.

As I understand the process, there is a revision to the draft proposal which is on the secondlife wiki now at https://wiki.secondlife.com/wiki/MMOX and it is the one labeled draft #4. I also understand this "charter draft" does not mention LLSD or OGP at all and in reading it, it seems reasonable.

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

From: Jon Watte <jwatte@gmail.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Cc: Charles Krinke <cfk@pacbell.net>; mmox@ietf.org
Sent: Saturday, February 21, 2009 4:11:17 PM
Subject: Re: [mmox] MMOX Group Charter

Morgaine wrote:
> I'm also maintaining a page of useful MMOX links outside IETF space which some might find helpful here:  https://wiki.secondlife.com/wiki/MMOX .  Under *MMOX Workgroup Charter Drafts*  you can find links to the various iterations that we have made so far, as well as links to my chronicling posts.

Can we please move to a Wiki that doesn't require a Second Life login to edit?

Sincerely,

jw

--0-1789068117-1235262307=:73712-- From cfk@pacbell.net Sat Feb 21 16:30:42 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7BA3A694D for ; Sat, 21 Feb 2009 16:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWXlADHuGNmn for ; Sat, 21 Feb 2009 16:30:40 -0800 (PST) Received: from web82603.mail.mud.yahoo.com (web82603.mail.mud.yahoo.com [68.142.201.120]) by core3.amsl.com (Postfix) with SMTP id A8C793A682F for ; Sat, 21 Feb 2009 16:30:40 -0800 (PST) Received: (qmail 895 invoked by uid 60001); 22 Feb 2009 00:30:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=JYBTasdFxMed2pYm4ppjOLnj4rXMPMoEEfPZTLOtSR68ILgYKUm0WvnuVZcfCVLeEJOdHJiiCbjyOkr5r9Qj7NavsS12v3TO6ztxBQTUs12xBjLE2P/zARiqjgf+GD4RaZ06g9SkMaVQHVTohgfPRVg8BJQT1xx/BCdBYooUOAc=; X-YMail-OSG: 8Gp8PtwVM1lX4dELQvyuJczZ0O5jWGsCAcDDybfUlpUSfPTjL5uLLzXG.oHcwhwVQ3w6Nd_CXTnq_FAFIG5aEqKmw1vkUWkRUGNdSDmeZ1m4eWrvET1TKcaIL50lpFAOCMTNSplD76ZMhckfgm.xXi4jwpfHcq8iDoXdZAFqmdiwfqfwuPJe_sovMYdgxiKATVWCtO1sxSKrpQnY2TLZR0b847g- Received: from [67.120.11.69] by web82603.mail.mud.yahoo.com via HTTP; Sat, 21 Feb 2009 16:30:56 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <49A08104.3020400@cox.net> <182040.52962.qm@web82605.mail.mud.yahoo.com> <49A08B23.7000003@cox.net> <49A099F9.9040809@gmail.com> Date: Sat, 21 Feb 2009 16:30:56 -0800 (PST) From: Charles Krinke To: Jon Watte , lenglish5@cox.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-498681287-1235262656=:99540" Message-ID: <179791.99540.qm@web82603.mail.mud.yahoo.com> Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 00:30:42 -0000 --0-498681287-1235262656=:99540 Content-Type: text/plain; charset=us-ascii I disagree. There is no reason for this to be either or. We certainly can make an interop spec that contemplates "prims", "meshes" or other geometric notions. As I see this situation evolving, there will be a number fields in negotiating capabilities between a client and a server in teleporting from one virtual world to another. Prims vs meshes are one. Havoc/ODE/Other physics engines are another. Scripting engines are a third. There will be a number of "world specific" capabilities that need to be negotiated between the client and the server the client is attempting to connect that will need capabilities fields. Charles Krinke OpenSim Core Developer http://opensimulator.org OSGrid Director http://osgrid.org ________________________________ From: Jon Watte To: lenglish5@cox.net Cc: Charles Krinke ; "mmox@ietf.org" Sent: Saturday, February 21, 2009 4:19:05 PM Subject: Re: [mmox] Learning from the past; focusing on the future Lawson English wrote: > My understanding is that prims save bandwidth, while meshes can be tailored to more efficiently use client-side resources. For a globe-trotting avatar that is constantly downloading new scenery, prims might be more efficient. For someone who plans on staying mostly in one world, meshes probably win hands down (assuming an efficient caching system in the client) . Prims have their uses, sure -- for example, almost all pysics simulations use proxy shapes (similar to prims, if I understand prims right), rather than the actual mesh. However, I would argue that 95% of all 3D content in the world (at large -- not just user generated content in a consumer-facing virtual world) is in the form of mesh data. All current 3D representation research is on how to generate meshes more effectively (from pictures, video, LIDAR data, etc), and how to code/transmit them more effectively. The only other format that comes close is good-old elevation data ("raster" or "heightmap" depending on where you're coming from). >From what I understand, it's also reasonably easy to generate meshes from prim descriptions -- Second Life already does it, for display on the screen. Meanwhile, taking mesh data that exists and automatically generating prims out of that is intractable, so requiring that every interactive 3D system in the world do that is pretty much a non-starter. For an example, something as simple as an arched doorway is fairly common in regular meshes, yet can't be simply described ingeneral convex prims (of course you could create an arbitrary set of prims, like "teapot," for arbitrary special cases, but that still loses the generality of meshes). Or, to formulate it in a more direct way: Either the Second Life platforms have to add a way to display and transmit meshes (if it's not already there), OR the rest of the world has to add a way to automatically generate prims from existing meshes. One of those problems is a lot easier to solve than the other. I think requiring implementation of a generally unsolved research problems in an interoperability standard is unwise. Sincerely, jw --0-498681287-1235262656=:99540 Content-Type: text/html; charset=us-ascii
I disagree. There is no reason for this to be either or. We certainly can make an interop spec that contemplates "prims", "meshes" or other geometric notions.

As I see this situation evolving, there will be a number fields in negotiating capabilities between a client and a server in teleporting from one virtual world to another. Prims vs meshes are one. Havoc/ODE/Other physics engines are another. Scripting engines are a third.

There will be a number of "world specific" capabilities that need to be negotiated between the client and the server the client is attempting to connect that will need capabilities fields.

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


From: Jon Watte <jwatte@gmail.com>
To: lenglish5@cox.net
Cc: Charles Krinke <cfk@pacbell.net>; "mmox@ietf.org" <mmox@ietf.org>
Sent: Saturday, February 21, 2009 4:19:05 PM
Subject: Re: [mmox] Learning from the past; focusing on the future

Lawson English wrote:
> My understanding is that prims save bandwidth, while meshes can be tailored to more efficiently use client-side resources. For a globe-trotting avatar that is constantly downloading new scenery, prims might be more efficient. For someone  who plans on staying mostly in one world, meshes probably win hands down (assuming an efficient caching system in the client) .

Prims have their uses, sure -- for example, almost all pysics simulations use proxy shapes (similar to prims, if I understand prims right), rather than the actual mesh.

However, I would argue that 95% of all 3D content in the world (at large -- not just user generated content in a consumer-facing virtual world) is in the form of mesh data. All current 3D representation research is on how to generate meshes more effectively (from pictures, video, LIDAR data, etc), and how to code/transmit them more effectively. The only other format that comes close is good-old elevation data ("raster" or "heightmap" depending on where you're coming from).

From what I understand, it's also reasonably easy to generate meshes from prim descriptions -- Second Life already does it, for display on the screen. Meanwhile, taking mesh data that exists and automatically generating prims out of that is intractable, so requiring that every interactive 3D system in the world do that is pretty much a non-starter.

For an example, something as simple as an arched doorway is fairly common in regular meshes, yet can't be simply described ingeneral convex prims (of course you could create an arbitrary set of prims, like "teapot," for arbitrary special cases, but that still loses the generality of meshes).

Or, to formulate it in a more direct way: Either the Second Life platforms have to add a way to display and transmit meshes (if it's not already there), OR the rest of the world has to add a way to automatically generate prims from existing meshes. One of those problems is a lot easier to solve than the other. I think requiring implementation of a generally unsolved research problems in an interoperability standard is unwise.

Sincerely,

jw

--0-498681287-1235262656=:99540-- From morgaine.dinova@googlemail.com Sat Feb 21 17:18:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1FB43A6923 for ; Sat, 21 Feb 2009 17:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NRuk+jEPM71 for ; Sat, 21 Feb 2009 17:18:33 -0800 (PST) Received: from mail-fx0-f164.google.com (mail-fx0-f164.google.com [209.85.220.164]) by core3.amsl.com (Postfix) with ESMTP id E3BA23A677E for ; Sat, 21 Feb 2009 17:18:32 -0800 (PST) Received: by fxm8 with SMTP id 8so623922fxm.13 for ; Sat, 21 Feb 2009 17:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=j4qsnKtLylq62YsmoghmrzXleqcOCbtMH1PZ96lepHQ=; b=EdD8afvPX/GwLOuM8lM0fnULzK6j1asRcX5M3nS0i1rRWjULIXTOWFIb24oxE85ThX xjC4yKZFxoOoRZ1Mjw7p0Mo+ftdaTlsO0Ij5I/+B1JJt9Z7AkoNCFuQKQaIMvbFD2qNe jwwW+mLKXvuvTeXGtM9ZhEXYiNPjRWmYFSsJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e9VHSQTsQY9d5V0RVwZ2T9SQCGLYjyc3ifhWajTbBjV+DexRjyNF34h/8axi6s64al ObOW9qh/ofcYHFPjHsCqd1GhOCrFekfHqYXmg355JTHxwHJOv8Ghq9R7GZNNP7Ksz2IF CE99m+3cWk66zcC1LFFl7cQ0aNehfOnl+VjlQ= MIME-Version: 1.0 Received: by 10.180.218.15 with SMTP id q15mr899375bkg.194.1235265527266; Sat, 21 Feb 2009 17:18:47 -0800 (PST) In-Reply-To: <492298.73712.qm@web82607.mail.mud.yahoo.com> References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> <492298.73712.qm@web82607.mail.mud.yahoo.com> Date: Sun, 22 Feb 2009 01:18:47 +0000 Message-ID: From: Morgaine To: Charles Krinke Content-Type: multipart/alternative; boundary=001636c5aa86f4bdd4046377aa56 Cc: mmox@ietf.org, Jon Watte Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 01:18:34 -0000 --001636c5aa86f4bdd4046377aa56 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I should clarify that I have nothing to do with Linden Lab whatsoever, other than being a resident in Second Life. That wiki is available to all SL residents, commonly for personal wiki pages --- it is in effect a public wiki. Members of the AWG use this for group communication, as in the case of the aforementioned MMOX links page that I maintain at https://wiki.secondlife.com/wiki/MMOX. There is no Linden Lab involvement in this, although of course they are welcome to improve the page if they wish, as is everyone else. Morgaine. On Sun, Feb 22, 2009 at 12:25 AM, Charles Krinke wrote: > I see nothing wrong with Morgaine using her companies wiki for her > companies draft proposals. > > I would say, Jon, that you could use your companies wiki for your companies > draft proposals and it would be entirely fair. > > As I understand the process, there is a revision to the draft proposal > which is on the secondlife wiki now at > https://wiki.secondlife.com/wiki/MMOX and it is the one labeled draft #4. > I also understand this "charter draft" does not mention LLSD or OGP at all > and in reading it, it seems reasonable. > > Charles Krinke > OpenSim Core Developer > http://opensimulator.org > OSGrid Director > http://osgrid.org > > ------------------------------ > *From:* Jon Watte > *To:* Morgaine > *Cc:* Charles Krinke ; mmox@ietf.org > *Sent:* Saturday, February 21, 2009 4:11:17 PM > *Subject:* Re: [mmox] MMOX Group Charter > > Morgaine wrote: > > I'm also maintaining a page of useful MMOX links outside IETF space which > some might find helpful here: https://wiki.secondlife.com/wiki/MMOX . > Under *MMOX Workgroup Charter Drafts* you can find links to the various > iterations that we have made so far, as well as links to my chronicling > posts. > > Can we please move to a Wiki that doesn't require a Second Life login to > edit? > > Sincerely, > > jw > > --001636c5aa86f4bdd4046377aa56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I should clarify that I have nothing to do with Linden Lab whatsoever, othe= r than being a resident in Second Life.  That wiki is available to all= SL residents, commonly for personal wiki pages --- it is in effect a publi= c wiki.

Members of the AWG use this for group communication, as in the case of = the aforementioned MM= OX links page that I maintain at https://wiki.secondlife.com/wiki/MMOX.  There is no Linden= Lab involvement in this, although of course they are welcome to improve th= e page if they wish, as is everyone else.

Morgaine.



On Sun, Feb 22, 200= 9 at 12:25 AM, Charles Krinke <cfk@pacbell.net> wrote:
I see nothing wrong with Morgaine using her companies wiki for her = companies draft proposals.

I would say, Jon, that you could use your= companies wiki for your companies draft proposals and it would be entirely= fair.

As I understand the process, there is a revision to the draft proposal = which is on the secondlife wiki now at https://wiki.secondlife.com/wiki/MMOX a= nd it is the one labeled draft #4. I also understand this "charter dra= ft" does not mention LLSD or OGP at all and in reading it, it seems re= asonable.

Charles Krinke
OpenSim Core Developer
http://opensimulator.org
OSGrid Director=
http://osgrid.org
=
From: Jon Watte <jwatte@gmail.com>
To: Morgaine <morgaine.dinov= a@googlemail.com>
Cc: Charles Krinke <cfk@pacbell.net>; mmox@ietf.org
Sent: Saturday, February 2= 1, 2009 4:11:17 PM

Subject: Re: [mmox] MMOX Group Charter

Morgaine wrote:
> I'm also maintaining a page of useful MMOX link= s outside IETF space which some might find helpful here:  https://wiki.second= life.com/wiki/MMOX .  Under *MMOX Workgroup Charter Drafts*  = you can find links to the various iterations that we have made so far, as w= ell as links to my chronicling posts.

Can we please move to a Wiki that doesn't require a Second Life log= in to edit?

Sincerely,

jw


--001636c5aa86f4bdd4046377aa56-- From cfk@pacbell.net Sat Feb 21 17:24:43 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D973A698D for ; Sat, 21 Feb 2009 17:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSS0T2s+Kqya for ; Sat, 21 Feb 2009 17:24:42 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id 0E46A3A677E for ; Sat, 21 Feb 2009 17:24:41 -0800 (PST) Received: (qmail 69839 invoked by uid 60001); 22 Feb 2009 01:24:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=PW/jvzPKjOYNzOAZH77GCkP3kAYIcG57hT69YRLwQUJmMpFQkO3BbKa9sknXc2E1n7DR+K24qxunyTimGNkzSjX2dBFlqvh4MpBf1ny1G7IG4Mqi+BrQplrh//C3F8Tp+hBAh41jn1+1uBivJusWrhJ3k79Wo4Rk+bcmzno2ywI=; X-YMail-OSG: lLCm108VM1kUhnei3UUIUi5FUA2bfHpHj1O3nCsg.2qZBaEh0gCy3CwioWUWuaGRc_HlvNe72YwuSsJEySKgb1SR3dag4o7V64.w62DlDHKFNCknO_OnS_cG3p2ttrwr59rSSsm_ZT1UixYhyhgvEhkHAgWJl5PGaltPGPqviVffjQXETxri64jD0QHjmhBdcrWiV4bdsoPtoVXfqP1XjYhHG7s- Received: from [67.120.11.69] by web82602.mail.mud.yahoo.com via HTTP; Sat, 21 Feb 2009 17:24:56 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> <492298.73712.qm@web82607.mail.mud.yahoo.com> Date: Sat, 21 Feb 2009 17:24:56 -0800 (PST) From: Charles Krinke To: Morgaine MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-540972009-1235265896=:68303" Message-ID: <766659.68303.qm@web82602.mail.mud.yahoo.com> Cc: mmox@ietf.org, Jon Watte Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 01:24:43 -0000 --0-540972009-1235265896=:68303 Content-Type: text/plain; charset=us-ascii My apologies, Morgaine. I was reacting more to the negative connotations about SecondLife in the first place. Personally, I find SecondLife to be a fine virtual world with an interesting, sometimes eclectic group. Plus, I find lots of interesting business, educational, government and scientific sims there also. I flubbed the company connotation, Morgaine and walk around with a virtual sackcloth and ashes. Charles ________________________________ From: Morgaine To: Charles Krinke Cc: Jon Watte ; mmox@ietf.org Sent: Saturday, February 21, 2009 5:18:47 PM Subject: Re: [mmox] MMOX Group Charter I should clarify that I have nothing to do with Linden Lab whatsoever, other than being a resident in Second Life. That wiki is available to all SL residents, commonly for personal wiki pages --- it is in effect a public wiki. Members of the AWG use this for group communication, as in the case of the aforementioned MMOX links page that I maintain at https://wiki.secondlife.com/wiki/MMOX. There is no Linden Lab involvement in this, although of course they are welcome to improve the page if they wish, as is everyone else. Morgaine. On Sun, Feb 22, 2009 at 12:25 AM, Charles Krinke wrote: I see nothing wrong with Morgaine using her companies wiki for her companies draft proposals. I would say, Jon, that you could use your companies wiki for your companies draft proposals and it would be entirely fair. As I understand the process, there is a revision to the draft proposal which is on the secondlife wiki now at https://wiki.secondlife.com/wiki/MMOX and it is the one labeled draft #4. I also understand this "charter draft" does not mention LLSD or OGP at all and in reading it, it seems reasonable. Charles Krinke OpenSim Core Developer http://opensimulator.org OSGrid Director http://osgrid.org ________________________________ From: Jon Watte To: Morgaine Cc: Charles Krinke ; mmox@ietf.org Sent: Saturday, February 21, 2009 4:11:17 PM Subject: Re: [mmox] MMOX Group Charter Morgaine wrote: > I'm also maintaining a page of useful MMOX links outside IETF space which some might find helpful here: https://wiki.secondlife.com/wiki/MMOX . Under *MMOX Workgroup Charter Drafts* you can find links to the various iterations that we have made so far, as well as links to my chronicling posts. Can we please move to a Wiki that doesn't require a Second Life login to edit? Sincerely, jw --0-540972009-1235265896=:68303 Content-Type: text/html; charset=us-ascii
My apologies, Morgaine. I was reacting more to the negative connotations about SecondLife in the first place. Personally, I find SecondLife to be a fine virtual world with an interesting, sometimes eclectic group. Plus, I find lots of interesting business, educational, government and scientific sims there also.

I flubbed the company connotation, Morgaine and walk around with a virtual sackcloth and ashes.

Charles

From: Morgaine <morgaine.dinova@googlemail.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: Jon Watte <jwatte@gmail.com>; mmox@ietf.org
Sent: Saturday, February 21, 2009 5:18:47 PM
Subject: Re: [mmox] MMOX Group Charter

I should clarify that I have nothing to do with Linden Lab whatsoever, other than being a resident in Second Life.  That wiki is available to all SL residents, commonly for personal wiki pages --- it is in effect a public wiki.

Members of the AWG use this for group communication, as in the case of the aforementioned MMOX links page that I maintain at https://wiki.secondlife.com/wiki/MMOX.  There is no Linden Lab involvement in this, although of course they are welcome to improve the page if they wish, as is everyone else.

Morgaine.



On Sun, Feb 22, 2009 at 12:25 AM, Charles Krinke <cfk@pacbell.net> wrote:
I see nothing wrong with Morgaine using her companies wiki for her companies draft proposals.

I would say, Jon, that you could use your companies wiki for your companies draft proposals and it would be entirely fair.

As I understand the process, there is a revision to the draft proposal which is on the secondlife wiki now at https://wiki.secondlife.com/wiki/MMOX and it is the one labeled draft #4. I also understand this "charter draft" does not mention LLSD or OGP at all and in reading it, it seems reasonable.

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

From: Jon Watte <jwatte@gmail.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Cc: Charles Krinke <cfk@pacbell.net>; mmox@ietf.org
Sent: Saturday, February 21, 2009 4:11:17 PM

Subject: Re: [mmox] MMOX Group Charter

Morgaine wrote:
> I'm also maintaining a page of useful MMOX links outside IETF space which some might find helpful here:  https://wiki.secondlife.com/wiki/MMOX .  Under *MMOX Workgroup Charter Drafts*  you can find links to the various iterations that we have made so far, as well as links to my chronicling posts.

Can we please move to a Wiki that doesn't require a Second Life login to edit?

Sincerely,

jw


--0-540972009-1235265896=:68303-- From belxjander@gmail.com Sat Feb 21 17:52:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1DBA3A67D4 for ; Sat, 21 Feb 2009 17:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.383 X-Spam-Level: X-Spam-Status: No, score=-1.383 tagged_above=-999 required=5 tests=[AWL=-0.779, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ujs1ES6UMJfk for ; Sat, 21 Feb 2009 17:52:31 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 7CC673A67B2 for ; Sat, 21 Feb 2009 17:52:31 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1353418rvb.49 for ; Sat, 21 Feb 2009 17:52:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=ycPIs+gFlG8uHAqVap2CD8llc6k9Wk5+pBi1iaAEEKQ=; b=FHbacbG1QajGQaXMatRVSduTuuYPln7AU9kEviGrbuqazoFaLFbufA6F2wuJk4rXFK qaz6zNnrfAycZjkmmD8YoFUfASBAMee/2jNzVHMmsMk1aYLYPFhxhYEaavcYOwxENNcq rfX4gyMlZYeuKIWZ07aCKK1T3/rU+/PFpgi28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=g7d+RpA+/H8E6W2LXCtxPj3em7JSQwHZa9r/PJglf9RVITqwsRLyz02e7TdtDVEFwt L6KZGhL+RUEPahEN6RUNbbUZ39H1AYvGjeW8Xmz86vSwIO4HWtCd8YApENnEbZ11fo4a IUILlk66WoQQLSpeizMTOCwJGTH+oQwsdCLSg= Received: by 10.141.42.10 with SMTP id u10mr1256703rvj.61.1235267566300; Sat, 21 Feb 2009 17:52:46 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id b8sm10006892rvf.8.2009.02.21.17.52.44 (version=SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 17:52:45 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <49A089D6.7020104@gmail.com> References: <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <49A089D6.7020104@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-jV4sxjqb5/6PaBR0j7LW" Date: Sun, 22 Feb 2009 10:47:12 +0900 Message-Id: <1235267232.7560.210.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 01:52:32 -0000 --=-jV4sxjqb5/6PaBR0j7LW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Apologies in advance but this is a partial "brain dump" message... so please read as much as you can and not reply immediately so any "object" inside a "scene" for a "3D environment" will need to have interactive handling of some kind. Do we expand beyond Identity and "presence" where each system can provide a "default AV" for "temporary" presence on that system into having material transferable between systems to map onto a given systems 3D model data ? in which case any interchange agreement is also going to include usage of a "translator" for any "modified defaults" to be transferable to the new "default mesh" to account for the modelling differences of the AV object? or are we all getting into transfer of objects before the sytems have a transfer of "presence" where one or more systems have a common "presence"? Messaging and other comminucations functions I see as being mapped using the existing Instant-Messenger/Relay-Chat/Mail systems... =46rom a personal perspective of using Guild Wars and SecondLife, with access to some others for evaluation purposes... Most of the Messaging subsystem is dependent on presence alone... Human runs Client opening "online world", and contacts are listed by two types "location" and "contactlist", "location" being presence on the same server(or map area), "contactlist" being a list of people recorded like a cellphone directory. I submit the use of an existing open Instant-Messenger for providing, "communications presence" extending "login presence"... where I am defining "login presence" as being the state of "actively logged into a VW" and "communications presence" as permitting others to make contact through either "location" or "contactlist" mechanisms (with permit/deny for "contactlist") this will result in Identity on any given VW requiring 2 parts, a "vw local" account(temporary if visitor?), a "composite" account (primary point of login). this would allow "fine-grain" sign-on to various services using existing schema I come online, I sign into my VW of choice, I set "communication:status=3Davailable", there is also the "Empathy" messenger written in python using service modules, (telepathy stack) for Instant Messenger and Voice over IP functions. I am personally avoiding transfer of in-world items and more considering another means where a person can "transfer" an item by "transfer" translators... Im also wanting to sort out discussing *active* content, as not all VWs use the same engine, (SL uses LSL, Croquet uses ???, what else?) and not all VWs are going to even support scripting... I ask that we start with presence on 1 or more concurrent systems by some means and actively be able to talk on them both before being able to transfer an item or how it appears to others (which comes into the not everyone uses the same client...) Has anyone else on this list engaged in a discussion over IRC where two or more people were trying to explain how to do something based on everyone had the same display on screen and were getting mad when the third person was saying about menu items or gadgets not where they were supposed to be? I also have the impression this list is apparently trying to work around exactly that kind of problem... everyones client is different and what is the core "same"?? I look forward to hearing back about this... Jeremy On Sat, 2009-02-21 at 15:10 -0800, Jon Watte wrote: > Morgaine wrote: > > > > > > On Sat, Feb 21, 2009 at 7:02 PM, Jon Watte > > wrote: > > > > > > Personally, I believe that regular meshes with physics proxies are > > that minimum profile, because that most closely matches how most > > if not all of the distributed simulations in the world do things. > > > > > > > > I'm afraid we have to do better than that. There is huge interest in=20 > > what we call Limited Capability Clients (*LCC*s), which are typically=20 > > gadget-type devices such as cellphones or PDAs used as virtual world=20 > > clients, but they could in principle be absolutely anything, even=20 > > scripted objects within a world itself. These tiny clients only pick=20 > > those parts of a virtual world service that they need and no more ---=20 > > indeed, quite often they could not cope with more. > > >=20 > I knew this would come up, but I had to stop typing somewhere :-) I=20 > think it's fine for such clients to discard various kinds of data (or,=20 > rather, not request it), and for the services that serve those clients=20 > to synthesize something like an avatar for the more-capable clients they=20 > interact with. >=20 > What I explicitly, specifically, do not wish, is for something like the=20 > data geometry interchange format to be loosely specified along the lines=20 > of: "You can choose an aggregation of prims, OR you can choose a regular=20 > mesh -- either is fine." That would end up with world A doing only=20 > prims, and world B doing only geometry, and they not being able to=20 > interoperate, even though they both claim to support the=20 > interoperability standard. >=20 > Similarly, for voice chat, I think it is required that we say "you must=20 > support at least codec C, and may additionally support codecs X, Y or Z"=20 > -- else, again, you may find yourself not being able to "get there from=20 > here," even though the systems involved claim to be interoperable. >=20 > I want profiles to be there to guarantee a high level of "plug and=20 > play." In my opinion, it's fine to define "if you do geometry, you MUST=20 > do meshes, but you COULD also do prims." Theoretically, it could be the=20 > reverse, but given that 99% of the 3D technology on Earth is mesh based,=20 > that would be a bit of cart-before-the-horse if we're looking for=20 > "common ground" consensus. >=20 > Sincerely, >=20 > jw >=20 > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-jV4sxjqb5/6PaBR0j7LW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJoK6gAAoJECHrKutFYVwToPQP/3FnXHfFvwdNYWhOe9kVTQbY Ka1kmTm1a2Bjlt6HVeCu4jl7ykhbY/DfuChXRSWdK57oPhATphBQ13Da++u4WdS2 ZqqfJdOcR2J4YaCsNBk8aTWdCGjhhqBmLFt5YBqwGxDQqtkZdT1IvEkJo5KQOeAP 1TA5t7tSeOrIrGmg/jp3St6Z3+SMW5VKezgdL6s9o1Of+GCIo07x8uPtaVaejYqQ kbIWP4QQaHsxIOCbUpZftBdgL0ecXHrKcuZQxIfPpMNd4xDotnoIN7Uo4NjJzRSi jJ7WKDYz2tgxpJdg8vPbybSifSs4Crl+NuXwSpi32QaVmBQWHhUmCtUfgaMEbCtI E12HAD91CoACTlPjQRRVH/WqkNfHdY5T6TCwEga3jK9JIqBLcdrX2DH6FApMeDU0 vkmHp0MmhjjpMxIF9fkQQlO3zx9ydB5g+suHxkR0RBKblCrjhDNy5q2oGgdQIo2Z A+4n8GnDeCwfLYa6zhxHkGoQliyMhVKFMwmCUJDtJEpMrTayyCWzMbeg0kM4LSJK 9/z8D8dvORK3DhSFEoSEy9zuMCUgYxJO2QylQq9Os3R8B0c61XbrYgkDEi67Dgcv to73sByU4vDxfrcO3AsYEXBum01pP0evbo8C1sepK/KnXXhTux94+hUvO3zHt/4C GBIrUAfyJHby50vmPp5O =h/sU -----END PGP SIGNATURE----- --=-jV4sxjqb5/6PaBR0j7LW-- From lenglish5@cox.net Sat Feb 21 17:54:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00E073A67D4 for ; Sat, 21 Feb 2009 17:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.815 X-Spam-Level: X-Spam-Status: No, score=0.815 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dvRHqFWj3S2 for ; Sat, 21 Feb 2009 17:54:51 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id F3D233A67B2 for ; Sat, 21 Feb 2009 17:54:50 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090222015504.IEZN4363.fed1rmmtao103.cox.net@fed1rmimpo03.cox.net>; Sat, 21 Feb 2009 20:55:04 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id Jpv31b0084N6T0Q04pv33M; Sat, 21 Feb 2009 20:55:03 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=neQvZdKBpY9EJRGKMMIA:9 a=o_riTxdIjLdKu4QQuQ3_o863RqMA:4 a=C35D7iIojSgA:10 X-CM-Score: 0.00 Message-ID: <49A0B077.1000803@cox.net> Date: Sat, 21 Feb 2009 18:55:03 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Charles Krinke References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> <492298.73712.qm@web82607.mail.mud.yahoo.com> <766659.68303.qm@web82602.mail.mud.yahoo.com> In-Reply-To: <766659.68303.qm@web82602.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jon Watte , mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 01:54:52 -0000 Charles Krinke wrote: > My apologies, Morgaine. I was reacting more to the negative > connotations about SecondLife in the first place. Personally, I find > SecondLife to be a fine virtual world with an interesting, sometimes > eclectic group. Plus, I find lots of interesting business, > educational, government and scientific sims there also. > > I flubbed the company connotation, Morgaine and walk around with a > virtual sackcloth and ashes. > > Charles Prim or mesh-based? Lawson From belxjander@gmail.com Sat Feb 21 17:59:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D40B28C104 for ; Sat, 21 Feb 2009 17:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.612 X-Spam-Level: X-Spam-Status: No, score=-1.612 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtyheGXqtKhD for ; Sat, 21 Feb 2009 17:59:26 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 219BE3A6AA1 for ; Sat, 21 Feb 2009 17:59:23 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1354635rvb.49 for ; Sat, 21 Feb 2009 17:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=5LT/N4O7sXsNael80NC0terspcycL8tvUX5VtjOrvaU=; b=Av9lPb9b/SYts84y9T7cC/sJMf8piFseQt1CMDEJWVA55aC5aurd8up5ZynOhdSrYs JvKkv8FHmFFD2JcpXpvkOruwM2SQP9KW5mc4z5HHlbpV20v3/3trJfmL5nW/Iu69wKAO MUgAsnyQ5SsbVrWYps5MvZPQWzb4IChhhXptY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=f6Su1wY/WGVPDi+wyqgfjW4SKSwYDk+es7SOkW+1j61649d1r9fqmLGeoZyGLWy3RS 0TI35pcSyifmWoE28sCnbTsnNyT2/eWld8+00G6oUdRsZRmbHX2YBpyzeotdJaicfJ0h 11X7aetxFfaZp2r91GhuLFcarKNtnLMpKEdUg= Received: by 10.140.249.21 with SMTP id w21mr1250965rvh.151.1235267979778; Sat, 21 Feb 2009 17:59:39 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id f21sm10043582rvb.2.2009.02.21.17.59.38 (version=SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 17:59:39 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <49A09825.2040808@gmail.com> References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7E5A3HKCTJLQ3VmpGWNm" Date: Sun, 22 Feb 2009 10:54:06 +0900 Message-Id: <1235267646.7560.214.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 01:59:27 -0000 --=-7E5A3HKCTJLQ3VmpGWNm Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Im willing to setup a custom Wiki on my appengine account using an own-login-session schema if thats appropriate? Im actually working on such things already though I do admit to being slow with coding (being a persistently pedant about details when coding) Sincerely, Jeremy On Sat, 2009-02-21 at 16:11 -0800, Jon Watte wrote: > Morgaine wrote: > > I'm also maintaining a page of useful MMOX links outside IETF space=20 > > which some might find helpful here: =20 > > https://wiki.secondlife.com/wiki/MMOX . Under *MMOX Workgroup Charter=20 > > Drafts* you can find links to the various iterations that we have=20 > > made so far, as well as links to my chronicling posts. >=20 > Can we please move to a Wiki that doesn't require a Second Life login to=20 > edit? >=20 > Sincerely, >=20 > jw >=20 > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-7E5A3HKCTJLQ3VmpGWNm Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJoLA+AAoJECHrKutFYVwTDG0QAOor0wSRRhKLhY3BgiXP3rqt N916cIYoHD/Aklh+b80sqmVbrkoGsFhBpeymruakFRY4f+E/gxguYb9FHovKYCOA 65J9E5itrdPU1KBTr0lWvy4frq327ULV66vlvhz+zfAT30P/gxgwkJ/Vo+YGvcQs fyxT5d/ocqduLP1pYrNlTpdXpwqk/isQPmAE50jnXk2k0U4CqHZJvZJrKl8QDAbe 0BWfbMXKK9OlP7GY0yoT8dopzIFxE2zun7HQ/0iWv2wcs4OgP/4oQO77xl9OIqKT b0T9gz29OSViRTWG+zpwVk08lYQIpl9CJ4VvJcP4TQT1JvUZe6Gc5QrN005B45qS RiwJDP2BXNr4k71OymZ9mkWtaL+12gTFGIzv86KwVna7wyMORT8kgebUra4MOCjt 3uxOzhhrn2xnrj98TF5L4KVZxbjP+w0LA6v0zaQh4/QJmlSbnOQaIpzFVINp0a7U mR/sOzZv79AHRKNRCIKAgsnW4znkKFr/+EuRVN2Zf+fVnx9x4sLXtcPfnoV1PvZY KGHMZkBgDM1FJONSrW9dvPF8oTguyFWyigTwdhwBDpPtu3TF9k+Ba2u3y4q1GR8t Unvk/Vr6kU3Zuyeck6JLPHNR4zn81Pk9hqNqNX13Wg29ybziPBFYWP1FlA+SlYLm HOLI5UCTA2UhUXW5IFqc =UWgD -----END PGP SIGNATURE----- --=-7E5A3HKCTJLQ3VmpGWNm-- From morgaine.dinova@googlemail.com Sat Feb 21 18:30:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 816FD3A68DF for ; Sat, 21 Feb 2009 18:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRvBolZazAyi for ; Sat, 21 Feb 2009 18:30:17 -0800 (PST) Received: from mail-fx0-f164.google.com (mail-fx0-f164.google.com [209.85.220.164]) by core3.amsl.com (Postfix) with ESMTP id A58473A67CF for ; Sat, 21 Feb 2009 18:30:16 -0800 (PST) Received: by fxm8 with SMTP id 8so628288fxm.13 for ; Sat, 21 Feb 2009 18:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7UncI2KQeApL+mYWLbCW02EtSTjgEgbltbj27IJl9jU=; b=ANYmPpxomk9Bs53YhqRZ9iFi3mp7KNqOOJ4R71Qu0Io0afMl0MgLx37JTZIgM6NKMj jM8usM6UImoMKEmCP32mkd90LoEGg17I4rhoDwU1D/j32r7gahZ7iHSYVWpVzIYkMHJG g596wHM9lzaKHmtSMrvoXgwL62IVj57t5dl1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n6aCGfn1gAzmWxG5O613B6uAwAT35P1YDVTYX1+I4QVoTaZvwvhV5gBX59iEcAmvmt A89Cz5GdtPIY5gI+L08H3/mYn4bkgeyWlMk3OfhDf3137B7kvoJQKsr1i7puMph0quGE OmLgsjkPf3otuCstTQXPzLWkCfGRNt4aQYGSo= MIME-Version: 1.0 Received: by 10.181.199.6 with SMTP id b6mr923578bkq.137.1235269831700; Sat, 21 Feb 2009 18:30:31 -0800 (PST) In-Reply-To: <179791.99540.qm@web82603.mail.mud.yahoo.com> References: <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <49A08104.3020400@cox.net> <182040.52962.qm@web82605.mail.mud.yahoo.com> <49A08B23.7000003@cox.net> <49A099F9.9040809@gmail.com> <179791.99540.qm@web82603.mail.mud.yahoo.com> Date: Sun, 22 Feb 2009 02:30:31 +0000 Message-ID: From: Morgaine To: Charles Krinke Content-Type: multipart/alternative; boundary=001636c5a267853250046378abd0 Cc: lenglish5@cox.net, Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 02:30:18 -0000 --001636c5a267853250046378abd0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Feb 22, 2009 at 12:30 AM, Charles Krinke wrote: > I disagree. There is no reason for this to be either or. We certainly can > make an interop spec that contemplates "prims", "meshes" or other geometric > notions. > Indeed, either/or is unnecessarily proscriptive.. I believe that we should focus on defining an extensible core protocol that allows payloads of all of these types, and others, to be carried. That's part of our general "mechanism, not policy" guideline. Morgaine. On Sun, Feb 22, 2009 at 12:30 AM, Charles Krinke wrote: > I disagree. There is no reason for this to be either or. We certainly can > make an interop spec that contemplates "prims", "meshes" or other geometric > notions. > > As I see this situation evolving, there will be a number fields in > negotiating capabilities between a client and a server in teleporting from > one virtual world to another. Prims vs meshes are one. Havoc/ODE/Other > physics engines are another. Scripting engines are a third. > > There will be a number of "world specific" capabilities that need to be > negotiated between the client and the server the client is attempting to > connect that will need capabilities fields. > > Charles Krinke > OpenSim Core Developer > http://opensimulator.org > OSGrid Director > http://osgrid.org > > > ------------------------------ > *From:* Jon Watte > *To:* lenglish5@cox.net > *Cc:* Charles Krinke ; "mmox@ietf.org" > *Sent:* Saturday, February 21, 2009 4:19:05 PM > *Subject:* Re: [mmox] Learning from the past; focusing on the future > > Lawson English wrote: > > My understanding is that prims save bandwidth, while meshes can be > tailored to more efficiently use client-side resources. For a globe-trotting > avatar that is constantly downloading new scenery, prims might be more > efficient. For someone who plans on staying mostly in one world, meshes > probably win hands down (assuming an efficient caching system in the client) > . > > Prims have their uses, sure -- for example, almost all pysics simulations > use proxy shapes (similar to prims, if I understand prims right), rather > than the actual mesh. > > However, I would argue that 95% of all 3D content in the world (at large -- > not just user generated content in a consumer-facing virtual world) is in > the form of mesh data. All current 3D representation research is on how to > generate meshes more effectively (from pictures, video, LIDAR data, etc), > and how to code/transmit them more effectively. The only other format that > comes close is good-old elevation data ("raster" or "heightmap" depending on > where you're coming from). > > From what I understand, it's also reasonably easy to generate meshes from > prim descriptions -- Second Life already does it, for display on the screen. > Meanwhile, taking mesh data that exists and automatically generating prims > out of that is intractable, so requiring that every interactive 3D system in > the world do that is pretty much a non-starter. > > For an example, something as simple as an arched doorway is fairly common > in regular meshes, yet can't be simply described ingeneral convex prims (of > course you could create an arbitrary set of prims, like "teapot," for > arbitrary special cases, but that still loses the generality of meshes). > > Or, to formulate it in a more direct way: Either the Second Life platforms > have to add a way to display and transmit meshes (if it's not already > there), OR the rest of the world has to add a way to automatically generate > prims from existing meshes. One of those problems is a lot easier to solve > than the other. I think requiring implementation of a generally unsolved > research problems in an interoperability standard is unwise. > > Sincerely, > > jw > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --001636c5a267853250046378abd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Feb 22, 2009 at 12:30 AM, Charles Krinke= <cfk@pacbell.net> wrote:
I disagree. There is no reason for this to be either or. We certainly can make an interop spec that contemplates "prims", "meshes"= ; or other geometric notions.


Indeed, = either/or is unnecessarily proscriptive..

I believe that we should f= ocus on defining an extensible core protocol that allows payloads of all of= these types, and others, to be carried.  That's part of our gener= al "mechanism, not policy" guideline.

Morgaine.



On Sun,= Feb 22, 2009 at 12:30 AM, Charles Krinke <cfk@pacbell.net> wrote:
I disagree. There is no reason for this to be either or. We certain= ly can make an interop spec that contemplates "prims", "mesh= es" or other geometric notions.

As I see this situation evolving, there will be a number fields in nego= tiating capabilities between a client and a server in teleporting from one = virtual world to another. Prims vs meshes are one. Havoc/ODE/Other physics = engines are another. Scripting engines are a third.

There will be a number of "world specific" capabilities that = need to be negotiated between the client and the server the client is attem= pting to connect that will need capabilities fields.


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


From: Jon Watte <jwatte@gmail.com>
To: lenglish5@cox.net
Cc: Charles Krinke <cfk@pacbell.net>; "mmox@ietf.org" <mmox@ietf.org>
Sent: Saturday, February 2= 1, 2009 4:19:05 PM

Subject: Re: [mmox] Learning from the past; focusing on t= he future

Lawson English wrote:
> My understanding is that prims save bandwidth= , while meshes can be tailored to more efficiently use client-side resource= s. For a globe-trotting avatar that is constantly downloading new scenery, = prims might be more efficient. For someone  who plans on staying mostl= y in one world, meshes probably win hands down (assuming an efficient cachi= ng system in the client) .

Prims have their uses, sure -- for example, almost all pysics simulatio= ns use proxy shapes (similar to prims, if I understand prims right), rather= than the actual mesh.

However, I would argue that 95% of all 3D con= tent in the world (at large -- not just user generated content in a consume= r-facing virtual world) is in the form of mesh data. All current 3D represe= ntation research is on how to generate meshes more effectively (from pictur= es, video, LIDAR data, etc), and how to code/transmit them more effectively= . The only other format that comes close is good-old elevation data ("raster" or "heightmap&qu= ot; depending on where you're coming from).

From what I understa= nd, it's also reasonably easy to generate meshes from prim descriptions= -- Second Life already does it, for display on the screen. Meanwhile, taki= ng mesh data that exists and automatically generating prims out of that is = intractable, so requiring that every interactive 3D system in the world do = that is pretty much a non-starter.

For an example, something as simple as an arched doorway is fairly comm= on in regular meshes, yet can't be simply described ingeneral convex pr= ims (of course you could create an arbitrary set of prims, like "teapo= t," for arbitrary special cases, but that still loses the generality o= f meshes).

Or, to formulate it in a more direct way: Either the Second Life platfo= rms have to add a way to display and transmit meshes (if it's not alrea= dy there), OR the rest of the world has to add a way to automatically generate prims from existing meshes. One of those problems i= s a lot easier to solve than the other. I think requiring implementation of= a generally unsolved research problems in an interoperability standard is = unwise.

Sincerely,

jw


___= ____________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--001636c5a267853250046378abd0-- From morgaine.dinova@googlemail.com Sat Feb 21 18:39:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7593A67CF for ; Sat, 21 Feb 2009 18:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD6iW1ewkJd0 for ; Sat, 21 Feb 2009 18:39:15 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 60AD63A67B2 for ; Sat, 21 Feb 2009 18:39:14 -0800 (PST) Received: by fxm11 with SMTP id 11so823070fxm.13 for ; Sat, 21 Feb 2009 18:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bSw841wWxdd2wlabv7d5I4VNIpl/UwEG4YjHD+M89iw=; b=plx8EkhVyfGOIQJtKZ2FoKtX+ZGG1siDtoVjgWB6VFuvvP8C/OqcKjulT1tcbKHNjU Dl16Efd3xV1RpyQkSsTyB6hiohODTQGwGUtQ9sfw8Q1bpBdxcjxKskHW1joWbKvNfKI9 LftAZoTiD4sSt7mvxXL75pQxDdc7yueZuMcWE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=N9beC2mDblyB64w5txCkt+NddLmK1NyAp46s9GimK6SdrJP/SEUqYi95WivPMYZqhe d1nnJy6W+IJL5YibtJvp4CfjRIbTR0yyzDoSlywK2J5hoI7zmt+t2qkMwSIknKSSJjB1 5rRIcpSJtChJNKR1k8eejICfmA9ZOaAeB67F4= MIME-Version: 1.0 Received: by 10.181.11.3 with SMTP id o3mr923450bki.172.1235270368941; Sat, 21 Feb 2009 18:39:28 -0800 (PST) In-Reply-To: <766659.68303.qm@web82602.mail.mud.yahoo.com> References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> <492298.73712.qm@web82607.mail.mud.yahoo.com> <766659.68303.qm@web82602.mail.mud.yahoo.com> Date: Sun, 22 Feb 2009 02:39:28 +0000 Message-ID: From: Morgaine To: Charles Krinke Content-Type: multipart/alternative; boundary=001636c5a66f8ad7d3046378cb6c Cc: mmox@ietf.org, Jon Watte Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 02:39:16 -0000 --001636c5a66f8ad7d3046378cb6c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Feb 22, 2009 at 1:24 AM, Charles Krinke wrote: > > I flubbed the company connotation, Morgaine and walk around with a virtual > sackcloth and ashes. > Haha, no harm done. And you do look rather fetching in that outfit. ;-) Morgaine. On Sun, Feb 22, 2009 at 1:24 AM, Charles Krinke wrote: > My apologies, Morgaine. I was reacting more to the negative connotations > about SecondLife in the first place. Personally, I find SecondLife to be a > fine virtual world with an interesting, sometimes eclectic group. Plus, I > find lots of interesting business, educational, government and scientific > sims there also. > > I flubbed the company connotation, Morgaine and walk around with a virtual > sackcloth and ashes. > > Charles > > ------------------------------ > *From:* Morgaine > *To:* Charles Krinke > *Cc:* Jon Watte ; mmox@ietf.org > *Sent:* Saturday, February 21, 2009 5:18:47 PM > *Subject:* Re: [mmox] MMOX Group Charter > > I should clarify that I have nothing to do with Linden Lab whatsoever, > other than being a resident in Second Life. That wiki is available to all > SL residents, commonly for personal wiki pages --- it is in effect a public > wiki. > > Members of the AWG use this for group communication, as in the case of the > aforementioned MMOX links page > that I maintain at https://wiki.secondlife.com/wiki/MMOX. There is no > Linden Lab involvement in this, although of course they are welcome to > improve the page if they wish, as is everyone else. > > Morgaine. > > > > On Sun, Feb 22, 2009 at 12:25 AM, Charles Krinke wrote: > >> I see nothing wrong with Morgaine using her companies wiki for her >> companies draft proposals. >> >> I would say, Jon, that you could use your companies wiki for your >> companies draft proposals and it would be entirely fair. >> >> As I understand the process, there is a revision to the draft proposal >> which is on the secondlife wiki now at >> https://wiki.secondlife.com/wiki/MMOX and it is the one labeled draft #4. >> I also understand this "charter draft" does not mention LLSD or OGP at all >> and in reading it, it seems reasonable. >> >> Charles Krinke >> OpenSim Core Developer >> http://opensimulator.org >> OSGrid Director >> http://osgrid.org >> >> ------------------------------ >> *From:* Jon Watte >> *To:* Morgaine >> *Cc:* Charles Krinke ; mmox@ietf.org >> *Sent:* Saturday, February 21, 2009 4:11:17 PM >> *Subject:* Re: [mmox] MMOX Group Charter >> >> Morgaine wrote: >> > I'm also maintaining a page of useful MMOX links outside IETF space >> which some might find helpful here: >> https://wiki.secondlife.com/wiki/MMOX . Under *MMOX Workgroup Charter >> Drafts* you can find links to the various iterations that we have made so >> far, as well as links to my chronicling posts. >> >> Can we please move to a Wiki that doesn't require a Second Life login to >> edit? >> >> Sincerely, >> >> jw >> >> > --001636c5a66f8ad7d3046378cb6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable  
On Sun, Feb 22, 2009 at 1:24 AM, Charl= es Krinke <cfk@pacb= ell.net> wrote:

I flubbed the company connotation, Morgaine and walk around wit= h a virtual sackcloth and ashes.
 
Haha, no harm done.  And you do look rather fetching= in that outfit. ;-)

Morgaine.




On Sun, Feb 22, 2009 at 1:24 AM, Charles Krinke = <cfk@pacbell.net> wrote= :
My apol= ogies, Morgaine. I was reacting more to the negative connotations about Sec= ondLife in the first place. Personally, I find SecondLife to be a fine virt= ual world with an interesting, sometimes eclectic group. Plus, I find lots = of interesting business, educational, government and scientific sims there = also.

I flubbed the company connotation, Morgaine and walk around with a virt= ual sackcloth and ashes.

Charles

From: Morgaine <morgaine.dinova@googlemail.com>To: Charles Krinke <cfk@pacbell.net>
Cc: Jon Watte &l= t;jwatte@gmail.com>; mmox@ietf.org=
Sent: Saturday, February 2= 1, 2009 5:18:47 PM

Subject: Re: [mmox] MMOX Group Charter
I should clarify that I have nothing to do with Linden Lab whatsoever, othe= r than being a resident in Second Life.  That wiki is available to all= SL residents, commonly for personal wiki pages --- it is in effect a publi= c wiki.

Members of the AWG use this for group communication, as in the case of = the aforementioned MMOX links page that I maintain at https://wiki.secondlife.com/wiki/MMOX.  There is no Linden Lab= involvement in this, although of course they are welcome to improve the pa= ge if they wish, as is everyone else.

Morgaine.



On Sun, Feb 22, 200= 9 at 12:25 AM, Charles Krinke <cfk@pacbell.net> wrote:
I see nothing wrong with Morgaine using her companies wiki for her = companies draft proposals.

I would say, Jon, that you could use your= companies wiki for your companies draft proposals and it would be entirely= fair.

As I understand the process, there is a revision to the draft proposal = which is on the secondlife wiki now at https://wiki.secondlife.co= m/wiki/MMOX and it is the one labeled draft #4. I also understand this = "charter draft" does not mention LLSD or OGP at all and in readin= g it, it seems reasonable.

Charles Krinke
OpenSim Core Developer
http://opensimulator.orgOSGrid Director
http://osg= rid.org

From: Jon Watte <jwatte@gmail.com= >
To: Morgaine <morgaine.dinova@googlemail.com>
Cc: Charles Krinke <cfk@pacbell.net>; mmox@ietf.org
Sent: Saturday, February 2= 1, 2009 4:11:17 PM

Subject: Re: [mmox] MMOX Group Charter

Morgaine wrote:
> I'm also maintaining a page of useful MMOX link= s outside IETF space which some might find helpful here:  ht= tps://wiki.secondlife.com/wiki/MMOX .  Under *MMOX Workgroup Chart= er Drafts*  you can find links to the various iterations that we have = made so far, as well as links to my chronicling posts.

Can we please move to a Wiki that doesn't require a Second Life log= in to edit?

Sincerely,

jw



--001636c5a66f8ad7d3046378cb6c-- From infinity@lindenlab.com Sat Feb 21 22:10:53 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4B23A6909 for ; Sat, 21 Feb 2009 22:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHHBD+oDAy2W for ; Sat, 21 Feb 2009 22:10:29 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 155D63A6876 for ; Sat, 21 Feb 2009 22:10:23 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 79FF13DBC45F; Sat, 21 Feb 2009 22:10:39 -0800 (PST) Message-Id: <67A952FD-5259-4979-8777-929B1578D1A5@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49A09825.2040808@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 22:10:37 -0800 References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 06:10:54 -0000 well.. it isn't a canonical page. On Feb 21, 2009, at 4:11 PM, Jon Watte wrote: > Morgaine wrote: >> I'm also maintaining a page of useful MMOX links outside IETF space >> which some might find helpful here: https://wiki.secondlife.com/wiki/MMOX >> . Under *MMOX Workgroup Charter Drafts* you can find links to >> the various iterations that we have made so far, as well as links >> to my chronicling posts. > > Can we please move to a Wiki that doesn't require a Second Life > login to edit? > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Sat Feb 21 23:46:28 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C09E3A68C6 for ; Sat, 21 Feb 2009 23:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZP5q04hxvCm for ; Sat, 21 Feb 2009 23:46:26 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id EE7163A6884 for ; Sat, 21 Feb 2009 23:46:23 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 2A07D3DBC45F; Sat, 21 Feb 2009 23:46:40 -0800 (PST) Message-Id: <3AA2B0DC-DA50-4423-AB1C-F233D57138CA@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: dyerbrookme@juno.com In-Reply-To: <20090221.124544.9172.0@webmail10.vgs.untd.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 23:46:37 -0800 References: <20090221.124544.9172.0@webmail10.vgs.untd.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 07:46:28 -0000 On Feb 21, 2009, at 9:45 AM, dyerbrookme@juno.com wrote: >> again. there are no protocols being considered by this group that >> would REQUIRE the abandonment of the transport of permissions >> metadata. > > Infinity, I never can understand why this statement is always put in > the negative when these discussions come up, "there are no protocols > being considered that would REQUIRE the abandonment. etc.". Is there > a reason why you can't put this in the positive, "We will make sure > that the protocols INCLUDE the transport of permissions metadata". > Because otherwise, it appears that you are saying essentially this, > as you've implied on the LL blog: "We aren't going to deliberately > take out permissions" -- but then implicitly, "But we won't work to > uphold them with a technical solution, either." This seems like an > important distinction, and putting the operation in the positive is > important to create a real situation of real free choice, otherwise, > not working to include the metadata means that suddenly, you can > later say "Oh, well, other people didn't want it so we had to go > along with it but it's not our fault". I word my statements to provide the meaning in intend. when i say "there are no protocols being considered by this group that would REQUIRE the abandonment of the transport of permissions metadata," i say it because there are, in fact, no protocols being considered by this group that would REQUIRE the abandonment of the transport of permissions metadata. What LL blog post are you talking about? Perhaps you have me confused with someone else (enh. it's an easy mistake.) But yes, we won't be working on a protocol that mandates them UNLESS there is unanimous consent that all implementers want to transport permissions metadata via OGP (or whatever we wind up calling it) and there is unanimous consent that the second life model for permissions metadata is appropriate for all implementors. Let me give you an analogy. There is a standard called TLS which is widely used to provide message confidentiality and origin integrity for messages flowing across the internet. Some options in TLS are considerably less secure than others. Specifically... the TLS_RSA_WITH_NULL_MD5 ciphersuite does not even encrypt messages flying across the wire. Think about this... TLS is _the_ standard used to protect your credit card numbers and it's perfectly legitimate within the context of a TLS protected message stream to NOT USE ANY ENCRYPTION WHATSOEVER!!!!!! So why haven't we heard of wide-scale credit card fraud stemming from bad guys stealing credit card numbers off the wire using the TLS_RSA_WITH_NULL_MD5 ciphersuite? Because banks and online merchants all know not to use that option. In short... just because a standard says you can shoot yourself in the foot... honestly... you don't have to. When you have a protocol where not all options make sense for all participants, you generally see people develop policies with names like "interoperability profiles" or "interop policy." These policies detail which options are allowed and which are forbidden, and under what conditions. So why make broken protocols? TLS_RSA_WITH_NULL_MD5 is not evidence of brokenness, it is evidence of flexibility. There are many situations where encryption is not needed but origin integrity is. In some of these situations, the use of encryption is actually counter-productive. If you want to use TLS for encryption, you use the ciphersuites that specify a bulk encryption cipher. If you want to use TLS only for origin integrity, you MAY use a ciphersuite with a NULL cipher. Like all tools, there is an assumption that the user will have some understanding of it's use. And so it is with permissions meta-data. It is highly likely we will produce one or more protocols that do not even mention it. LLSD for instance makes no mention of permissions meta-data, but this does not mean that permissions don't work on the second life grid. (to be sure, there are occasional bugs, but the bugs don't emerge because the LLSD specification failed to define permissions meta-data.) and this is why it is not a failure to define a protocol without permissions meta- data. just because one protocol doesn't define it doesn't mean another one won't. and just because a suite of protocols doesn't define it, doesn't mean it won't be used in some implementations of the protocol. >> this is not a forum for you to complain about the permissions >> system currently deployed on the second life main grid or linden >> lab's policies regarding digital asset creator's intellectual >> property rights. there _are_ other forums where this is appropriate >> and i encourage you to participate in them. > > I'm not complaining about the current permissions system, I'm > celebrating it as a good thing and urging that it be used as the > standard. It's not about privileging one company over another, as I > think the c/m/t regime is a pretty workable and remarkably > successful regime that works far better than other solutions that > companies have come up with (no UGC allowed, all UGC cleared through > a central committee, corporate firewalls on private grids, etc.) so.. you want world of warcraft, penguin cafe, qwaq, there.com, sony home, eve online, osgrid, etc. to all use the second life permissions system instead of the one they made for their user base because you may one day want to use those worlds? good luck. > Sure, there are other forums to discuss these things, where you can > push concerned people out of sight and out of mind, but if you are > going to go about interoperability by refusing to uphold c/m/t at > the outset as a positive project, and only taking a passive stance > that you won't actively strip it out (but you will not work to > uphold it), then it very much becomes *all about* interoperability. > Unlike the corporate DRM's that people complain about so much that > don't have flexibility for individual users, the "DRM" of c/m/t SL- > style is controlled individually by each individual creator, and > that's the reason for its success. again. this is not the forum for this discussion. this is a forum for people who are implementing virtual worlds software. and honestly, your participation here is puzzling to me as you have publicly equated the IETF with a BDSM cult. > I don't think I will need to speak on this subject again, as I think > it's fairly well established now that a) Linden Lab will not work to > uphold the permissions regime of c/m/t outside its grid, but will > enthusiastically hook up to other grids that do not uphold this > regime merely for the sake of interoperability, that the inclusion > of c/m/t will *not* be on the menu of "trustworthyness"; b) other > companies with different IP protection solutions like central > clearance or no UGC at all will also not work to uphold a > permissions regime of c/m/t. huh? where do you get this? but again... this is not a forum managed by Linden Lab and it is not a forum devoted to Linden Lab's policies. if you have a problem with Linden's policies, please use the appropriate channel. IETF != Linden Lab. > Now that we've established those two things, the public then > understands the vast implications of interoperability serving > corporate rather than public interests. All you need to do is be > clear about this, and then the conversation is over. Then the > consumer votes with their feet, as needed. From infinity@lindenlab.com Sat Feb 21 23:49:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD18C28C18A for ; Sat, 21 Feb 2009 23:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEnb9YXhVr5u for ; Sat, 21 Feb 2009 23:49:48 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 72CE13A6930 for ; Sat, 21 Feb 2009 23:49:48 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id D7C683DBC45F; Sat, 21 Feb 2009 23:50:04 -0800 (PST) Message-Id: <4F125591-80D3-4A79-8652-72352D749E53@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Charles Krinke In-Reply-To: <766659.68303.qm@web82602.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2--716234507 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 21 Feb 2009 23:50:03 -0800 References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> <492298.73712.qm@web82607.mail.mud.yahoo.com> <766659.68303.qm@web82602.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 07:49:49 -0000 --Apple-Mail-2--716234507 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit and if we do our job right, you'll be able to teleport between SL to OSGrid and still be wearing that virtual sackcloth. On Feb 21, 2009, at 5:24 PM, Charles Krinke wrote: > My apologies, Morgaine. I was reacting more to the negative > connotations about SecondLife in the first place. Personally, I find > SecondLife to be a fine virtual world with an interesting, sometimes > eclectic group. Plus, I find lots of interesting business, > educational, government and scientific sims there also. > > I flubbed the company connotation, Morgaine and walk around with a > virtual sackcloth and ashes. > > Charles > > From: Morgaine > To: Charles Krinke > Cc: Jon Watte ; mmox@ietf.org > Sent: Saturday, February 21, 2009 5:18:47 PM > Subject: Re: [mmox] MMOX Group Charter > > I should clarify that I have nothing to do with Linden Lab > whatsoever, other than being a resident in Second Life. That wiki > is available to all SL residents, commonly for personal wiki pages > --- it is in effect a public wiki. > > Members of the AWG use this for group communication, as in the case > of the aforementioned MMOX links page that I maintain at https://wiki.secondlife.com/wiki/MMOX > . There is no Linden Lab involvement in this, although of course > they are welcome to improve the page if they wish, as is everyone > else. > > Morgaine. > > > > On Sun, Feb 22, 2009 at 12:25 AM, Charles Krinke > wrote: > I see nothing wrong with Morgaine using her companies wiki for her > companies draft proposals. > > I would say, Jon, that you could use your companies wiki for your > companies draft proposals and it would be entirely fair. > > As I understand the process, there is a revision to the draft > proposal which is on the secondlife wiki now at https://wiki.secondlife.com/wiki/MMOX > and it is the one labeled draft #4. I also understand this "charter > draft" does not mention LLSD or OGP at all and in reading it, it > seems reasonable. > > Charles Krinke > OpenSim Core Developer > http://opensimulator.org > OSGrid Director > http://osgrid.org > > From: Jon Watte > To: Morgaine > Cc: Charles Krinke ; mmox@ietf.org > Sent: Saturday, February 21, 2009 4:11:17 PM > > Subject: Re: [mmox] MMOX Group Charter > > Morgaine wrote: > > I'm also maintaining a page of useful MMOX links outside IETF > space which some might find helpful here: https://wiki.secondlife.com/wiki/MMOX > . Under *MMOX Workgroup Charter Drafts* you can find links to the > various iterations that we have made so far, as well as links to my > chronicling posts. > > Can we please move to a Wiki that doesn't require a Second Life > login to edit? > > Sincerely, > > jw > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-2--716234507 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable and if we do our job right, = you'll be able to teleport between SL to OSGrid and still be wearing = that virtual sackcloth.

On Feb 21, 2009, at 5:24 PM, = Charles Krinke wrote:

My apologies, Morgaine. I was reacting more to the = negative connotations about SecondLife in the first place. Personally, I = find SecondLife to be a fine virtual world with an interesting, = sometimes eclectic group. Plus, I find lots of interesting business, = educational, government and scientific sims there also.

I flubbed = the company connotation, Morgaine and walk around with a virtual = sackcloth and ashes.

Charles

From: Morgaine <morgaine.dinova@googlemail.= com>
To: Charles Krinke <cfk@pacbell.net>
Cc: Jon Watte <jwatte@gmail.com>; mmox@ietf.org
Sent: Saturday, February 21, 2009 = 5:18:47 PM
 Re: [mmox] MMOX Group = Charter

I should clarify that I have nothing to do with = Linden Lab whatsoever, other than being a resident in Second Life.  = That wiki is available to all SL residents, commonly for personal wiki = pages --- it is in effect a public wiki.

Members of the AWG use = this for group communication, as in the case of the aforementioned MMOX links page that I = maintain at https://wiki.secondlife.com= /wiki/MMOX.  There is no Linden Lab involvement in this, = although of course they are welcome to improve the page if they wish, as = is everyone else.

Morgaine.



On Sun, Feb 22, 2009 at 12:25 = AM, Charles Krinke <cfk@pacbell.net> wrote:
I see nothing wrong with Morgaine using her = companies wiki for her companies draft proposals.

I would say, = Jon, that you could use your companies wiki for your companies draft = proposals and it would be entirely fair.

As I understand the = process, there is a revision to the draft proposal which is on the = secondlife wiki now at https://wiki.secondlife.com= /wiki/MMOX and it = is the one labeled draft #4. I also understand this "charter draft" does = not mention LLSD or OGP at all and in reading it, it seems = reasonable.

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

From: Jon Watte <jwatte@gmail.com>
To: Morgaine <morgaine.dinova@googlemail.= com>
Cc: Charles Krinke <cfk@pacbell.net>; mmox@ietf.org
Sent: Saturday, February 21, 2009 = 4:11:17 PM

Subject: Re: [mmox] MMOX Group = Charter

Morgaine wrote:
> = I'm also maintaining a page of useful MMOX links outside IETF space = which some might find helpful here:  https://wiki.secondlife.com= /wiki/MMOX .  = Under *MMOX Workgroup Charter Drafts*  you can find links to the = various iterations that we have made so far, as well as links to my = chronicling posts.

Can we please move to a Wiki that doesn't = require a Second Life login to = edit?

Sincerely,

jw


______________________________= _________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/m= ailman/listinfo/mmox

= --Apple-Mail-2--716234507-- From tommi.s.e.laukkanen@gmail.com Sun Feb 22 00:46:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8FA3A695E for ; Sun, 22 Feb 2009 00:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFLHPCLlidyG for ; Sun, 22 Feb 2009 00:46:57 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 58D8C28C1B1 for ; Sun, 22 Feb 2009 00:46:48 -0800 (PST) Received: by fxm11 with SMTP id 11so880521fxm.13 for ; Sun, 22 Feb 2009 00:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=LpauRB8fItvuozjlZ+8xUE7eSxRSS1u0+Op2dSZiVbU=; b=WUR8f3OUZiCIwh13oJXptYib7xxTntiHxcOUbZdxdQgVJjeywVmfbyMSiXfwf/43jb 0D6TmvZJ5NJc9YvzqflMGZowThZzAIsOO5zrKYanH53bZ30dsrxoAr3l0rCkmZLFhwhX yy3s/GxgKLT5w1px58KEHqfDqxSsdYAh28BGA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FXUdmbo22hmo+G7LvCqXZ+hczp7JX6hqBXchaMdyz4caLq3LoSSAlCYVSw3ISZPMH6 3Ln5t/4SInRLFg9Hvb/RnwaRiDyvX+fhsmrN1Do+W7aTpYV0i1ApVG/D4wdbgFg22462 AIu4CkoxtpHn+Kjp/CLxXnv6Sr1mL4JAiFWzA= MIME-Version: 1.0 Received: by 10.181.155.9 with SMTP id h9mr1027643bko.176.1235292421257; Sun, 22 Feb 2009 00:47:01 -0800 (PST) Date: Sun, 22 Feb 2009 10:47:01 +0200 Message-ID: From: Tommi Laukkanen To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016368e2b18f6785e04637ded18 Subject: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 08:46:58 -0000 --0016368e2b18f6785e04637ded18 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello I have been participating in an open source effort to specify a networked virtual environment protocol. Although Metaverse Exchange Protocol (MXP) is covering only part of the scope here I thought it might be interesting. MXP collects some good ideas to coherent theoretical model (Bubble Cloud) and proposes working engineering solution. One of the MXP over UDP key concepts is to have a minimal set of UDP messages for connectivity, transport and distributed virtual environment scene graph synchronization. All application specific information is transmitted as payload over the UDP messages encoded in MXMP format. Another key concept is to multiplex all the communication through one UDP port to simplify the session handling and network connectivity. Working C# prototype exists which demonstrates the reference implementation. I believe that MXP is a good read currently for people interested in NVE field. You can find the specification wiki from here: http://go-mxp.org best regards, Tommi Laukkanen --0016368e2b18f6785e04637ded18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello
 
I have been participating in an open source effort = to specify a networked virtual environment protocol. Although Metaverse Exc= hange Protocol (MXP) is covering only part of the scope here I thought it m= ight be interesting.
 
MXP collects some good ideas to coherent theoretical model (Bubbl= e Cloud) and proposes working engineering solution. One of the MXP over UDP= key concepts is to have a minimal set of UDP messages for connectivity, tr= ansport and distributed virtual environment scene graph synchronization. Al= l application specific information is transmitted as payload over the UDP m= essages encoded in MXMP format. Another key concept is to multiplex all the= communication through one UDP port to simplify the session handling and ne= twork connectivity.
 
Working C# prototype exists which demonstrates the reference impl= ementation.
 
I believe that MXP is a good read currently for pe= ople interested in NVE field. You can find the specification wiki from here= :
 
http://go-mxp.org
 
best rega= rds,
Tommi Laukkanen
 
--0016368e2b18f6785e04637ded18-- From infinity@lindenlab.com Sun Feb 22 01:02:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0EF3A695E for ; Sun, 22 Feb 2009 01:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rW0L3+Rpyegn for ; Sun, 22 Feb 2009 01:02:51 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id D8F963A6856 for ; Sun, 22 Feb 2009 01:02:51 -0800 (PST) Received: from [192.168.1.11] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id ED9A81414001; Sun, 22 Feb 2009 01:03:07 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Tommi Laukkanen In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-3--711852292 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Feb 2009 01:03:05 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 09:02:52 -0000 --Apple-Mail-3--711852292 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit tommi.. did you read the IPR disclosure rules? On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen wrote: > Hello > > I have been participating in an open source effort to specify a > networked virtual environment protocol. Although Metaverse Exchange > Protocol (MXP) is covering only part of the scope here I thought it > might be interesting. > > MXP collects some good ideas to coherent theoretical model (Bubble > Cloud) and proposes working engineering solution. One of the MXP > over UDP key concepts is to have a minimal set of UDP messages for > connectivity, transport and distributed virtual environment scene > graph synchronization. All application specific information is > transmitted as payload over the UDP messages encoded in MXMP format. > Another key concept is to multiplex all the communication through > one UDP port to simplify the session handling and network > connectivity. > > Working C# prototype exists which demonstrates the reference > implementation. > > I believe that MXP is a good read currently for people interested in > NVE field. You can find the specification wiki from here: > > http://go-mxp.org > > best regards, > Tommi Laukkanen > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-3--711852292 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable tommi.. did you read the IPR = disclosure rules?

On Feb 22, 2009, at 12:47 AM, Tommi = Laukkanen wrote:

Hello
 
I have been participating in an = open source effort to specify a networked virtual environment protocol. = Although Metaverse Exchange Protocol (MXP) is covering only part of the = scope here I thought it might be interesting.
 
MXP collects = some good ideas to coherent theoretical model (Bubble Cloud) and = proposes working engineering solution. One of the MXP over UDP key = concepts is to have a minimal set of UDP messages for connectivity, = transport and distributed virtual environment scene graph = synchronization. All application specific information is transmitted as = payload over the UDP messages encoded in MXMP format. Another key = concept is to multiplex all the communication through one UDP port to = simplify the session handling and network connectivity.
=  
Working C# prototype exists which demonstrates the reference = implementation.
 
I believe that MXP is a good read currently = for people interested in NVE field. You can find the specification wiki = from here:
 
http://go-mxp.org
 
best = regards,
Tommi Laukkanen
 
= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mmox

= --Apple-Mail-3--711852292-- From dyerbrookme@juno.com Sun Feb 22 03:50:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304DB3A6900 for ; Sun, 22 Feb 2009 03:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.58 X-Spam-Level: ** X-Spam-Status: No, score=2.58 tagged_above=-999 required=5 tests=[AWL=-5.178, BAYES_00=-2.599, FM_GOOD_ENF_CREDIT=10.357, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnR-iss2aA9P for ; Sun, 22 Feb 2009 03:50:34 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id ADED03A6AAD for ; Sun, 22 Feb 2009 03:50:33 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail15.vgs.untd.com [10.181.12.155]) by smtpout05.vgs.untd.com with SMTP id AABE4CRAVAK7ES72 for (sender ); Sun, 22 Feb 2009 03:50:43 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkN1SpvUTmL5IVz8miQeg1NDw== Received: (from dyerbrookme@juno.com) by webmail15.vgs.untd.com (jqueuemail) id N9ZK7H7F; Sun, 22 Feb 2009 03:50:04 PST Received: from [10.181.11.39] by webmail15.vgs.untd.com with HTTP: Sun, 22 Feb 2009 11:49:51 GMT X-Originating-IP: [10.181.11.39] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sun, 22 Feb 2009 11:49:51 GMT To: infinity@lindenlab.com X-Mailer: Webmail Version 4.0 Message-Id: <20090222.064951.5324.0@webmail15.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 22:11:3497876789 X-MAIL-INFO: 5bbd8014a1bd05b9f5608129a41d217ddd811189dd39394539155555e9557104e0a000a0f9c070a9104949758dc9b161fd65c9d02499b9202924204400002900c01d95a000d1648d61a0e5b00041b159c08d75b1752da9d424506d1da49499d1 X-UNTD-Peer-Info: 10.181.12.155|webmail15.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 11:50:36 -0000 >I word my statements to provide the meaning in intend. when i say = "there are no protocols being considered by this group that would = REQUIRE the abandonment of the transport of permissions metadata," i = say it because there are, in fact, no protocols being considered by = this group that would REQUIRE the abandonment of the transport of = permissions metadata. What LL blog post are you talking about? Perhaps = you have me confused with someone else (enh. it's an easy mistake.) Transport of permissions metadata is not the same thing as implementing = those permissions on another grid. Do you get credit for having transpor= ted the metadata if the other grid doesn't implement it? Will you not ha= ve as a marker of trustworthyness of a grid its willingness to accept *a= nd implement* metadata for permissions? No, Infinity. I don't have you confused with some other Linden. The blog= post is here: http://blog.secondlife.com/2008/07/08/ibm-linden-lab-interoperability-an= nouncement/ In it, we find *the only thing LL has ever said formally about its inten= tions on permissions*. It says: "Linden Lab will not design a system that lets people openly violate the= permissions of SL goods and take them to other worlds. We recognize tha= t intellectual property is the engine that drives Second Life, and we ar= e completely committed to preserving the qualities that make Second Life= the unique, innovative and dynamic place that it is today." It's corporate-speak. And while it says LL "will not design a system tha= t lets people openly violate the permissions" (hey, thanks!) it does *no= t* say "LL will design a system that prevents people from violating the = permissions". Difference! You're committed? Great! Now could we hear the= engineering plan for preserving that, er, dynamism involved in IP? I think it's a valid question to ask. After all, LL allowed its code to = be reverse-engineered in 2006 despite a rule in the TOS that this was no= t allowed. >But yes, we won't be working on a protocol that mandates them UNLESS t= here is unanimous consent that all implementers want to transport = permissions metadata via OGP (or whatever we wind up calling it) and = there is unanimous consent that the second life model for permissions = metadata is appropriate for all implementors. This strikes me as odd and inflexible. Who says there has to be unanimou= s consent? Isn't the Internet supposed to be a place where you can pick = or chose? Are you saying that if the SL clone OpenSim decides = it will refuse to transport permissions metadata that you'll drop this d= emand, and cease attempts to secure permissions metadata merely because = one of eight or 250 or how many virtual worlds there are vetos it? Why? = Is this another one of those 0/1 or 100 percent or nothing perfection ty= pes of technical demands superimposed on to governance affairs that ough= t not to work in such an inflexible matter? In the world of the "Internet copy machin" and the SL copy bot environme= nt, creators are happy if they get 67 percent protection, not 100 perce= nt, and they don't wish to abandon the 67 percent by declaring 100 perce= nt is impossible. >TLS is _the_ standard used to protect your credit card numbers and it'= s perfectly legitimate within the context of a TLS protected message st= ream to NOT USE ANY ENCRYPTION WHATSOEVER!!!!!! I'd like to hear a second opinion on this. When I see someone emotionall= y all-capping and exclamation-pointing a proposition, I don't see scienc= e, I see religion. >In short... just because a standard says you can shoot yourself in the = foot... honestly... you don't have to. When you have a protocol where no= t all options make sense for all participants, you generally see people = develop policies with names like "interoperability profiles" or "intero= p policy." These policies detail which options are allowed and which are= forbidden, and under what conditions. But if you decide in advance that just because one player among all the = virtual worlds says that they don't feel like transporting metadata for = permissions you won't adopt it as a value, then it sounds like there isn= 't any flexibility whatsoever. Just because one platform dumped IP, the = rest couldn't insist on upholding its implementation even as a choice. >So why make broken protocols? TLS_RSA_WITH_NULL_MD5 is not evidence of brokenness, it is evidence of = flexibility. There are many situations where encryption is not needed = but origin integrity is. In some of these situations, the use of = encryption is actually counter-productive. I wouldn't know. That sounds like a political opinion. I'd like to hear = more about this. I wonder why origin integrity gets to be invoked, but r= eceiving integrity matters not. While it may feel like what is transferr= ed among worlds is just a stream of numbers to you, to users, the code f= eels like real tables, houses, water, sky, etc. And the attitude toward = them is different, and if they are created then the artists might like m= ore care than NULL put over it. >you MAY use a ciphersuite with a NULL cipher. This sounds like something I'd never want a hotel manager to be telling = me. >And so it is with permissions meta-data. It is highly likely we will = produce one or more protocols that do not even mention it. = Yes, that's what I'm concerned about. >and this is why it is not a failure to define a protocol without permis= sions meta-data. just because one protocol doesn't define it doesn't mea= n another one won't. and just because a suite of protocols doesn't defin= e it, doesn't mean it won't be used in some implementations of the proto= col. Sounds like now permissions have become a mere module to tack on as an a= fterthought. When that is how it is conceived, rather than embedded into= the system as a forthright recognition of the importance of economies t= o virtual worlds, then it seems like we are in an eternal sandbox. >so.. you want world of warcraft, penguin cafe, qwaq, there.com, sony = home, eve online, osgrid, etc. to all use the second life permissions = system instead of the one they made for their user base because you = may one day want to use those worlds? good luck. So...I'm supposed to wheel into Azeroth in my Scion and set up a picnic = table and a barbecue and throw some steaks on the grill and then invite = the orcs for a picnic? Perhaps we can cuddle on the blanket? = I'm hardly the only participant in this list who is just not getting thi= s notion of melding versimilitude worlds with fantasy realms. I haven't = heard any user base in WoW agitating for SL avatars to invade their war= game, and the WoW players of SL aren't clamouring to be able to make ar= mour in SL and port it into WoW...oops, they can't do that because there= is *no user generated content* in WoW unless you consider player strate= gies in meta-games like DKP, etc. as UGC (which I do, but its non-invent= oriable content). One can imagine that perhaps some light client or "win= dow" into a quest in WoW could be interesting or useful while someone wa= s simultaneously in SL, kind of camming in, but the intensity of the WoW= quest would preclude wishing to go camming into other worlds and spaces= . You don't need interoperability. You have Windows. You tab the window = down? And go in the other game. Takes a second. Worlds for Windows, by M= icrosoft. So it's false to invoke a) non-UGC games like WoW and b) worlds where pr= otection is achieved, like There.com, through the central committee. Wha= t's operative here are the SL clone worlds or worlds emerging that might= have a similar principle of UGC. So then, I don't get this strange reti= cence to embrace and promote the essential, best core of SL, which is th= e ability of people to easily make, share, and sell content with a very = easy and understood and widely accepted c/m/t permissions system. Again,= I can only repeat the question: why is it good enough for SL but not go= od enough for the Metaverse at large? If it is not good for the Metavers= e, why is it still in SL? Some temporary Leninist NEP, is it, until anot= her revenue source is developed (like domain names or licenses to hook u= p to the asset server?) = >again. this is not the forum for this discussion. this is a forum for = people who are implementing virtual worlds software. and honestly, = your participation here is puzzling to me as you have publicly equated = the IETF with a BDSM cult. Let me tell you two words: Facebook TOS. http://uk.reuters.com/article/technologyNewsMolt/idUKTRE51H6V820090218 People who implement virtual worlds software, like people who implement = social media software, can no longer expect to do this in isolation, and= without accountability to, those who they are making it *for*. The reas= on the call it virtual *world* is because *it's a world with people in i= t*. The reason they call it social media is because it's *social*. So yo= u cannot develop in isolation from the stakeholders in these worlds and = spaces. They are not mere customers you can hold at arm's length while y= ou sell a product as a vendor; interoperability begins at home, between = the platform provider and the users. Your "puzzlement" is typical of what I call the Geeks' Forced Migration = Policy, as it implies: "If you don't like it, leave." Like America, "Lov= e it or leave it". That's silly. Governance of software is not like an o= pensource project where you disagree and make a fork. That culture inhib= its the free consensus that is needed for further development of the 3D = Internet. Yes, I have compared the rigid, arcane, extensive, oppressive rules and = rituals and hive-mind humming of IETF as "like" BDSM culture in this reg= ard: it puts you in the wrong at every turn. You can never understand *e= nough* about it. Journalists who try to report on it end up "scarred". T= hey are always incorrect, and always needing yet more indoctrination. Th= e atmosphere is not one of liberal democratic discourse, where one can a= gree or disagree or criticize or support, it's one in which there is onl= y the double-plus-good promotion of the positive proposal and the "yes" = vote and never a "no" vote. Whatever "necessity" there is about having t= his kind of culture to develop code or technical standards and I'm not s= ure in fact it's a necessity even there) it is not a necessity and is ev= en an obstacle in the development of socialware, which ought to be the t= hird thing after hardware and software in which the customer feedback, t= he laymen's concerns, are constantly incorporated as a matter of course,= and not just tacked on at the end of the process. = >huh? where do you get this? = I read what you wrote. And my question stands: why uphold c/m/t in your = own world if you do not wish to support it elsewhere? >but again... this is not a forum managed by Linden Lab and it is not a = forum devoted to Linden Lab's policies. if you have a problem with Linde= n's policies, please use the appropriate channel. IETF !=3D Linden Lab. If Linden Lab's policies are universalized by becoming a standard, they = are the business of the Metaverse at large and not merely a customer ser= vice problem for your own grid. Sorry, but I reject the Linden "channell= ing" approach to dismiss issues on a public forum of this nature. ____________________________________________________________ Get important data to help make informed decisions. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTHIsWCzPr4ZKRD95AACAfP= AcApfbx6uav0fIglcT0buMBAZvJIa68/ From gareth@litesim.com Sun Feb 22 04:30:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ADCA28C0EB for ; Sun, 22 Feb 2009 04:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eN6oG6bTPp8V for ; Sun, 22 Feb 2009 04:30:13 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id BA2813A687A for ; Sun, 22 Feb 2009 04:30:13 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1452298rvb.49 for ; Sun, 22 Feb 2009 04:30:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.122.20 with SMTP id z20mr1482255rvm.171.1235305829754; Sun, 22 Feb 2009 04:30:29 -0800 (PST) In-Reply-To: References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <61dbdd7d0902211100x7451ee8dy536051dd32ccbe7c@mail.gmail.com> Date: Sun, 22 Feb 2009 12:30:29 +0000 Message-ID: <61dbdd7d0902220430y544a7a71r4557961dae2421cd@mail.gmail.com> From: Gareth Nelson To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 12:30:14 -0000 For some odd reason I thought the wiki was more authorative than the mailing list ;) On Sat, Feb 21, 2009 at 11:05 PM, Morgaine wrote: > > > On Sat, Feb 21, 2009 at 7:00 PM, Gareth Nelson wrote: >> >> Looking again, this is very very OGP-biased, is this not something we >> ought to correct? > > It's already been corrected --- I wrote this post for you this morning, you > may recall: > http://www.ietf.org/mail-archive/web/mmox/current/msg00349.html :-) > > > Morgaine. > From mccahill@duke.edu Sun Feb 22 05:14:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F72D3A67F6 for ; Sun, 22 Feb 2009 05:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIORWvLUNTy9 for ; Sun, 22 Feb 2009 05:14:36 -0800 (PST) Received: from smtp.duke.edu (smtp-04.oit.duke.edu [152.3.174.85]) by core3.amsl.com (Postfix) with ESMTP id 8194E3A6405 for ; Sun, 22 Feb 2009 05:14:36 -0800 (PST) Received: from smtp.duke.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A8BD3359654; Sun, 22 Feb 2009 08:14:52 -0500 (EST) Received: from [192.168.1.3] (cpe-066-057-004-163.nc.res.rr.com [66.57.4.163]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.duke.edu (Postfix) with ESMTP id 50ED8359652; Sun, 22 Feb 2009 08:14:52 -0500 (EST) Message-Id: From: "Mark P. McCahill" To: Jon Watte In-Reply-To: <49A04DEB.4060301@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Feb 2009 08:14:50 -0500 References: <49A04DEB.4060301@gmail.com> X-Mailer: Apple Mail (2.930.3) X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2009.2.22.130428 Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 13:14:38 -0000 Is it possible that two working groups could come out of this BOF process? The mailing list seems to be split - some are interested in the original wire-level protocol proposal, and another group is talking about higher-level interoperability issues such as identity and other issues including those Jon listed below. On Feb 21, 2009, at 1:54 PM, Jon Watte wrote: > Dan Olivares wrote: >> At this point in time, are there any more proposals for the working >> group draft? Should we move on to establishing rough consensus and >> BOF? >> > > Here is a proposal for subjects for standardization and a general > understanding of what the "common ground" would be. I believe that > without standardizing at least all of these things, broad and useful > interoperability cannot be achieved: > > - User identity is provided by an identity provider, which may be > the "home" world of the user, or some other provider. Users should > not need identity tied to the specific world they want to visit. > Some worlds may choose to not accept certain specific credentials, > just like certain real-world stores may not accept Candian dollars > for payment. The market will work out a few major credential systems > in the end (such as OpenID, perhaps). As long as each system is > accessed uniformly, the specifics of the back end don't matter. > > - Geometry is based on regular meshes, possibly with LOD switches > and lower-resolution physics meshes/proxies/hulls. I understand that > this may be a sticking point for the SL-derived worlds (or do they > actually support arbitrary meshes as an option now? I haven't kept > up.) > > - Texturing is based on a regular Phong model with various defined > texture maps (because HLSL vs GLSL vs some-other-SL are each of them > not suitable on their own). Turns out, once you have the possibility > of gloss maps, normal maps, emission maps, opacity maps, diffuse > maps and ambient maps, you have 90% of the "look" of any one > technology, which is about as good as you can hope for through > interoperability. > > - Telemetry (entity movement) needs to be sent on a position/ > orientation/velocity basis, with dead reckoning. Delta compression > and lower update rates can be used to keep bandwidth usage in check. > This is a big difference for OLIVE, because we are input- > synchronous, similar to City of Heroes or Age of Empires. However, > again, this is the common denominator and experience speaking. > > - Animating objects need to use a common, widespread interchange > format, using named animation clips and skeletal animation. Morph > deformation is likely too big a payload to make sense, at least in > the early stages. COLLADA is a good format for this, but there are > other possibilities (FBX, X3D and X come to mind). I think that > making at least one format required is a good idea, because that > ensures a minimum level of interoperability is always present. > > - Simulation and script execution for a given object needs to be > done on the "home" system for that object, because objects may be > constructed assuming wildly disparate execution environments (X3D > with JavaScript; Prims with SL Script, C++ with XML, Java with JSR > 184, etc). > > - Objects need to be marked up with simple, well defined possible > interactions, so that a user interface can be generated on each > client based on those interactions. Interactions are typically "set > this property to this value" or "execute this command." Such > interactions need to be forwarded to the server that runs the object > in question. Similarly, specific interactions ("emote animation," > "collision," "damage," "two-party animation," "flight" etc) need to > be defined. > > - Non-time-critical requests should go over HTTP and/or HTTPS, using > XML-RPC or a similarly well understood protocol. > > - Time-critical and high-bandwidth data (such as entity telemetry > and user inputs) should be sent using explicit (separate) schema, > and binary representation, for the same reason that we don't send > streaming video as XML, or mark each pixel with a color space > identifier. > > Sincerely, > > Jon Watte > Forterra Systems > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From gareth@litesim.com Sun Feb 22 05:45:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F403A69FD for ; Sun, 22 Feb 2009 05:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w+jpp3BRVQf for ; Sun, 22 Feb 2009 05:45:51 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 92ABC3A6953 for ; Sun, 22 Feb 2009 05:45:51 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1465254rvb.49 for ; Sun, 22 Feb 2009 05:46:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.133.10 with SMTP id g10mr1515206rvd.113.1235310367867; Sun, 22 Feb 2009 05:46:07 -0800 (PST) In-Reply-To: References: <61dbdd7d0902210322g3ac1e9d3na94284a3ca90504f@mail.gmail.com> Date: Sun, 22 Feb 2009 13:46:07 +0000 Message-ID: <61dbdd7d0902220546gc76dc21r467cb9c48f8eef39@mail.gmail.com> From: Gareth Nelson To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 13:45:52 -0000 My point is that the current SL protocol has it's own QoS handled by application endpoints, not network routers. Do cisco sell traffic shaping devices that handle the SL protocol? I think QoS in server<>server links is something that can be standardised, but client<>server is too unique to the individual protocol type. In other words, a router can't tag a traffic stream as being "virtual world stuff", it has to be "SL stuff" or "croquet stuff" etc. On Sat, Feb 21, 2009 at 7:03 PM, Meadhbh Hamrick (Infinity) wrote: > yup. this kind of QoS is definitely useful. in the current implementation of > second life, there's quite a bit simulator to simulator communication. if > all the simulators are inside the same data center, communicating with each > other over a fiber ring, we have plenty of bandwidth, so we don't see a lot > of QoS related problems. however... when two sims are in different data > centers and their communications have to go over the public internet (rather > than some private network with guaranteed bandwidth and latency > characteristics) sim <-> sim QoS becomes VERY important. > > of course we're not saying we should standardize the exact same protocol > we're using today at linden, but it's reasonable to assume that we would > re-use some of the same design patterns, or at least support the same design > pattern. ergo, it's probably in our best interest to think about QoS between > all systems... > > -cheers > -meadhbh > > On Feb 21, 2009, at 3:22 AM, Gareth Nelson wrote: > >> Thanks for the overview :) >> My only comment with a quick glance is regarding this: >> >> "c) allow network layers to recognize VW traffic and make routing >> decisions based on its characteristics." >> >> Is client<>server traffic for individual worlds not primarily >> something for individual worlds rather than an interop issue? >> For example, you might be on world A, and talking to world B via world >> A's servers, but your client<>server traffic is still running A's >> protocol. At the server<>server end is this kind of QoS actually >> useful? >> >> On Sat, Feb 21, 2009 at 11:10 AM, Morgaine >> wrote: >>> >>> >>> On Sat, Feb 21, 2009 at 9:14 AM, Gareth Nelson >>> wrote: >>> >>>> So, why don't we get on with voting on a charter? >>>> As for discussing implementation details now - nothing wrong with >>>> doing so if it's in the same basic area as the formal working group >>>> would be >>> >>> >>> That work has already started, Gareth, although the discussion might have >>> preceded your joining the list. :-) >>> >>> To help your navigation, I'll unpick the messy email threading for you: >>> >>> 1) John Hurliman first pointed out the inappropriateness of references to >>> OGP in the charter of a workgroup whose mission it is to examine what is >>> appropriate in the first place: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00012.html >>> >>> 2) I agreed, and affirmed that we are definitely not here to rubberstamp >>> Linden proposals, and hence that we should start immediately on improving >>> the charter: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00013.html >>> >>> 3) Infinity responded extremely positively and noted that the initial >>> draft >>> was highly LL/IBM-specific since they were the two authors of the draft, >>> but >>> invited John and myself (and everyone else on the list of course) to >>> submit >>> concrete proposals for improvements: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00015.html >>> >>> 4) I responded with an offer to help directly: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00016.html >>> >>> 5) Based off the LL/IBM original (#1), John provided the first improved >>> draft charter (#2): >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00032.html >>> >>> 6) Based off John's draft #2, I made improvements for clarity and removed >>> an >>> ambiguity, to give us draft #3: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00036.html >>> >>> 7) Infinity and I then exchanged several emails in the list to narrow >>> down >>> whether the word "proprietary" was substantive, or just a residue from >>> the >>> initial version. The clear conclusion was that it was highly >>> substantive, >>> and therefore I further modified my version with a clear statement that >>> we >>> are in the business of defining open, non-proprietary standards, which >>> became draft #4: >>> http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html >>> >>> There have been no specific updates since then. >>> >>> Needless to say, if you or anyone else requires further changes, then >>> pick >>> up the baton and run with it! I look forward to draft #5. :-) >>> >>> I am sure the text will undergo numerous further iterations before we >>> finally agree on an effective charter that can be passed at the BoF. The >>> MMOX list is currently examining other issues, but it is certain to >>> return >>> to the charter as the BoF draws nearer. >>> >>> Morgaine. >>> >>> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > From cs@comlounge.net Sun Feb 22 07:29:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6AD23A687A for ; Sun, 22 Feb 2009 07:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz3uNhXfraaZ for ; Sun, 22 Feb 2009 07:29:06 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 0CCC63A6783 for ; Sun, 22 Feb 2009 07:29:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 91D596F4010; Sun, 22 Feb 2009 16:29:21 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vwia3P3w7EyJ; Sun, 22 Feb 2009 16:29:20 +0100 (CET) Received: from Labertasche.local (unknown [212.117.76.202]) by post.comlounge.net (Postfix) with ESMTP id F2BBC1CE0420; Sun, 22 Feb 2009 16:29:19 +0100 (CET) Message-ID: <49A16F4D.8070007@comlounge.net> Date: Sun, 22 Feb 2009 16:29:17 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Mark P. McCahill" References: <49A04DEB.4060301@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 15:29:07 -0000 Hi! Mark P. McCahill wrote: > Is it possible that two working groups could come out of this BOF process? > > The mailing list seems to be split - some are interested in the original > wire-level protocol > proposal, and another group is talking about higher-level > interoperability issues such as > identity and other issues including those Jon listed below. I was wondering actually if those identity related matters are actually not broader than just virtual worlds and if it then fits into this working group (lets say if some web site wants to use it it might feel strange to refer to some VW specific standard). And "identity related matters" can mean the following: Authentication How to use my identity from somewhere else on a new site (here things like OpenID, YADIS, InformationCards etc. play in. There also is already a big community around this topic, see [1]. Authorization How to allow consumer services access to protected resources on service providers on behalf of the user and without knowing a user's password (or whatever is used to login). The question here is how we can find a tradeoff between control and good user experience (e.g. not asking the user for every service if it's ok to access it). Related work is done with OAuth[2] which seems to gain traction but still has various shortcomings which are discussed at the moment. Service Discovery A user might have various services associated, such as profile information, the social graph (contacts), photos, 3d assets in various places, groups, preferred IM servers, activity streams and so on. If the user signs up somewhere it would be good if it can be avoided that all URLs to those services needs to be entered. Instead a service catalogue might be useful which holds all of the users services sorted by type. The user could then choose which services to allow access to. The same is useful for service providers. Like some OpenSim or other virtual world region might have different sub-components the client needs to talk to. These can be defined the same way (for OpenSim that's GridInfo right now IIRC). There is a spec called XRDS-Simple[3] which is based on XRDS which again is used for OpenID discovery (YADIS) to find out what identity services are actually available at the URL the user enters. While XRDS-Simple is now deprecated[4] a new spec (at OASIS) is being written called XRD which has is supposed to be a better version of XRDS-Simple. At [5] are some more thoughts on discovery. Various formats/APIs for moving data around Having authentication, authorization and service discovery one can then go ahead and actually exchange data. There are of course many types of data one can think about. The most basic thing is usually profile information though, followed by contacts. This at least is what I have to enter/find over and over again with each signup to a new service. In virtual worlds finding your friends might even be more difficulty because they might not have the same names on every platform (e.g. because you cannot freely choose your name like in SL). There are already many solutions to this problem like FOAF/RDF, Microformats or OpenSocial's REST API. I personally prefer the latter because REST means that you also can write data back (although right now no service to my knowledge supports that). Microformats is probably out due to the requirement of HTML which you might not always have in VWs. Other possible services might be group management, IM, inventory management (it would be great to have a standardized REST interface for that) and so on. The question is though if all this should be in the scope of such an identity based WG. Probably not. Synchronisation It's nice to be able to copy data around to whatever service you want to but if it cannot be synced it might be worthless after a while. So some means of synchronisation could be defined, e.g. based on XMPP/ATOM etc. This might also play into the field of activity streams, another hot topic on the web right now. So these are my basic thoughts about this. As a result it would be nice to have - one definitive URL (or whatever format) for your identity starting point (per identity) - a way for other services to discover which types of data you provide on the net and a mechanism to get authorization to subscribe to it. - a way to push back data, e.g. changed email addresses etc. to one of these services - users in control of their data. The latter might also be a problem of TOS/EULAs, as most providers right now need or want quite broad licenses to use your data in whatever way they want to. There are some discussions right now around the Facebook TOS change and how people can be made aware of the restrictions they face when joining a site. These are more social/legal problems though. If some sort of Creative Commons like set of licenses comes out of that it might get technical of course to attach them to data and move them around. Groups active here are at DataPortability[6| and Project Liberty[7]. The good thing in general for a separate group would be to be able to embrace more parties having the same problems like many social networks and Open Stack supporters. That's esp. interesting as there already is a lot of talk going on. My €.02 -- Christian [1] http://identitycommons.org/ [2] http://oauth.net [3] http://xrds-simple.net [4] http://www.hueniverse.com/hueniverse/2009/01/discovery-on-my-mind-new-specification-published.html [5] http://www.hueniverse.com/hueniverse/2009/02/redefining-discovery.html [6] http://wiki.dataportability.org/pages/viewpage.action?pageId=4490392 [7] http://wiki.projectliberty.org/index.php/VolunteeredPersonalInformationSIG > > > On Feb 21, 2009, at 1:54 PM, Jon Watte wrote: > >> Dan Olivares wrote: >>> At this point in time, are there any more proposals for the working >>> group draft? Should we move on to establishing rough consensus and >>> BOF? >>> >> >> Here is a proposal for subjects for standardization and a general >> understanding of what the "common ground" would be. I believe that >> without standardizing at least all of these things, broad and useful >> interoperability cannot be achieved: >> >> - User identity is provided by an identity provider, which may be the >> "home" world of the user, or some other provider. Users should not >> need identity tied to the specific world they want to visit. Some >> worlds may choose to not accept certain specific credentials, just >> like certain real-world stores may not accept Candian dollars for >> payment. The market will work out a few major credential systems in >> the end (such as OpenID, perhaps). As long as each system is accessed >> uniformly, the specifics of the back end don't matter. >> >> - Geometry is based on regular meshes, possibly with LOD switches and >> lower-resolution physics meshes/proxies/hulls. I understand that this >> may be a sticking point for the SL-derived worlds (or do they actually >> support arbitrary meshes as an option now? I haven't kept up.) >> >> - Texturing is based on a regular Phong model with various defined >> texture maps (because HLSL vs GLSL vs some-other-SL are each of them >> not suitable on their own). Turns out, once you have the possibility >> of gloss maps, normal maps, emission maps, opacity maps, diffuse maps >> and ambient maps, you have 90% of the "look" of any one technology, >> which is about as good as you can hope for through interoperability. >> >> - Telemetry (entity movement) needs to be sent on a >> position/orientation/velocity basis, with dead reckoning. Delta >> compression and lower update rates can be used to keep bandwidth usage >> in check. This is a big difference for OLIVE, because we are >> input-synchronous, similar to City of Heroes or Age of Empires. >> However, again, this is the common denominator and experience speaking. >> >> - Animating objects need to use a common, widespread interchange >> format, using named animation clips and skeletal animation. Morph >> deformation is likely too big a payload to make sense, at least in the >> early stages. COLLADA is a good format for this, but there are other >> possibilities (FBX, X3D and X come to mind). I think that making at >> least one format required is a good idea, because that ensures a >> minimum level of interoperability is always present. >> >> - Simulation and script execution for a given object needs to be done >> on the "home" system for that object, because objects may be >> constructed assuming wildly disparate execution environments (X3D with >> JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, etc). >> >> - Objects need to be marked up with simple, well defined possible >> interactions, so that a user interface can be generated on each client >> based on those interactions. Interactions are typically "set this >> property to this value" or "execute this command." Such interactions >> need to be forwarded to the server that runs the object in question. >> Similarly, specific interactions ("emote animation," "collision," >> "damage," "two-party animation," "flight" etc) need to be defined. >> >> - Non-time-critical requests should go over HTTP and/or HTTPS, using >> XML-RPC or a similarly well understood protocol. >> >> - Time-critical and high-bandwidth data (such as entity telemetry and >> user inputs) should be sent using explicit (separate) schema, and >> binary representation, for the same reason that we don't send >> streaming video as XML, or mark each pixel with a color space identifier. >> >> Sincerely, >> >> Jon Watte >> Forterra Systems >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox -- 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 cs@comlounge.net 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 cfk@pacbell.net Sun Feb 22 07:33:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630913A69FC for ; Sun, 22 Feb 2009 07:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcOFcKK8rkCD for ; Sun, 22 Feb 2009 07:33:49 -0800 (PST) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id 999183A6783 for ; Sun, 22 Feb 2009 07:33:49 -0800 (PST) Received: (qmail 25902 invoked by uid 60001); 22 Feb 2009 15:34:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=oWzwXEyIcpJMWsxYeF+s22CVpZi76E6zR6vBcNq0hgat06PKVrNKtVdgRZmloa0Fycio9PNnlMWuCMU10izKXEFI4FKvNIJyNnxZsIKP/+UaYEQITwAJw4pGX1QjYVexhHOImJG0IyQOhdF8/J2YNRP5BtrgUr2rVup0VY4+U/M=; X-YMail-OSG: KjnDEFcVM1lR4baFr9GtDb6kqsCaIuM.2kDNXG06ppJtnUCZpWvW14f4KaMeCv6lbW1JAUmVB0oNGRK3ZRxyN1ChK9xhUp2PWUD4gXD6mDPNKN1bqalJHUZct9ilvWESTiqQ_6K0_QP.YwJVK1deVnLD4pXys1NA7kQYZ7qTW3g_m5f1lDG4_q.MWCHUuQ60tOk22V4gsRbv01TJUigWF1V8WV8- Received: from [67.120.11.69] by web82605.mail.mud.yahoo.com via HTTP; Sun, 22 Feb 2009 07:34:05 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <49A04DEB.4060301@gmail.com> Date: Sun, 22 Feb 2009 07:34:05 -0800 (PST) From: Charles Krinke To: "Mark P. McCahill" , Jon Watte MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-121872381-1235316845=:23835" Message-ID: <697430.23835.qm@web82605.mail.mud.yahoo.com> Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 15:33:51 -0000 --0-121872381-1235316845=:23835 Content-Type: text/plain; charset=us-ascii Well, what I "hope" we are really talking about is the beginnings of the 3D internet where we can expect to evolve from "flat web pages" to 3D interactive web communication. This whole thing feels like the discussions around web browsing about 25 years ago. If we do our job right, then we will eventually expect that any 3D client can expect to connect to any 3D server, negotiate a pre-described set of capabilities and services and act in an analagous fashion that a web browser does now. In order to get there, imagine that there were no HTTP or HTML, but rather a few groups that had defined similar but incompatible web page formats so that only their browser would read their web page. In order to get to a common experience, it would be necessary for these groups to agree to a common standard so that the browsers could "interop" with each other. That is the stage we are at today with the notion of "interop" and 3D interactive web virtual worlds. So, be it wire protocol, or higher level interoperability issues, I think we all need to work to get past our current biases and find a way to define 3D interoperability so we can get past the "flat web" and evolve into the next part of the internet evolution. Charles Krinke OpenSim Core Developer http://opensimulator.org OSGrid Director http://osgrid.org ________________________________ From: Mark P. McCahill To: Jon Watte Cc: "mmox@ietf.org" Sent: Sunday, February 22, 2009 5:14:50 AM Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart Is it possible that two working groups could come out of this BOF process? The mailing list seems to be split - some are interested in the original wire-level protocol proposal, and another group is talking about higher-level interoperability issues such as identity and other issues including those Jon listed below. On Feb 21, 2009, at 1:54 PM, Jon Watte wrote: > Dan Olivares wrote: >> At this point in time, are there any more proposals for the working >> group draft? Should we move on to establishing rough consensus and >> BOF? >> > > Here is a proposal for subjects for standardization and a general understanding of what the "common ground" would be. I believe that without standardizing at least all of these things, broad and useful interoperability cannot be achieved: > > - User identity is provided by an identity provider, which may be the "home" world of the user, or some other provider. Users should not need identity tied to the specific world they want to visit. Some worlds may choose to not accept certain specific credentials, just like certain real-world stores may not accept Candian dollars for payment. The market will work out a few major credential systems in the end (such as OpenID, perhaps). As long as each system is accessed uniformly, the specifics of the back end don't matter. > > - Geometry is based on regular meshes, possibly with LOD switches and lower-resolution physics meshes/proxies/hulls. I understand that this may be a sticking point for the SL-derived worlds (or do they actually support arbitrary meshes as an option now? I haven't kept up.) > > - Texturing is based on a regular Phong model with various defined texture maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on their own). Turns out, once you have the possibility of gloss maps, normal maps, emission maps, opacity maps, diffuse maps and ambient maps, you have 90% of the "look" of any one technology, which is about as good as you can hope for through interoperability. > > - Telemetry (entity movement) needs to be sent on a position/orientation/velocity basis, with dead reckoning. Delta compression and lower update rates can be used to keep bandwidth usage in check. This is a big difference for OLIVE, because we are input-synchronous, similar to City of Heroes or Age of Empires. However, again, this is the common denominator and experience speaking. > > - Animating objects need to use a common, widespread interchange format, using named animation clips and skeletal animation. Morph deformation is likely too big a payload to make sense, at least in the early stages. COLLADA is a good format for this, but there are other possibilities (FBX, X3D and X come to mind). I think that making at least one format required is a good idea, because that ensures a minimum level of interoperability is always present. > > - Simulation and script execution for a given object needs to be done on the "home" system for that object, because objects may be constructed assuming wildly disparate execution environments (X3D with JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, etc). > > - Objects need to be marked up with simple, well defined possible interactions, so that a user interface can be generated on each client based on those interactions. Interactions are typically "set this property to this value" or "execute this command." Such interactions need to be forwarded to the server that runs the object in question. Similarly, specific interactions ("emote animation," "collision," "damage," "two-party animation," "flight" etc) need to be defined. > > - Non-time-critical requests should go over HTTP and/or HTTPS, using XML-RPC or a similarly well understood protocol. > > - Time-critical and high-bandwidth data (such as entity telemetry and user inputs) should be sent using explicit (separate) schema, and binary representation, for the same reason that we don't send streaming video as XML, or mark each pixel with a color space identifier. > > Sincerely, > > Jon Watte > Forterra Systems > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-121872381-1235316845=:23835 Content-Type: text/html; charset=us-ascii
Well, what I "hope" we are really talking about is the beginnings of the 3D internet where we can expect to evolve from "flat web pages" to 3D interactive web communication.

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

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

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

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

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

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

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

From: Mark P. McCahill <mccahill@duke.edu>
To: Jon Watte <jwatte@gmail.com>
Cc: "mmox@ietf.org" <mmox@ietf.org>
Sent: Sunday, February 22, 2009 5:14:50 AM
Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart

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

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


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

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

_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--0-121872381-1235316845=:23835-- From cs@comlounge.net Sun Feb 22 07:59:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56503A6AC4 for ; Sun, 22 Feb 2009 07:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvcV5MwMURsx for ; Sun, 22 Feb 2009 07:59:53 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 1C5CF3A6912 for ; Sun, 22 Feb 2009 07:59:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 5940F1CE0319; Sun, 22 Feb 2009 17:00:09 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMzcYy7HHhDq; Sun, 22 Feb 2009 17:00:08 +0100 (CET) Received: from Labertasche.local (unknown [212.117.76.202]) by post.comlounge.net (Postfix) with ESMTP id 683971CE0316; Sun, 22 Feb 2009 17:00:07 +0100 (CET) Message-ID: <49A17685.1010703@comlounge.net> Date: Sun, 22 Feb 2009 17:00:05 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Charles Krinke References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> In-Reply-To: <697430.23835.qm@web82605.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 15:59:54 -0000 Charles Krinke wrote: > Well, what I "hope" we are really talking about is the beginnings of the > 3D internet where we can expect to evolve from "flat web pages" to 3D > interactive web communication. But what I wouldn't want here is to exclude the web. For my identity I would like to carry it over to any service be it 1D, 2D, 3D or 4D. Also I think we should prevent the case where we end up with 2 incompatible ways of a federated identity, one for the web and one for VWs. > > This whole thing feels like the discussions around web browsing about 25 > years ago. > > If we do our job right, then we will eventually expect that any 3D > client can expect to connect to any 3D server, negotiate a pre-described > set of capabilities and services and act in an analagous fashion that a > web browser does now. And I would even put the web browser into the equation. I don't think the web is dead, it's far away from being that. For 3D related things of course it would be more useful to have only one set of protocols defined like HTTP/HTML as you say. Right now (and I guess this is Jon's point) it might be difficulty to ask everybody to throw away their technologies and start from scratch with that new protocol. Also for email it took some while before most of those gateways were not needed anymore because it's all SMTP now. -- Christian > In order to get there, imagine that there were no HTTP or HTML, but > rather a few groups that had defined similar but incompatible web page > formats so that only their browser would read their web page. > > In order to get to a common experience, it would be necessary for these > groups to agree to a common standard so that the browsers could > "interop" with each other. > > That is the stage we are at today with the notion of "interop" and 3D > interactive web virtual worlds. > > So, be it wire protocol, or higher level interoperability issues, I > think we all need to work to get past our current biases and find a way > to define 3D interoperability so we can get past the "flat web" and > evolve into the next part of the internet evolution. > > Charles Krinke > OpenSim Core Developer > http://opensimulator.org > OSGrid Director > http://osgrid.org > > ------------------------------------------------------------------------ > *From:* Mark P. McCahill > *To:* Jon Watte > *Cc:* "mmox@ietf.org" > *Sent:* Sunday, February 22, 2009 5:14:50 AM > *Subject:* Re: [mmox] I hate to be a kill joy here and, put the horse > before the cart > > Is it possible that two working groups could come out of this BOF process? > > The mailing list seems to be split - some are interested in the original > wire-level protocol > proposal, and another group is talking about higher-level > interoperability issues such as > identity and other issues including those Jon listed below. > > > On Feb 21, 2009, at 1:54 PM, Jon Watte wrote: > >> Dan Olivares wrote: >>> At this point in time, are there any more proposals for the working >>> group draft? Should we move on to establishing rough consensus and >>> BOF? >>> >> >> Here is a proposal for subjects for standardization and a general > understanding of what the "common ground" would be. I believe that > without standardizing at least all of these things, broad and useful > interoperability cannot be achieved: >> >> - User identity is provided by an identity provider, which may be the > "home" world of the user, or some other provider. Users should not need > identity tied to the specific world they want to visit. Some worlds may > choose to not accept certain specific credentials, just like certain > real-world stores may not accept Candian dollars for payment. The market > will work out a few major credential systems in the end (such as OpenID, > perhaps). As long as each system is accessed uniformly, the specifics of > the back end don't matter. >> >> - Geometry is based on regular meshes, possibly with LOD switches and > lower-resolution physics meshes/proxies/hulls. I understand that this > may be a sticking point for the SL-derived worlds (or do they actually > support arbitrary meshes as an option now? I haven't kept up.) >> >> - Texturing is based on a regular Phong model with various defined > texture maps (because HLSL vs GLSL vs some-other-SL are each of them not > suitable on their own). Turns out, once you have the possibility of > gloss maps, normal maps, emission maps, opacity maps, diffuse maps and > ambient maps, you have 90% of the "look" of any one technology, which is > about as good as you can hope for through interoperability. >> >> - Telemetry (entity movement) needs to be sent on a > position/orientation/velocity basis, with dead reckoning. Delta > compression and lower update rates can be used to keep bandwidth usage > in check. This is a big difference for OLIVE, because we are > input-synchronous, similar to City of Heroes or Age of Empires. However, > again, this is the common denominator and experience speaking. >> >> - Animating objects need to use a common, widespread interchange > format, using named animation clips and skeletal animation. Morph > deformation is likely too big a payload to make sense, at least in the > early stages. COLLADA is a good format for this, but there are other > possibilities (FBX, X3D and X come to mind). I think that making at > least one format required is a good idea, because that ensures a minimum > level of interoperability is always present. >> >> - Simulation and script execution for a given object needs to be done > on the "home" system for that object, because objects may be constructed > assuming wildly disparate execution environments (X3D with JavaScript; > Prims with SL Script, C++ with XML, Java with JSR 184, etc). >> >> - Objects need to be marked up with simple, well defined possible > interactions, so that a user interface can be generated on each client > based on those interactions. Interactions are typically "set this > property to this value" or "execute this command." Such interactions > need to be forwarded to the server that runs the object in question. > Similarly, specific interactions ("emote animation," "collision," > "damage," "two-party animation," "flight" etc) need to be defined. >> >> - Non-time-critical requests should go over HTTP and/or HTTPS, using > XML-RPC or a similarly well understood protocol. >> >> - Time-critical and high-bandwidth data (such as entity telemetry and > user inputs) should be sent using explicit (separate) schema, and binary > representation, for the same reason that we don't send streaming video > as XML, or mark each pixel with a color space identifier. >> >> Sincerely, >> >> Jon Watte >> Forterra Systems >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox -- 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 cs@comlounge.net 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 cfk@pacbell.net Sun Feb 22 08:19:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E66A43A6783 for ; Sun, 22 Feb 2009 08:19:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lue3dhqM28px for ; Sun, 22 Feb 2009 08:19:34 -0800 (PST) Received: from web82607.mail.mud.yahoo.com (web82607.mail.mud.yahoo.com [68.142.201.124]) by core3.amsl.com (Postfix) with SMTP id 911993A6912 for ; Sun, 22 Feb 2009 08:19:34 -0800 (PST) Received: (qmail 15319 invoked by uid 60001); 22 Feb 2009 16:19:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=zjub0KT1ojDRegMSQFh5I+fHMUmry6SwcW+QDBttr5LfHHNxAfU4OgBz3KOjmlOkkUe/rNr/4vU4y48y4Pmdso/EL6ahEAPEIx952fUxklVU5VJTilo+ABXxu31KQAm8ezh3Qup1rzf5c9HQLkBXRaDVuiHEgNLE6EBdsLWJlCk=; X-YMail-OSG: 1fRm5aUVM1lzz9U6TLlYENeCn7wxBdJX8AApyU.mJnOnfZ3oLTOvHsdz9f5sFRyOZqT0tARsKxPUJLhkviR0dbqna2g0qCko99FuuqHEa7r4r4xfuMyyCK2B5tfQsbSvkV6QQYoQ0ZCEKTS5GfWgJxtbNo9yo_zDZco.WP_twePbZGL_IBy9bplJHrSSrO4Sc8_WLN9Nk.Ft5g-- Received: from [67.120.11.69] by web82607.mail.mud.yahoo.com via HTTP; Sun, 22 Feb 2009 08:19:50 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: Date: Sun, 22 Feb 2009 08:19:50 -0800 (PST) From: Charles Krinke To: "Meadhbh Hamrick \(Infinity\)" , Tommi Laukkanen MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1546221477-1235319590=:12996" Message-ID: <562887.12996.qm@web82607.mail.mud.yahoo.com> Cc: mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 16:19:36 -0000 --0-1546221477-1235319590=:12996 Content-Type: text/plain; charset=us-ascii Dear Meadhbh: Can you help Tommi (and myself) understand what you mean? Was it inappropriate to make the MXP post to this list? I do not understand what the context is. Charles ________________________________ From: Meadhbh Hamrick (Infinity) To: Tommi Laukkanen Cc: mmox@ietf.org Sent: Sunday, February 22, 2009 1:03:05 AM Subject: Re: [mmox] Other NVE protocol specification efforts tommi.. did you read the IPR disclosure rules? On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen wrote: Hello I have been participating in an open source effort to specify a networked virtual environment protocol. Although Metaverse Exchange Protocol (MXP) is covering only part of the scope here I thought it might be interesting. MXP collects some good ideas to coherent theoretical model (Bubble Cloud) and proposes working engineering solution. One of the MXP over UDP key concepts is to have a minimal set of UDP messages for connectivity, transport and distributed virtual environment scene graph synchronization. All application specific information is transmitted as payload over the UDP messages encoded in MXMP format. Another key concept is to multiplex all the communication through one UDP port to simplify the session handling and network connectivity. Working C# prototype exists which demonstrates the reference implementation. I believe that MXP is a good read currently for people interested in NVE field. You can find the specification wiki from here: http://go-mxp.org best regards, Tommi Laukkanen _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-1546221477-1235319590=:12996 Content-Type: text/html; charset=us-ascii
Dear Meadhbh:

Can you help Tommi (and myself) understand what you mean? Was it inappropriate to make the MXP post to this list? I do not understand what the context is.

Charles

From: Meadhbh Hamrick (Infinity) <infinity@lindenlab.com>
To: Tommi Laukkanen <tommi.s.e.laukkanen@gmail.com>
Cc: mmox@ietf.org
Sent: Sunday, February 22, 2009 1:03:05 AM
Subject: Re: [mmox] Other NVE protocol specification efforts

tommi.. did you read the IPR disclosure rules?

On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen wrote:

Hello
 
I have been participating in an open source effort to specify a networked virtual environment protocol. Although Metaverse Exchange Protocol (MXP) is covering only part of the scope here I thought it might be interesting.
 
MXP collects some good ideas to coherent theoretical model (Bubble Cloud) and proposes working engineering solution. One of the MXP over UDP key concepts is to have a minimal set of UDP messages for connectivity, transport and distributed virtual environment scene graph synchronization. All application specific information is transmitted as payload over the UDP messages encoded in MXMP format. Another key concept is to multiplex all the communication through one UDP port to simplify the session handling and network connectivity.
 
Working C# prototype exists which demonstrates the reference implementation.
 
I believe that MXP is a good read currently for people interested in NVE field. You can find the specification wiki from here:
 
http://go-mxp.org
 
best regards,
Tommi Laukkanen
 
_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox

--0-1546221477-1235319590=:12996-- From gareth@litesim.com Sun Feb 22 08:29:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186C63A6AE5 for ; Sun, 22 Feb 2009 08:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyCnNZwfQDZc for ; Sun, 22 Feb 2009 08:29:32 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 6BC2A3A687A for ; Sun, 22 Feb 2009 08:29:31 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1495866rvb.49 for ; Sun, 22 Feb 2009 08:29:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.134.10 with SMTP id h10mr1561523rvd.287.1235320187227; Sun, 22 Feb 2009 08:29:47 -0800 (PST) In-Reply-To: <697430.23835.qm@web82605.mail.mud.yahoo.com> References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> Date: Sun, 22 Feb 2009 16:29:47 +0000 Message-ID: <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> From: Gareth Nelson To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 16:29:34 -0000 You've just beautifully summarised a nice argument for standardised client/server protocols......... so how do we convince providers to take up a standardised client/server protocol? I think we need to focus on something that can be added on to an existing setup, and that does limit a lot of design decisions. For example: meshes only, or prims only? meshes and prims? How much conversion will a server have to do to implement a prim-only protocol if it currently uses meshes? I'm sure there's plenty of other examples, even simple stuff like the 256x256 regions in SL for example. But my basic point is that it may be simpler to implement stuff that does not require massive internal changes. On Sun, Feb 22, 2009 at 3:34 PM, Charles Krinke wrote: > Well, what I "hope" we are really talking about is the beginnings of the 3D > internet where we can expect to evolve from "flat web pages" to 3D > interactive web communication. > > This whole thing feels like the discussions around web browsing about 25 > years ago. > > If we do our job right, then we will eventually expect that any 3D client > can expect to connect to any 3D server, negotiate a pre-described set of > capabilities and services and act in an analagous fashion that a web browser > does now. > > In order to get there, imagine that there were no HTTP or HTML, but rather a > few groups that had defined similar but incompatible web page formats so > that only their browser would read their web page. > > In order to get to a common experience, it would be necessary for these > groups to agree to a common standard so that the browsers could "interop" > with each other. > > That is the stage we are at today with the notion of "interop" and 3D > interactive web virtual worlds. > > So, be it wire protocol, or higher level interoperability issues, I think we > all need to work to get past our current biases and find a way to define 3D > interoperability so we can get past the "flat web" and evolve into the next > part of the internet evolution. > > Charles Krinke > OpenSim Core Developer > http://opensimulator.org > OSGrid Director > http://osgrid.org > > ________________________________ > From: Mark P. McCahill > To: Jon Watte > Cc: "mmox@ietf.org" > Sent: Sunday, February 22, 2009 5:14:50 AM > Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before > the cart > > Is it possible that two working groups could come out of this BOF process? > > The mailing list seems to be split - some are interested in the original > wire-level protocol > proposal, and another group is talking about higher-level interoperability > issues such as > identity and other issues including those Jon listed below. > > > On Feb 21, 2009, at 1:54 PM, Jon Watte wrote: > >> Dan Olivares wrote: >>> At this point in time, are there any more proposals for the working >>> group draft? Should we move on to establishing rough consensus and >>> BOF? >>> >> >> Here is a proposal for subjects for standardization and a general >> understanding of what the "common ground" would be. I believe that without >> standardizing at least all of these things, broad and useful >> interoperability cannot be achieved: >> >> - User identity is provided by an identity provider, which may be the >> "home" world of the user, or some other provider. Users should not need >> identity tied to the specific world they want to visit. Some worlds may >> choose to not accept certain specific credentials, just like certain >> real-world stores may not accept Candian dollars for payment. The market >> will work out a few major credential systems in the end (such as OpenID, >> perhaps). As long as each system is accessed uniformly, the specifics of the >> back end don't matter. >> >> - Geometry is based on regular meshes, possibly with LOD switches and >> lower-resolution physics meshes/proxies/hulls. I understand that this may be >> a sticking point for the SL-derived worlds (or do they actually support >> arbitrary meshes as an option now? I haven't kept up.) >> >> - Texturing is based on a regular Phong model with various defined texture >> maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on >> their own). Turns out, once you have the possibility of gloss maps, normal >> maps, emission maps, opacity maps, diffuse maps and ambient maps, you have >> 90% of the "look" of any one technology, which is about as good as you can >> hope for through interoperability. >> >> - Telemetry (entity movement) needs to be sent on a >> position/orientation/velocity basis, with dead reckoning. Delta compression >> and lower update rates can be used to keep bandwidth usage in check. This is >> a big difference for OLIVE, because we are input-synchronous, similar to >> City of Heroes or Age of Empires. However, again, this is the common >> denominator and experience speaking. >> >> - Animating objects need to use a common, widespread interchange format, >> using named animation clips and skeletal animation. Morph deformation is >> likely too big a payload to make sense, at least in the early stages. >> COLLADA is a good format for this, but there are other possibilities (FBX, >> X3D and X come to mind). I think that making at least one format required is >> a good idea, because that ensures a minimum level of interoperability is >> always present. >> >> - Simulation and script execution for a given object needs to be done on >> the "home" system for that object, because objects may be constructed >> assuming wildly disparate execution environments (X3D with JavaScript; Prims >> with SL Script, C++ with XML, Java with JSR 184, etc). >> >> - Objects need to be marked up with simple, well defined possible >> interactions, so that a user interface can be generated on each client based >> on those interactions. Interactions are typically "set this property to this >> value" or "execute this command." Such interactions need to be forwarded to >> the server that runs the object in question. Similarly, specific >> interactions ("emote animation," "collision," "damage," "two-party >> animation," "flight" etc) need to be defined. >> >> - Non-time-critical requests should go over HTTP and/or HTTPS, using >> XML-RPC or a similarly well understood protocol. >> >> - Time-critical and high-bandwidth data (such as entity telemetry and user >> inputs) should be sent using explicit (separate) schema, and binary >> representation, for the same reason that we don't send streaming video as >> XML, or mark each pixel with a color space identifier. >> >> Sincerely, >> >> Jon Watte >> Forterra Systems >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From cfk@pacbell.net Sun Feb 22 08:52:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13EE93A67F3 for ; Sun, 22 Feb 2009 08:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWDV2WTFNvj1 for ; Sun, 22 Feb 2009 08:52:47 -0800 (PST) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id C546E3A6850 for ; Sun, 22 Feb 2009 08:52:46 -0800 (PST) Received: (qmail 90107 invoked by uid 60001); 22 Feb 2009 16:53:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=USrEnCMcSbTsnOCIQiwXjI3T3meoGYqgxDBhTDvZJL9n9SnFNe3/hYX4KFGR6+afGFuxrWNAnwYeWC4tf4+6sqSBfYc//z785fk/zr+nUHNigqjv288Kochh+7lcuD032MDyYhfWL5cPYPJziJHiLEiGJsqxi68C0rOSwDy27W0=; X-YMail-OSG: 4N2CC04VM1mUoWZZHDWQzEnysHIKeCh7AM3byF.IurUazDbQjPguWOnmgPhJEAXnPQJ.n4vdVDkMIaqPevzruN_5DjAF1_SEXkq7gl5_kXpbfcwpqWnPQL7kPnuvWVE_J4vOjgyGpbj6.M9KmkfwBQyYSbC2R3xS3vtQfe2YZWGbb1SNrDnUgiRv37zF42lCzw5sZ5v.ASBT1YrgcF4kG76gyO8- Received: from [67.120.11.69] by web82605.mail.mud.yahoo.com via HTTP; Sun, 22 Feb 2009 08:53:03 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> Date: Sun, 22 Feb 2009 08:53:03 -0800 (PST) From: Charles Krinke To: Gareth Nelson MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-555210854-1235321583=:88005" Message-ID: <193588.88005.qm@web82605.mail.mud.yahoo.com> Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 16:52:49 -0000 --0-555210854-1235321583=:88005 Content-Type: text/plain; charset=us-ascii Dear Gareth: You have a very good point. I admit that I over simplified in the interests of trying to get us to focus a bit. I believe that as a client (or 3D browser) were to attempt to connect to a 3D server, that are currently a series of packets exchanged, perhaps some would call them the login procedure of which we are familiar. One could easily imagine that the login procedure (or perhaps the clientStack negotiation) would extend to include packets describing the clients capabilities and the server would reply with "+1" to those matching capabilities. Some clients may support prims, some meshes, some both. Some servers may support prims, meshes or both. A similar notion would exist for various script engines, physics plugins, graphics capabilities and the like. So, I think that we can get there from here. I do know that there are groups, including my own, OpenSim working on multiple client support right now. So, to the extent we can find a consensus amongst ourselves, we can de-babelize our future a bit. We will not stop the future, as those who are creating are continuing regardless of what we say or do. The best we can hope for is to have a minimum of the "Tower of Babel" effect and a maximum of interoperability. Charles ________________________________ From: Gareth Nelson To: Charles Krinke Cc: Mark P. McCahill ; Jon Watte ; "mmox@ietf.org" Sent: Sunday, February 22, 2009 8:29:47 AM Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart You've just beautifully summarised a nice argument for standardised client/server protocols......... so how do we convince providers to take up a standardised client/server protocol? I think we need to focus on something that can be added on to an existing setup, and that does limit a lot of design decisions. For example: meshes only, or prims only? meshes and prims? How much conversion will a server have to do to implement a prim-only protocol if it currently uses meshes? I'm sure there's plenty of other examples, even simple stuff like the 256x256 regions in SL for example. But my basic point is that it may be simpler to implement stuff that does not require massive internal changes. On Sun, Feb 22, 2009 at 3:34 PM, Charles Krinke wrote: > Well, what I "hope" we are really talking about is the beginnings of the 3D > internet where we can expect to evolve from "flat web pages" to 3D > interactive web communication. > > This whole thing feels like the discussions around web browsing about 25 > years ago. > > If we do our job right, then we will eventually expect that any 3D client > can expect to connect to any 3D server, negotiate a pre-described set of > capabilities and services and act in an analagous fashion that a web browser > does now. > > In order to get there, imagine that there were no HTTP or HTML, but rather a > few groups that had defined similar but incompatible web page formats so > that only their browser would read their web page. > > In order to get to a common experience, it would be necessary for these > groups to agree to a common standard so that the browsers could "interop" > with each other. > > That is the stage we are at today with the notion of "interop" and 3D > interactive web virtual worlds. > > So, be it wire protocol, or higher level interoperability issues, I think we > all need to work to get past our current biases and find a way to define 3D > interoperability so we can get past the "flat web" and evolve into the next > part of the internet evolution. > > Charles Krinke > OpenSim Core Developer > http://opensimulator.org > OSGrid Director > http://osgrid.org > > ________________________________ > From: Mark P. McCahill > To: Jon Watte > Cc: "mmox@ietf.org" > Sent: Sunday, February 22, 2009 5:14:50 AM > Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before > the cart > > Is it possible that two working groups could come out of this BOF process? > > The mailing list seems to be split - some are interested in the original > wire-level protocol > proposal, and another group is talking about higher-level interoperability > issues such as > identity and other issues including those Jon listed below. > > > On Feb 21, 2009, at 1:54 PM, Jon Watte wrote: > >> Dan Olivares wrote: >>> At this point in time, are there any more proposals for the working >>> group draft? Should we move on to establishing rough consensus and >>> BOF? >>> >> >> Here is a proposal for subjects for standardization and a general >> understanding of what the "common ground" would be. I believe that without >> standardizing at least all of these things, broad and useful >> interoperability cannot be achieved: >> >> - User identity is provided by an identity provider, which may be the >> "home" world of the user, or some other provider. Users should not need >> identity tied to the specific world they want to visit. Some worlds may >> choose to not accept certain specific credentials, just like certain >> real-world stores may not accept Candian dollars for payment. The market >> will work out a few major credential systems in the end (such as OpenID, >> perhaps). As long as each system is accessed uniformly, the specifics of the >> back end don't matter. >> >> - Geometry is based on regular meshes, possibly with LOD switches and >> lower-resolution physics meshes/proxies/hulls. I understand that this may be >> a sticking point for the SL-derived worlds (or do they actually support >> arbitrary meshes as an option now? I haven't kept up.) >> >> - Texturing is based on a regular Phong model with various defined texture >> maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on >> their own). Turns out, once you have the possibility of gloss maps, normal >> maps, emission maps, opacity maps, diffuse maps and ambient maps, you have >> 90% of the "look" of any one technology, which is about as good as you can >> hope for through interoperability. >> >> - Telemetry (entity movement) needs to be sent on a >> position/orientation/velocity basis, with dead reckoning. Delta compression >> and lower update rates can be used to keep bandwidth usage in check. This is >> a big difference for OLIVE, because we are input-synchronous, similar to >> City of Heroes or Age of Empires. However, again, this is the common >> denominator and experience speaking. >> >> - Animating objects need to use a common, widespread interchange format, >> using named animation clips and skeletal animation. Morph deformation is >> likely too big a payload to make sense, at least in the early stages. >> COLLADA is a good format for this, but there are other possibilities (FBX, >> X3D and X come to mind). I think that making at least one format required is >> a good idea, because that ensures a minimum level of interoperability is >> always present. >> >> - Simulation and script execution for a given object needs to be done on >> the "home" system for that object, because objects may be constructed >> assuming wildly disparate execution environments (X3D with JavaScript; Prims >> with SL Script, C++ with XML, Java with JSR 184, etc). >> >> - Objects need to be marked up with simple, well defined possible >> interactions, so that a user interface can be generated on each client based >> on those interactions. Interactions are typically "set this property to this >> value" or "execute this command." Such interactions need to be forwarded to >> the server that runs the object in question. Similarly, specific >> interactions ("emote animation," "collision," "damage," "two-party >> animation," "flight" etc) need to be defined. >> >> - Non-time-critical requests should go over HTTP and/or HTTPS, using >> XML-RPC or a similarly well understood protocol. >> >> - Time-critical and high-bandwidth data (such as entity telemetry and user >> inputs) should be sent using explicit (separate) schema, and binary >> representation, for the same reason that we don't send streaming video as >> XML, or mark each pixel with a color space identifier. >> >> Sincerely, >> >> Jon Watte >> Forterra Systems >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --0-555210854-1235321583=:88005 Content-Type: text/html; charset=us-ascii
Dear Gareth:

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

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

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

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

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

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

Charles

From: Gareth Nelson <gareth@litesim.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: Mark P. McCahill <mccahill@duke.edu>; Jon Watte <jwatte@gmail.com>; "mmox@ietf.org" <mmox@ietf.org>
Sent: Sunday, February 22, 2009 8:29:47 AM
Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart

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

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

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

On Sun, Feb 22, 2009 at 3:34 PM, Charles Krinke <cfk@pacbell.net> wrote:
> Well, what I "hope" we are really talking about is the beginnings of the 3D
> internet where we can expect to evolve from "flat web pages" to 3D
> interactive web communication.
>
> This whole thing feels like the discussions around web browsing about 25
> years ago.
>
> If we do our job right, then we will eventually expect that any 3D client
> can expect to connect to any 3D server, negotiate a pre-described set of
> capabilities and services and act in an analagous fashion that a web browser
> does now.
>
> In order to get there, imagine that there were no HTTP or HTML, but rather a
> few groups that had defined similar but incompatible web page formats so
> that only their browser would read their web page.
>
> In order to get to a common experience, it would be necessary for these
> groups to agree to a common standard so that the browsers could "interop"
> with each other.
>
> That is the stage we are at today with the notion of "interop" and 3D
> interactive web virtual worlds.
>
> So, be it wire protocol, or higher level interoperability issues, I think we
> all need to work to get past our current biases and find a way to define 3D
> interoperability so we can get past the "flat web" and evolve into the next
> part of the internet evolution.
>
> Charles Krinke
> OpenSim Core Developer
> http://opensimulator.org
> OSGrid Director
> http://osgrid.org
>
> ________________________________
> From: Mark P. McCahill <mccahill@duke.edu>
> To: Jon Watte <jwatte@gmail.com>
> Cc: "mmox@ietf.org" <mmox@ietf.org>
> Sent: Sunday, February 22, 2009 5:14:50 AM
> Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before
> the cart
>
> Is it possible that two working groups could come out of this BOF process?
>
> The mailing list seems to be split - some are interested in the original
> wire-level protocol
> proposal, and another group is talking about higher-level interoperability
> issues such as
> identity and other issues including those Jon listed below.
>
>
> On Feb 21, 2009, at 1:54 PM, Jon Watte wrote:
>
>> Dan Olivares wrote:
>>> At this point in time, are there any more proposals for the working
>>> group draft? Should we move on to establishing rough consensus and
>>> BOF?
>>>
>>
>> Here is a proposal for subjects for standardization and a general
>> understanding of what the "common ground" would be. I believe that without
>> standardizing at least all of these things, broad and useful
>> interoperability cannot be achieved:
>>
>> - User identity is provided by an identity provider, which may be the
>> "home" world of the user, or some other provider. Users should not need
>> identity tied to the specific world they want to visit. Some worlds may
>> choose to not accept certain specific credentials, just like certain
>> real-world stores may not accept Candian dollars for payment. The market
>> will work out a few major credential systems in the end (such as OpenID,
>> perhaps). As long as each system is accessed uniformly, the specifics of the
>> back end don't matter.
>>
>> - Geometry is based on regular meshes, possibly with LOD switches and
>> lower-resolution physics meshes/proxies/hulls. I understand that this may be
>> a sticking point for the SL-derived worlds (or do they actually support
>> arbitrary meshes as an option now? I haven't kept up.)
>>
>> - Texturing is based on a regular Phong model with various defined texture
>> maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable on
>> their own). Turns out, once you have the possibility of gloss maps, normal
>> maps, emission maps, opacity maps, diffuse maps and ambient maps, you have
>> 90% of the "look" of any one technology, which is about as good as you can
>> hope for through interoperability.
>>
>> - Telemetry (entity movement) needs to be sent on a
>> position/orientation/velocity basis, with dead reckoning. Delta compression
>> and lower update rates can be used to keep bandwidth usage in check. This is
>> a big difference for OLIVE, because we are input-synchronous, similar to
>> City of Heroes or Age of Empires. However, again, this is the common
>> denominator and experience speaking.
>>
>> - Animating objects need to use a common, widespread interchange format,
>> using named animation clips and skeletal animation. Morph deformation is
>> likely too big a payload to make sense, at least in the early stages.
>> COLLADA is a good format for this, but there are other possibilities (FBX,
>> X3D and X come to mind). I think that making at least one format required is
>> a good idea, because that ensures a minimum level of interoperability is
>> always present.
>>
>> - Simulation and script execution for a given object needs to be done on
>> the "home" system for that object, because objects may be constructed
>> assuming wildly disparate execution environments (X3D with JavaScript; Prims
>> with SL Script, C++ with XML, Java with JSR 184, etc).
>>
>> - Objects need to be marked up with simple, well defined possible
>> interactions, so that a user interface can be generated on each client based
>> on those interactions. Interactions are typically "set this property to this
>> value" or "execute this command." Such interactions need to be forwarded to
>> the server that runs the object in question. Similarly, specific
>> interactions ("emote animation," "collision," "damage," "two-party
>> animation," "flight" etc) need to be defined.
>>
>> - Non-time-critical requests should go over HTTP and/or HTTPS, using
>> XML-RPC or a similarly well understood protocol.
>>
>> - Time-critical and high-bandwidth data (such as entity telemetry and user
>> inputs) should be sent using explicit (separate) schema, and binary
>> representation, for the same reason that we don't send streaming video as
>> XML, or mark each pixel with a color space identifier.
>>
>> Sincerely,
>>
>> Jon Watte
>> Forterra Systems
>>
>>
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
>
--0-555210854-1235321583=:88005-- From gareth@litesim.com Sun Feb 22 09:14:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32AF3A67F6 for ; Sun, 22 Feb 2009 09:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.947 X-Spam-Level: X-Spam-Status: No, score=-1.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWmYPj5EXe10 for ; Sun, 22 Feb 2009 09:14:07 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 641393A6783 for ; Sun, 22 Feb 2009 09:14:07 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1504573rvb.49 for ; Sun, 22 Feb 2009 09:14:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.127.20 with SMTP id z20mr1594608rvc.100.1235322863567; Sun, 22 Feb 2009 09:14:23 -0800 (PST) In-Reply-To: <193588.88005.qm@web82605.mail.mud.yahoo.com> References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> Date: Sun, 22 Feb 2009 17:14:23 +0000 Message-ID: <61dbdd7d0902220914j789f920fkf2229f16a56eab1e@mail.gmail.com> From: Gareth Nelson To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 17:14:09 -0000 I can tell you're an opensim dev - clientstak eh? Anyway, I believe there are 2 basic approaches to the "tower of babel" problem for client<>server traffic: 1 - new protocol support on the servers 2 - proxies that do dynamic conversion What we should aim for is to specifiy the common denominator protocol that all these proxies can convert to and from. The capabilities should be part of the login procedure, and essentially are already partly there in the SL-compatible worlds. On Sun, Feb 22, 2009 at 4:53 PM, Charles Krinke wrote: > Dear Gareth: > > You have a very good point. I admit that I over simplified in the interests > of trying to get us to focus a bit. > > I believe that as a client (or 3D browser) were to attempt to connect to a > 3D server, that are currently a series of packets exchanged, perhaps some > would call them the login procedure of which we are familiar. > > One could easily imagine that the login procedure (or perhaps the > clientStack negotiation) would extend to include packets describing the > clients capabilities and the server would reply with "+1" to those matching > capabilities. Some clients may support prims, some meshes, some both. Some > servers may support prims, meshes or both. > > A similar notion would exist for various script engines, physics plugins, > graphics capabilities and the like. > > So, I think that we can get there from here. I do know that there are > groups, including my own, OpenSim working on multiple client support right > now. So, to the extent we can find a consensus amongst ourselves, we can > de-babelize our future a bit. We will not stop the future, as those who are > creating are continuing regardless of what we say or do. > > The best we can hope for is to have a minimum of the "Tower of Babel" effect > and a maximum of interoperability. > > Charles > > ________________________________ > From: Gareth Nelson > To: Charles Krinke > Cc: Mark P. McCahill ; Jon Watte ; > "mmox@ietf.org" > Sent: Sunday, February 22, 2009 8:29:47 AM > Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before > the cart > > You've just beautifully summarised a nice argument for standardised > client/server protocols......... so how do we convince providers to > take up a standardised client/server protocol? > I think we need to focus on something that can be added on to an > existing setup, and that does limit a lot of design decisions. > > For example: > meshes only, or prims only? > meshes and prims? > How much conversion will a server have to do to implement a prim-only > protocol if it currently uses meshes? > > I'm sure there's plenty of other examples, even simple stuff like the > 256x256 regions in SL for example. But my basic point is that it may > be simpler to implement stuff that does not require massive internal > changes. > > On Sun, Feb 22, 2009 at 3:34 PM, Charles Krinke wrote: >> Well, what I "hope" we are really talking about is the beginnings of the >> 3D >> internet where we can expect to evolve from "flat web pages" to 3D >> interactive web communication. >> >> This whole thing feels like the discussions around web browsing about 25 >> years ago. >> >> If we do our job right, then we will eventually expect that any 3D client >> can expect to connect to any 3D server, negotiate a pre-described set of >> capabilities and services and act in an analagous fashion that a web >> browser >> does now. >> >> In order to get there, imagine that there were no HTTP or HTML, but rather >> a >> few groups that had defined similar but incompatible web page formats so >> that only their browser would read their web page. >> >> In order to get to a common experience, it would be necessary for these >> groups to agree to a common standard so that the browsers could "interop" >> with each other. >> >> That is the stage we are at today with the notion of "interop" and 3D >> interactive web virtual worlds. >> >> So, be it wire protocol, or higher level interoperability issues, I think >> we >> all need to work to get past our current biases and find a way to define >> 3D >> interoperability so we can get past the "flat web" and evolve into the >> next >> part of the internet evolution. >> >> Charles Krinke >> OpenSim Core Developer >> http://opensimulator.org >> OSGrid Director >> http://osgrid.org >> >> ________________________________ >> From: Mark P. McCahill >> To: Jon Watte >> Cc: "mmox@ietf.org" >> Sent: Sunday, February 22, 2009 5:14:50 AM >> Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before >> the cart >> >> Is it possible that two working groups could come out of this BOF process? >> >> The mailing list seems to be split - some are interested in the original >> wire-level protocol >> proposal, and another group is talking about higher-level interoperability >> issues such as >> identity and other issues including those Jon listed below. >> >> >> On Feb 21, 2009, at 1:54 PM, Jon Watte wrote: >> >>> Dan Olivares wrote: >>>> At this point in time, are there any more proposals for the working >>>> group draft? Should we move on to establishing rough consensus and >>>> BOF? >>>> >>> >>> Here is a proposal for subjects for standardization and a general >>> understanding of what the "common ground" would be. I believe that >>> without >>> standardizing at least all of these things, broad and useful >>> interoperability cannot be achieved: >>> >>> - User identity is provided by an identity provider, which may be the >>> "home" world of the user, or some other provider. Users should not need >>> identity tied to the specific world they want to visit. Some worlds may >>> choose to not accept certain specific credentials, just like certain >>> real-world stores may not accept Candian dollars for payment. The market >>> will work out a few major credential systems in the end (such as OpenID, >>> perhaps). As long as each system is accessed uniformly, the specifics of >>> the >>> back end don't matter. >>> >>> - Geometry is based on regular meshes, possibly with LOD switches and >>> lower-resolution physics meshes/proxies/hulls. I understand that this may >>> be >>> a sticking point for the SL-derived worlds (or do they actually support >>> arbitrary meshes as an option now? I haven't kept up.) >>> >>> - Texturing is based on a regular Phong model with various defined >>> texture >>> maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable >>> on >>> their own). Turns out, once you have the possibility of gloss maps, >>> normal >>> maps, emission maps, opacity maps, diffuse maps and ambient maps, you >>> have >>> 90% of the "look" of any one technology, which is about as good as you >>> can >>> hope for through interoperability. >>> >>> - Telemetry (entity movement) needs to be sent on a >>> position/orientation/velocity basis, with dead reckoning. Delta >>> compression >>> and lower update rates can be used to keep bandwidth usage in check. This >>> is >>> a big difference for OLIVE, because we are input-synchronous, similar to >>> City of Heroes or Age of Empires. However, again, this is the common >>> denominator and experience speaking. >>> >>> - Animating objects need to use a common, widespread interchange format, >>> using named animation clips and skeletal animation. Morph deformation is >>> likely too big a payload to make sense, at least in the early stages. >>> COLLADA is a good format for this, but there are other possibilities >>> (FBX, >>> X3D and X come to mind). I think that making at least one format required >>> is >>> a good idea, because that ensures a minimum level of interoperability is >>> always present. >>> >>> - Simulation and script execution for a given object needs to be done on >>> the "home" system for that object, because objects may be constructed >>> assuming wildly disparate execution environments (X3D with JavaScript; >>> Prims >>> with SL Script, C++ with XML, Java with JSR 184, etc). >>> >>> - Objects need to be marked up with simple, well defined possible >>> interactions, so that a user interface can be generated on each client >>> based >>> on those interactions. Interactions are typically "set this property to >>> this >>> value" or "execute this command." Such interactions need to be forwarded >>> to >>> the server that runs the object in question. Similarly, specific >>> interactions ("emote animation," "collision," "damage," "two-party >>> animation," "flight" etc) need to be defined. >>> >>> - Non-time-critical requests should go over HTTP and/or HTTPS, using >>> XML-RPC or a similarly well understood protocol. >>> >>> - Time-critical and high-bandwidth data (such as entity telemetry and >>> user >>> inputs) should be sent using explicit (separate) schema, and binary >>> representation, for the same reason that we don't send streaming video as >>> XML, or mark each pixel with a color space identifier. >>> >>> Sincerely, >>> >>> Jon Watte >>> Forterra Systems >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > From cfk@pacbell.net Sun Feb 22 09:18:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E25A3A6878 for ; Sun, 22 Feb 2009 09:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFkkES8vYWO9 for ; Sun, 22 Feb 2009 09:18:24 -0800 (PST) Received: from web82605.mail.mud.yahoo.com (web82605.mail.mud.yahoo.com [68.142.201.122]) by core3.amsl.com (Postfix) with SMTP id F2D523A68A8 for ; Sun, 22 Feb 2009 09:18:23 -0800 (PST) Received: (qmail 10962 invoked by uid 60001); 22 Feb 2009 17:18:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=z0m4Kp5HQDTblPVm43YZHt9AygbOxnZ1i037+GvdT0o6tYGIbUsyod1a9daML0szgunTArJO+6kKvKB5p6HgpVcv0kR6faRxOJ3W4vISKsH/eQF3JiKr7ELWOn0Wc9peAXUpOe9D10MbX2BJwVg1/+e7Lv2CSZ3o20oPfmOFp0A=; X-YMail-OSG: UsscS7gVM1nN7AnhOQ9W90YNHqQogqRFEjKvJe9tBcxwLHXUUaSMntMeEVLUYkO4tH3XdFbybuQVTgKTVrJS34GGRGcJomEkYvmlbN8o6gw_ZrJGp_9kZ10e8VUll9WaOF0LHVVn4jPFFHJrIMPFvUqOq_j0wNCwlOnquR9daJtqiKVcLfcu7hzSFs4zqHwtnPeV40MEd9jOnjaFaVw2GlnaSP4- Received: from [67.120.11.69] by web82605.mail.mud.yahoo.com via HTTP; Sun, 22 Feb 2009 09:18:39 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220914j789f920fkf2229f16a56eab1e@mail.gmail.com> Date: Sun, 22 Feb 2009 09:18:39 -0800 (PST) From: Charles Krinke To: Gareth Nelson MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2038491253-1235323119=:5882" Message-ID: <21199.5882.qm@web82605.mail.mud.yahoo.com> Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 17:18:26 -0000 --0-2038491253-1235323119=:5882 Content-Type: text/plain; charset=us-ascii +1 ________________________________ From: Gareth Nelson To: Charles Krinke Cc: Mark P. McCahill ; Jon Watte ; "mmox@ietf.org" Sent: Sunday, February 22, 2009 9:14:23 AM Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart I can tell you're an opensim dev - clientstak eh? Anyway, I believe there are 2 basic approaches to the "tower of babel" problem for client<>server traffic: 1 - new protocol support on the servers 2 - proxies that do dynamic conversion What we should aim for is to specifiy the common denominator protocol that all these proxies can convert to and from. The capabilities should be part of the login procedure, and essentially are already partly there in the SL-compatible worlds. On Sun, Feb 22, 2009 at 4:53 PM, Charles Krinke wrote: > Dear Gareth: > > You have a very good point. I admit that I over simplified in the interests > of trying to get us to focus a bit. > > I believe that as a client (or 3D browser) were to attempt to connect to a > 3D server, that are currently a series of packets exchanged, perhaps some > would call them the login procedure of which we are familiar. > > One could easily imagine that the login procedure (or perhaps the > clientStack negotiation) would extend to include packets describing the > clients capabilities and the server would reply with "+1" to those matching > capabilities. Some clients may support prims, some meshes, some both. Some > servers may support prims, meshes or both. > > A similar notion would exist for various script engines, physics plugins, > graphics capabilities and the like. > > So, I think that we can get there from here. I do know that there are > groups, including my own, OpenSim working on multiple client support right > now. So, to the extent we can find a consensus amongst ourselves, we can > de-babelize our future a bit. We will not stop the future, as those who are > creating are continuing regardless of what we say or do. > > The best we can hope for is to have a minimum of the "Tower of Babel" effect > and a maximum of interoperability. > > Charles > > ________________________________ > From: Gareth Nelson > To: Charles Krinke > Cc: Mark P. McCahill ; Jon Watte ; > "mmox@ietf.org" > Sent: Sunday, February 22, 2009 8:29:47 AM > Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before > the cart > > You've just beautifully summarised a nice argument for standardised > client/server protocols......... so how do we convince providers to > take up a standardised client/server protocol? > I think we need to focus on something that can be added on to an > existing setup, and that does limit a lot of design decisions. > > For example: > meshes only, or prims only? > meshes and prims? > How much conversion will a server have to do to implement a prim-only > protocol if it currently uses meshes? > > I'm sure there's plenty of other examples, even simple stuff like the > 256x256 regions in SL for example. But my basic point is that it may > be simpler to implement stuff that does not require massive internal > changes. > > On Sun, Feb 22, 2009 at 3:34 PM, Charles Krinke wrote: >> Well, what I "hope" we are really talking about is the beginnings of the >> 3D >> internet where we can expect to evolve from "flat web pages" to 3D >> interactive web communication. >> >> This whole thing feels like the discussions around web browsing about 25 >> years ago. >> >> If we do our job right, then we will eventually expect that any 3D client >> can expect to connect to any 3D server, negotiate a pre-described set of >> capabilities and services and act in an analagous fashion that a web >> browser >> does now. >> >> In order to get there, imagine that there were no HTTP or HTML, but rather >> a >> few groups that had defined similar but incompatible web page formats so >> that only their browser would read their web page. >> >> In order to get to a common experience, it would be necessary for these >> groups to agree to a common standard so that the browsers could "interop" >> with each other. >> >> That is the stage we are at today with the notion of "interop" and 3D >> interactive web virtual worlds. >> >> So, be it wire protocol, or higher level interoperability issues, I think >> we >> all need to work to get past our current biases and find a way to define >> 3D >> interoperability so we can get past the "flat web" and evolve into the >> next >> part of the internet evolution. >> >> Charles Krinke >> OpenSim Core Developer >> http://opensimulator.org >> OSGrid Director >> http://osgrid.org >> >> ________________________________ >> From: Mark P. McCahill >> To: Jon Watte >> Cc: "mmox@ietf.org" >> Sent: Sunday, February 22, 2009 5:14:50 AM >> Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before >> the cart >> >> Is it possible that two working groups could come out of this BOF process? >> >> The mailing list seems to be split - some are interested in the original >> wire-level protocol >> proposal, and another group is talking about higher-level interoperability >> issues such as >> identity and other issues including those Jon listed below. >> >> >> On Feb 21, 2009, at 1:54 PM, Jon Watte wrote: >> >>> Dan Olivares wrote: >>>> At this point in time, are there any more proposals for the working >>>> group draft? Should we move on to establishing rough consensus and >>>> BOF? >>>> >>> >>> Here is a proposal for subjects for standardization and a general >>> understanding of what the "common ground" would be. I believe that >>> without >>> standardizing at least all of these things, broad and useful >>> interoperability cannot be achieved: >>> >>> - User identity is provided by an identity provider, which may be the >>> "home" world of the user, or some other provider. Users should not need >>> identity tied to the specific world they want to visit. Some worlds may >>> choose to not accept certain specific credentials, just like certain >>> real-world stores may not accept Candian dollars for payment. The market >>> will work out a few major credential systems in the end (such as OpenID, >>> perhaps). As long as each system is accessed uniformly, the specifics of >>> the >>> back end don't matter. >>> >>> - Geometry is based on regular meshes, possibly with LOD switches and >>> lower-resolution physics meshes/proxies/hulls. I understand that this may >>> be >>> a sticking point for the SL-derived worlds (or do they actually support >>> arbitrary meshes as an option now? I haven't kept up.) >>> >>> - Texturing is based on a regular Phong model with various defined >>> texture >>> maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable >>> on >>> their own). Turns out, once you have the possibility of gloss maps, >>> normal >>> maps, emission maps, opacity maps, diffuse maps and ambient maps, you >>> have >>> 90% of the "look" of any one technology, which is about as good as you >>> can >>> hope for through interoperability. >>> >>> - Telemetry (entity movement) needs to be sent on a >>> position/orientation/velocity basis, with dead reckoning. Delta >>> compression >>> and lower update rates can be used to keep bandwidth usage in check. This >>> is >>> a big difference for OLIVE, because we are input-synchronous, similar to >>> City of Heroes or Age of Empires. However, again, this is the common >>> denominator and experience speaking. >>> >>> - Animating objects need to use a common, widespread interchange format, >>> using named animation clips and skeletal animation. Morph deformation is >>> likely too big a payload to make sense, at least in the early stages. >>> COLLADA is a good format for this, but there are other possibilities >>> (FBX, >>> X3D and X come to mind). I think that making at least one format required >>> is >>> a good idea, because that ensures a minimum level of interoperability is >>> always present. >>> >>> - Simulation and script execution for a given object needs to be done on >>> the "home" system for that object, because objects may be constructed >>> assuming wildly disparate execution environments (X3D with JavaScript; >>> Prims >>> with SL Script, C++ with XML, Java with JSR 184, etc). >>> >>> - Objects need to be marked up with simple, well defined possible >>> interactions, so that a user interface can be generated on each client >>> based >>> on those interactions. Interactions are typically "set this property to >>> this >>> value" or "execute this command." Such interactions need to be forwarded >>> to >>> the server that runs the object in question. Similarly, specific >>> interactions ("emote animation," "collision," "damage," "two-party >>> animation," "flight" etc) need to be defined. >>> >>> - Non-time-critical requests should go over HTTP and/or HTTPS, using >>> XML-RPC or a similarly well understood protocol. >>> >>> - Time-critical and high-bandwidth data (such as entity telemetry and >>> user >>> inputs) should be sent using explicit (separate) schema, and binary >>> representation, for the same reason that we don't send streaming video as >>> XML, or mark each pixel with a color space identifier. >>> >>> Sincerely, >>> >>> Jon Watte >>> Forterra Systems >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > --0-2038491253-1235323119=:5882 Content-Type: text/html; charset=us-ascii
+1

From: Gareth Nelson <gareth@litesim.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: Mark P. McCahill <mccahill@duke.edu>; Jon Watte <jwatte@gmail.com>; "mmox@ietf.org" <mmox@ietf.org>
Sent: Sunday, February 22, 2009 9:14:23 AM
Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart

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

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

On Sun, Feb 22, 2009 at 4:53 PM, Charles Krinke <cfk@pacbell.net> wrote:
> Dear Gareth:
>
> You have a very good point. I admit that I over simplified in the interests
> of trying to get us to focus a bit.
>
> I believe that as a client (or 3D browser) were to attempt to connect to a
> 3D server, that are currently a series of packets exchanged, perhaps some
> would call them the login procedure of which we are familiar.
>
> One could easily imagine that the login procedure (or perhaps the
> clientStack negotiation) would extend to include packets describing the
> clients capabilities and the server would reply with "+1" to those matching
> capabilities. Some clients may support prims, some meshes, some both. Some
> servers may support prims, meshes or both.
>
> A similar notion would exist for various script engines, physics plugins,
> graphics capabilities and the like.
>
> So, I think that we can get there from here. I do know that there are
> groups, including my own, OpenSim working on multiple client support right
> now. So, to the extent we can find a consensus amongst ourselves, we can
> de-babelize our future a bit. We will not stop the future, as those who are
> creating are continuing regardless of what we say or do.
>
> The best we can hope for is to have a minimum of the "Tower of Babel" effect
> and a maximum of interoperability.
>
> Charles
>
> ________________________________
> From: Gareth Nelson <gareth@litesim.com>
> To: Charles Krinke <cfk@pacbell.net>
> Cc: Mark P. McCahill <mccahill@duke.edu>; Jon Watte <jwatte@gmail.com>;
> "mmox@ietf.org" <mmox@ietf.org>
> Sent: Sunday, February 22, 2009 8:29:47 AM
> Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before
> the cart
>
> You've just beautifully summarised a nice argument for standardised
> client/server protocols......... so how do we convince providers to
> take up a standardised client/server protocol?
> I think we need to focus on something that can be added on to an
> existing setup, and that does limit a lot of design decisions.
>
> For example:
> meshes only, or prims only?
> meshes and prims?
> How much conversion will a server have to do to implement a prim-only
> protocol if it currently uses meshes?
>
> I'm sure there's plenty of other examples, even simple stuff like the
> 256x256 regions in SL for example. But my basic point is that it may
> be simpler to implement stuff that does not require massive internal
> changes.
>
> On Sun, Feb 22, 2009 at 3:34 PM, Charles Krinke <cfk@pacbell.net> wrote:
>> Well, what I "hope" we are really talking about is the beginnings of the
>> 3D
>> internet where we can expect to evolve from "flat web pages" to 3D
>> interactive web communication.
>>
>> This whole thing feels like the discussions around web browsing about 25
>> years ago.
>>
>> If we do our job right, then we will eventually expect that any 3D client
>> can expect to connect to any 3D server, negotiate a pre-described set of
>> capabilities and services and act in an analagous fashion that a web
>> browser
>> does now.
>>
>> In order to get there, imagine that there were no HTTP or HTML, but rather
>> a
>> few groups that had defined similar but incompatible web page formats so
>> that only their browser would read their web page.
>>
>> In order to get to a common experience, it would be necessary for these
>> groups to agree to a common standard so that the browsers could "interop"
>> with each other.
>>
>> That is the stage we are at today with the notion of "interop" and 3D
>> interactive web virtual worlds.
>>
>> So, be it wire protocol, or higher level interoperability issues, I think
>> we
>> all need to work to get past our current biases and find a way to define
>> 3D
>> interoperability so we can get past the "flat web" and evolve into the
>> next
>> part of the internet evolution.
>>
>> Charles Krinke
>> OpenSim Core Developer
>> http://opensimulator.org
>> OSGrid Director
>> http://osgrid.org
>>
>> ________________________________
>> From: Mark P. McCahill <mccahill@duke.edu>
>> To: Jon Watte <jwatte@gmail.com>
>> Cc: "mmox@ietf.org" <mmox@ietf.org>
>> Sent: Sunday, February 22, 2009 5:14:50 AM
>> Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before
>> the cart
>>
>> Is it possible that two working groups could come out of this BOF process?
>>
>> The mailing list seems to be split - some are interested in the original
>> wire-level protocol
>> proposal, and another group is talking about higher-level interoperability
>> issues such as
>> identity and other issues including those Jon listed below.
>>
>>
>> On Feb 21, 2009, at 1:54 PM, Jon Watte wrote:
>>
>>> Dan Olivares wrote:
>>>> At this point in time, are there any more proposals for the working
>>>> group draft? Should we move on to establishing rough consensus and
>>>> BOF?
>>>>
>>>
>>> Here is a proposal for subjects for standardization and a general
>>> understanding of what the "common ground" would be. I believe that
>>> without
>>> standardizing at least all of these things, broad and useful
>>> interoperability cannot be achieved:
>>>
>>> - User identity is provided by an identity provider, which may be the
>>> "home" world of the user, or some other provider. Users should not need
>>> identity tied to the specific world they want to visit. Some worlds may
>>> choose to not accept certain specific credentials, just like certain
>>> real-world stores may not accept Candian dollars for payment. The market
>>> will work out a few major credential systems in the end (such as OpenID,
>>> perhaps). As long as each system is accessed uniformly, the specifics of
>>> the
>>> back end don't matter.
>>>
>>> - Geometry is based on regular meshes, possibly with LOD switches and
>>> lower-resolution physics meshes/proxies/hulls. I understand that this may
>>> be
>>> a sticking point for the SL-derived worlds (or do they actually support
>>> arbitrary meshes as an option now? I haven't kept up.)
>>>
>>> - Texturing is based on a regular Phong model with various defined
>>> texture
>>> maps (because HLSL vs GLSL vs some-other-SL are each of them not suitable
>>> on
>>> their own). Turns out, once you have the possibility of gloss maps,
>>> normal
>>> maps, emission maps, opacity maps, diffuse maps and ambient maps, you
>>> have
>>> 90% of the "look" of any one technology, which is about as good as you
>>> can
>>> hope for through interoperability.
>>>
>>> - Telemetry (entity movement) needs to be sent on a
>>> position/orientation/velocity basis, with dead reckoning. Delta
>>> compression
>>> and lower update rates can be used to keep bandwidth usage in check. This
>>> is
>>> a big difference for OLIVE, because we are input-synchronous, similar to
>>> City of Heroes or Age of Empires. However, again, this is the common
>>> denominator and experience speaking.
>>>
>>> - Animating objects need to use a common, widespread interchange format,
>>> using named animation clips and skeletal animation. Morph deformation is
>>> likely too big a payload to make sense, at least in the early stages.
>>> COLLADA is a good format for this, but there are other possibilities
>>> (FBX,
>>> X3D and X come to mind). I think that making at least one format required
>>> is
>>> a good idea, because that ensures a minimum level of interoperability is
>>> always present.
>>>
>>> - Simulation and script execution for a given object needs to be done on
>>> the "home" system for that object, because objects may be constructed
>>> assuming wildly disparate execution environments (X3D with JavaScript;
>>> Prims
>>> with SL Script, C++ with XML, Java with JSR 184, etc).
>>>
>>> - Objects need to be marked up with simple, well defined possible
>>> interactions, so that a user interface can be generated on each client
>>> based
>>> on those interactions. Interactions are typically "set this property to
>>> this
>>> value" or "execute this command." Such interactions need to be forwarded
>>> to
>>> the server that runs the object in question. Similarly, specific
>>> interactions ("emote animation," "collision," "damage," "two-party
>>> animation," "flight" etc) need to be defined.
>>>
>>> - Non-time-critical requests should go over HTTP and/or HTTPS, using
>>> XML-RPC or a similarly well understood protocol.
>>>
>>> - Time-critical and high-bandwidth data (such as entity telemetry and
>>> user
>>> inputs) should be sent using explicit (separate) schema, and binary
>>> representation, for the same reason that we don't send streaming video as
>>> XML, or mark each pixel with a color space identifier.
>>>
>>> Sincerely,
>>>
>>> Jon Watte
>>> Forterra Systems
>>>
>>>
>>> _______________________________________________
>>> mmox mailing list
>>> mmox@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmox
>>
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
>>
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
>>
>>
>
--0-2038491253-1235323119=:5882-- From cs@comlounge.net Sun Feb 22 09:56:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C5A3A6783 for ; Sun, 22 Feb 2009 09:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.255 X-Spam-Level: X-Spam-Status: No, score=-1.255 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dM02WgtPJG5a for ; Sun, 22 Feb 2009 09:56:02 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 002043A6875 for ; Sun, 22 Feb 2009 09:56:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 258C11CE042A; Sun, 22 Feb 2009 18:56:17 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tB2T0McWyujH; Sun, 22 Feb 2009 18:56:16 +0100 (CET) Received: from Labertasche.local (unknown [212.117.76.202]) by post.comlounge.net (Postfix) with ESMTP id 9ACB21CE02F7; Sun, 22 Feb 2009 18:56:13 +0100 (CET) Message-ID: <49A191BB.40106@comlounge.net> Date: Sun, 22 Feb 2009 18:56:11 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Charles Krinke References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> In-Reply-To: <193588.88005.qm@web82605.mail.mud.yahoo.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 17:56:03 -0000 Charles Krinke wrote: > Dear Gareth: > > You have a very good point. I admit that I over simplified in the > interests of trying to get us to focus a bit. > > I believe that as a client (or 3D browser) were to attempt to connect to > a 3D server, that are currently a series of packets exchanged, perhaps > some would call them the login procedure of which we are familiar. > > One could easily imagine that the login procedure (or perhaps the > clientStack negotiation) would extend to include packets describing the > clients capabilities and the server would reply with "+1" to those > matching capabilities. Some clients may support prims, some meshes, some > both. Some servers may support prims, meshes or both. That's what I was thinking the service discovery could be used for. You just check the server's service catalogue for formats/APIs you support. These might even contain priorities so that you know which ones are the preferred method. This discovery can span various areas. Still some MMOX spec should probably define a set of preferred or even required formats because otherwise we won't get interop anytime soon. -- Christian -- 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 cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de) new podcast: Data Without Borders (http://datawithoutborders.net) From gareth@litesim.com Sun Feb 22 10:04:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EEDD28C0FD for ; Sun, 22 Feb 2009 10:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIKSZKgtNPBf for ; Sun, 22 Feb 2009 10:04:16 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 75EF128C0F4 for ; Sun, 22 Feb 2009 10:04:16 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2054716wfd.31 for ; Sun, 22 Feb 2009 10:04:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.157.4 with SMTP id f4mr2151806rve.1.1235325872005; Sun, 22 Feb 2009 10:04:32 -0800 (PST) In-Reply-To: <49A191BB.40106@comlounge.net> References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <49A191BB.40106@comlounge.net> Date: Sun, 22 Feb 2009 18:04:31 +0000 Message-ID: <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> From: Gareth Nelson To: Christian Scholz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 18:04:17 -0000 So, now we're back to square 1. A few thoughts: Do we do the whole agent/region domain split a la OGP? If so, then the agent domain can serve up the authentication and identity stuff, while region domain serves up standard caps for........ what? I propose HTTP for assets, with a standard base URL for each region domain and agent domain, and a basic description of the avatar as first step in defining the real "meat" of the 3D stuff. On Sun, Feb 22, 2009 at 5:56 PM, Christian Scholz wrote: > Charles Krinke wrote: >> Dear Gareth: >> >> You have a very good point. I admit that I over simplified in the >> interests of trying to get us to focus a bit. >> >> I believe that as a client (or 3D browser) were to attempt to connect to >> a 3D server, that are currently a series of packets exchanged, perhaps >> some would call them the login procedure of which we are familiar. >> >> One could easily imagine that the login procedure (or perhaps the >> clientStack negotiation) would extend to include packets describing the >> clients capabilities and the server would reply with "+1" to those >> matching capabilities. Some clients may support prims, some meshes, some >> both. Some servers may support prims, meshes or both. > > That's what I was thinking the service discovery could be used for. > You just check the server's service catalogue for formats/APIs you > support. These might even contain priorities so that you know which ones > are the preferred method. This discovery can span various areas. > > Still some MMOX spec should probably define a set of preferred or even > required formats because otherwise we won't get interop anytime soon. > > -- Christian > > -- > 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 cs@comlounge.net > 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 mccahill@duke.edu Sun Feb 22 10:30:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7250C3A68F4 for ; Sun, 22 Feb 2009 10:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPyJNpX7gRc3 for ; Sun, 22 Feb 2009 10:30:29 -0800 (PST) Received: from smtp.duke.edu (smtp-03.oit.duke.edu [152.3.174.16]) by core3.amsl.com (Postfix) with ESMTP id 7FE463A67F7 for ; Sun, 22 Feb 2009 10:30:29 -0800 (PST) Received: from smtp.duke.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C3EAF805D; Sun, 22 Feb 2009 13:30:43 -0500 (EST) Received: from [192.168.1.3] (cpe-066-057-004-163.nc.res.rr.com [66.57.4.163]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.duke.edu (Postfix) with ESMTP id 220A1803F; Sun, 22 Feb 2009 13:30:43 -0500 (EST) Message-Id: From: "Mark P. McCahill" To: Christian Scholz In-Reply-To: <49A16F4D.8070007@comlounge.net> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Feb 2009 13:30:41 -0500 References: <49A04DEB.4060301@gmail.com> <49A16F4D.8070007@comlounge.net> X-Mailer: Apple Mail (2.930.3) X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2009.2.22.181913 Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 18:30:31 -0000 On Feb 22, 2009, at 10:29 AM, Christian Scholz wrote: > Hi! > > Mark P. McCahill wrote: >> Is it possible that two working groups could come out of this BOF =20 >> process? >> >> The mailing list seems to be split - some are interested in the =20 >> original >> wire-level protocol >> proposal, and another group is talking about higher-level >> interoperability issues such as >> identity and other issues including those Jon listed below. > > I was wondering actually if those identity related matters are =20 > actually > not broader than just virtual worlds and if it then fits into this > working group (lets say if some web site wants to use it it might feel > strange to refer to some VW specific standard). > I think it fits into this working group in a couple ways. For interoperability across multiple worlds and identity systems, we =20 need to describe how clients and servers negotiate which forms of credentials =20= are acceptable to establish an identity. You cannot do very much in a social space before an identity has been established for the avatar. If we accept the idea of federated identity, avatar names as used in current practice need to change. They would need to include the party =20= that issued the identity - something like this: = Mysterio_Sinister@secondlife.com=20 or mccahill@duke.edu. I agree that this overlaps many of the social networks and other =20 internet services. That is another reason that working on the identity and presence =20 problems now appeals to me - it would have a very large payoff in terms of =20 cross-system interoperability, and could be fairly easy to add to existing services =20= and virtual worlds. > And "identity related matters" can mean the following: > > Authentication > How to use my identity from somewhere else on a new site (here things > like OpenID, YADIS, InformationCards etc. play in. There also is =20 > already > a big community around this topic, see [1]. > > Authorization > How to allow consumer services access to protected resources on =20 > service > providers on behalf of the user and without knowing a user's password > (or whatever is used to login). The question here is how we can find a > tradeoff between control and good user experience (e.g. not asking the > user for every service if it's ok to access it). Related work is done > with OAuth[2] which seems to gain traction but still has various > shortcomings which are discussed at the moment. > > Service Discovery > A user might have various services associated, such as profile > information, the social graph (contacts), photos, 3d assets in various > places, groups, preferred IM servers, activity streams and so on. > If the user signs up somewhere it would be good if it can be avoided > that all URLs to those services needs to be entered. Instead a service > catalogue might be useful which holds all of the users services sorted > by type. The user could then choose which services to allow access to. > The same is useful for service providers. Like some OpenSim or other > virtual world region might have different sub-components the client > needs to talk to. These can be defined the same way (for OpenSim =20 > that's > GridInfo right now IIRC). > There is a spec called XRDS-Simple[3] which is based on XRDS which =20 > again > is used for OpenID discovery (YADIS) to find out what identity =20 > services > are actually available at the URL the user enters. While XRDS-Simple =20= > is > now deprecated[4] a new spec (at OASIS) is being written called XRD > which has is supposed to be a better version of XRDS-Simple. At [5] =20= > are > some more thoughts on discovery. > > Various formats/APIs for moving data around > Having authentication, authorization and service discovery one can =20 > then > go ahead and actually exchange data. There are of course many types of > data one can think about. The most basic thing is usually profile > information though, followed by contacts. This at least is what I have > to enter/find over and over again with each signup to a new service. > In virtual worlds finding your friends might even be more difficulty > because they might not have the same names on every platform (e.g. > because you cannot freely choose your name like in SL). > There are already many solutions to this problem like FOAF/RDF, > Microformats or OpenSocial's REST API. I personally prefer the latter > because REST means that you also can write data back (although right =20= > now > no service to my knowledge supports that). Microformats is probably =20= > out > due to the requirement of HTML which you might not always have in VWs. > Other possible services might be group management, IM, inventory > management (it would be great to have a standardized REST interface =20= > for > that) and so on. The question is though if all this should be in the > scope of such an identity based WG. Probably not. > > Synchronisation > It's nice to be able to copy data around to whatever service you =20 > want to > but if it cannot be synced it might be worthless after a while. So =20 > some > means of synchronisation could be defined, e.g. based on XMPP/ATOM =20 > etc. > This might also play into the field of activity streams, another hot > topic on the web right now. > > > So these are my basic thoughts about this. As a result it would be =20 > nice > to have > > - one definitive URL (or whatever format) for your identity starting > point (per identity) > - a way for other services to discover which types of data you provide > on the net and a mechanism to get authorization to subscribe to it. > - a way to push back data, e.g. changed email addresses etc. to one of > these services > - users in control of their data. > > The latter might also be a problem of TOS/EULAs, as most providers =20 > right > now need or want quite broad licenses to use your data in whatever way > they want to. There are some discussions right now around the Facebook > TOS change and how people can be made aware of the restrictions they > face when joining a site. These are more social/legal problems though. > If some sort of Creative Commons like set of licenses comes out of =20 > that > it might get technical of course to attach them to data and move them > around. Groups active here are at DataPortability[6| and Project =20 > Liberty[7]. > > The good thing in general for a separate group would be to be able to > embrace more parties having the same problems like many social =20 > networks > and Open Stack supporters. That's esp. interesting as there already =20= > is a > lot of talk going on. > > My =80.02 > > -- Christian > > > [1] http://identitycommons.org/ > [2] http://oauth.net > [3] http://xrds-simple.net > [4] > = http://www.hueniverse.com/hueniverse/2009/01/discovery-on-my-mind-new-spec= ification-published.html > [5] = http://www.hueniverse.com/hueniverse/2009/02/redefining-discovery.html > [6] = http://wiki.dataportability.org/pages/viewpage.action?pageId=3D4490392 > [7] > = http://wiki.projectliberty.org/index.php/VolunteeredPersonalInformationSIG= > > >> >> >> On Feb 21, 2009, at 1:54 PM, Jon Watte wrote: >> >>> Dan Olivares wrote: >>>> At this point in time, are there any more proposals for the working >>>> group draft? Should we move on to establishing rough consensus and >>>> BOF? >>>> >>> >>> Here is a proposal for subjects for standardization and a general >>> understanding of what the "common ground" would be. I believe that >>> without standardizing at least all of these things, broad and useful >>> interoperability cannot be achieved: >>> >>> - User identity is provided by an identity provider, which may be =20= >>> the >>> "home" world of the user, or some other provider. Users should not >>> need identity tied to the specific world they want to visit. Some >>> worlds may choose to not accept certain specific credentials, just >>> like certain real-world stores may not accept Candian dollars for >>> payment. The market will work out a few major credential systems in >>> the end (such as OpenID, perhaps). As long as each system is =20 >>> accessed >>> uniformly, the specifics of the back end don't matter. >>> >>> - Geometry is based on regular meshes, possibly with LOD switches =20= >>> and >>> lower-resolution physics meshes/proxies/hulls. I understand that =20 >>> this >>> may be a sticking point for the SL-derived worlds (or do they =20 >>> actually >>> support arbitrary meshes as an option now? I haven't kept up.) >>> >>> - Texturing is based on a regular Phong model with various defined >>> texture maps (because HLSL vs GLSL vs some-other-SL are each of them >>> not suitable on their own). Turns out, once you have the possibility >>> of gloss maps, normal maps, emission maps, opacity maps, diffuse =20 >>> maps >>> and ambient maps, you have 90% of the "look" of any one technology, >>> which is about as good as you can hope for through interoperability. >>> >>> - Telemetry (entity movement) needs to be sent on a >>> position/orientation/velocity basis, with dead reckoning. Delta >>> compression and lower update rates can be used to keep bandwidth =20 >>> usage >>> in check. This is a big difference for OLIVE, because we are >>> input-synchronous, similar to City of Heroes or Age of Empires. >>> However, again, this is the common denominator and experience =20 >>> speaking. >>> >>> - Animating objects need to use a common, widespread interchange >>> format, using named animation clips and skeletal animation. Morph >>> deformation is likely too big a payload to make sense, at least in =20= >>> the >>> early stages. COLLADA is a good format for this, but there are other >>> possibilities (FBX, X3D and X come to mind). I think that making at >>> least one format required is a good idea, because that ensures a >>> minimum level of interoperability is always present. >>> >>> - Simulation and script execution for a given object needs to be =20 >>> done >>> on the "home" system for that object, because objects may be >>> constructed assuming wildly disparate execution environments (X3D =20= >>> with >>> JavaScript; Prims with SL Script, C++ with XML, Java with JSR 184, =20= >>> etc). >>> >>> - Objects need to be marked up with simple, well defined possible >>> interactions, so that a user interface can be generated on each =20 >>> client >>> based on those interactions. Interactions are typically "set this >>> property to this value" or "execute this command." Such interactions >>> need to be forwarded to the server that runs the object in question. >>> Similarly, specific interactions ("emote animation," "collision," >>> "damage," "two-party animation," "flight" etc) need to be defined. >>> >>> - Non-time-critical requests should go over HTTP and/or HTTPS, using >>> XML-RPC or a similarly well understood protocol. >>> >>> - Time-critical and high-bandwidth data (such as entity telemetry =20= >>> and >>> user inputs) should be sent using explicit (separate) schema, and >>> binary representation, for the same reason that we don't send >>> streaming video as XML, or mark each pixel with a color space =20 >>> identifier. >>> >>> Sincerely, >>> >>> Jon Watte >>> Forterra Systems >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > > --=20 > Christian Scholz Homepage: = http://comlounge.net > COM.lounge blog: = http://mrtopf.de/blog > Luetticher Strasse 10 Skype: =20 > HerrTopf > 52064 Aachen Video Blog: = http://comlounge.tv > Tel: +49 241 400 730 0 E-Mail = cs@comlounge.net > Fax: +49 241 979 00 850 IRC: MrTopf, =20 > Tao_T > > neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de) > new podcast: Data Without Borders (http://datawithoutborders.net) > From jwatte@gmail.com Sun Feb 22 10:34:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C8F3A68C4 for ; Sun, 22 Feb 2009 10:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kirKEVWlcrXy for ; Sun, 22 Feb 2009 10:34:49 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.235]) by core3.amsl.com (Postfix) with ESMTP id E67473A6848 for ; Sun, 22 Feb 2009 10:34:48 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id e34so1096122qbe.41 for ; Sun, 22 Feb 2009 10:35:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=U2Vs7Fd4JABAMnzYBoaSuA6ytxA8lrFq180+2PoTIsA=; b=AT385umtjjc4xo78D5iFW3XaT6hEs1xwLo0HzASyL28400lSpnX1tx9TkwZ27C+7OR IJF0H/WxRuJ7Znc0Mqi6esrlY6m9c0og5ulQzEqpYNKUHqXWel4FSI0bvttrHNHJqHRg sfIyARfPa8SVoRTu2l6lh2QOmVrcSDoqe3488= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=weYBwRzq2eX6GoI3fTSH87EV3oHGXe6M3R2jFKpJ1J53EY0eiY8cEd9rylp2CP00Ik 6P34LmeDQ3TpbnHP38uD8arL5+jdbVaXHoiP3EC14CBmBab8XJYuPGPUi25MBs6ZHOGg Nl83BpyrNX4dac8zUWaWV3+LmyDeQl7UBw1r8= Received: by 10.141.20.6 with SMTP id x6mr1615234rvi.159.1235327704002; Sun, 22 Feb 2009 10:35:04 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k41sm5415631rvb.6.2009.02.22.10.35.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 10:35:03 -0800 (PST) Message-ID: <49A19AD6.2020501@gmail.com> Date: Sun, 22 Feb 2009 10:35:02 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> <492298.73712.qm@web82607.mail.mud.yahoo.com> In-Reply-To: <492298.73712.qm@web82607.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 18:34:50 -0000 Charles Krinke wrote: > > As I understand the process, there is a revision to the draft proposal > which is on the secondlife wiki now at > https://wiki.secondlife.com/wiki/MMOX and it is the one labeled draft > #4. I also understand this "charter draft" does not mention LLSD or > OGP at all and in reading it, it seems reasonable. > You mean, apart from this part? October 2009 Publication of LLSD Draft as an Informational RFC It's right there, among the list of goals in the message linked to as "draft #4." Sincerely, jw From jwatte@gmail.com Sun Feb 22 10:39:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF913A696B for ; Sun, 22 Feb 2009 10:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3+Nm95dlmLY for ; Sun, 22 Feb 2009 10:39:22 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 96C353A6818 for ; Sun, 22 Feb 2009 10:39:22 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1522040rvb.49 for ; Sun, 22 Feb 2009 10:39:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=7hbpTyIuotzKZQBf68XL5s/k+zu2SECncgAU39Ep7dI=; b=pc8A7yY8SiQqi5j/lsca72BStYEf6AiDvWdMuvB2tMvsxOT4WnkcIv7IukbvoazJ6E br80Hf+PSYa0iW4nLn8hdCabEzaQBAgLwF8h4Ry3Vlzlhvb8B0swqQ18UPQ0c4pa0K5q KrIIilwfqNke4L5/MJC8Ye575ZJaiVLFLp0cs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=XRy/3NxI8Gt7x0/VcA44c9QCd63b8HPHNVS77mc4leLxEHhvqe0phGHO0yEG2EqF+R RLui+o8MxgEP/QODOUPJSf5P+gWc55WPwOpgmwkQzOwgUoUVj4PiZTgFLUJXiQ4D17J0 fO4oucEKvFAmfJyBse44q3oX8MJbKJkSrnCes= Received: by 10.140.226.14 with SMTP id y14mr1607809rvg.242.1235327978633; Sun, 22 Feb 2009 10:39:38 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k37sm12965974rvb.1.2009.02.22.10.39.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 10:39:38 -0800 (PST) Message-ID: <49A19BE9.2010604@gmail.com> Date: Sun, 22 Feb 2009 10:39:37 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke References: <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <49A08104.3020400@cox.net> <182040.52962.qm@web82605.mail.mud.yahoo.com> <49A08B23.7000003@cox.net> <49A099F9.9040809@gmail.com> <179791.99540.qm@web82603.mail.mud.yahoo.com> In-Reply-To: <179791.99540.qm@web82603.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lenglish5@cox.net, "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 18:39:23 -0000 Charles Krinke wrote: > I disagree. There is no reason for this to be either or. We certainly > can make an interop spec that contemplates "prims", "meshes" or other > geometric notions. > > As I see this situation evolving, there will be a number fields in > negotiating capabilities between a client and a server in teleporting > from one virtual world to another. Prims vs meshes are one. > Havoc/ODE/Other physics engines are another. Scripting engines are a > third. > > There will be a number of "world specific" capabilities that need to > be negotiated between the client and the server the client is > attempting to connect that will need capabilities fields. Why would a client connect to an unknown server? What actual benefit do you get from that? What would you do about user interface when connecting to a different system? How would you know to control an avatar at a different system from a client written for another system? How would you interoperate between two different systems that don't use the same basic object or simulation representation? I believe that a "universal client" does not actually solve any useful problems (it doesn't add any capability different from what you get by just installing multiple clients). It also is a lot of engineering, and locks system implementation into a restrictive/prescriptive model. If what you want to do is make sure that "second life" client can connect to "open sim" servers, and vice versa, then your proposal makes sense, but I don't believe that's a useful model of interoperability for the world at large. I think that level of interoperability should be specified in a forum specific for second life-derived technologies (such as the AWG, perhaps?) Sincerely, jw From jwatte@gmail.com Sun Feb 22 10:41:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369A63A68C4 for ; Sun, 22 Feb 2009 10:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0WF6XKWy0eh for ; Sun, 22 Feb 2009 10:41:17 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 642CB3A6818 for ; Sun, 22 Feb 2009 10:41:17 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1522407rvb.49 for ; Sun, 22 Feb 2009 10:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+iAKiIcJ3avKOSG9nkHRfoz5z7Ol48homvgl1ZRff/Q=; b=bWgqSlzfEE56uud0N5bBgsoQo+r2a6KP4HDLgQlczvYqrFNzwFdVrsfQ9zewJAV/dw vsLfktToUey3YhBE/h8I6uKuGIUlS62ORkioLLSnPqcGQqxcO7zl5nXdByaQ3SQJKZyR IZ4VsXA8/AHQnqsw44I7lp/8H1UJzH9E3USP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=k7IfzjqDP0BY+TIDcVj1DR7lrrpipH7zlFnIuBLQJYABQr6vhIYhvil/tnOK8HIYPm qe7gr0tWvrZyIqw01Qs9tlpLnsalLFcnGqxRitgv7AXj0BH1PLbhqWfc5nabEBxOYzLh 5Fy5dzbWh8vMCajYFA5WpQJDmJ360vJH5QKpE= Received: by 10.140.161.11 with SMTP id j11mr1629356rve.15.1235328093985; Sun, 22 Feb 2009 10:41:33 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k2sm11742913rvb.4.2009.02.22.10.41.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 10:41:33 -0800 (PST) Message-ID: <49A19C5C.10309@gmail.com> Date: Sun, 22 Feb 2009 10:41:32 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> <492298.73712.qm@web82607.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 18:41:18 -0000 Morgaine wrote: > Members of the AWG use this for group communication, as in the case of > the aforementioned MMOX links page that I maintain at > https://wiki.secondlife.com/wiki/MMOX. There is no Linden Lab > involvement in this, although of course they are welcome to improve > the page if they wish, as is everyone else. So you think that "becoming a Second Life resident" is not an unreasonable requirement for someone participating in an open standards effort? Sincerely, jw From jwatte@gmail.com Sun Feb 22 10:48:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67DD63A694A for ; Sun, 22 Feb 2009 10:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZArYMEtdaXa for ; Sun, 22 Feb 2009 10:48:37 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.153]) by core3.amsl.com (Postfix) with ESMTP id 4F9E83A681C for ; Sun, 22 Feb 2009 10:48:37 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so5725707poe.4 for ; Sun, 22 Feb 2009 10:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=7RalqdUnJT0KDg63nQ/b/T7j5d7fWWtQrrqHFmvzZAE=; b=uyeoUt68lRg/9BsmhpBepBIxfW5tM+uB5Irj7L4MckZ/lxiguBhGStyby7LRNFwBDH pKYL18Sjvcn9RDWzXtjou5JQ2IDuxXQgYu1+ZKzIUgYs79+rwnlCu4ZpajJvq86CVUJr JKo36NVgI1aVpXTFLvLxodikgIkOjFxjtuMu4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=RGYI3QP7ybgqDb9Wu7/KdT9frWA/UnkvDwKSu3En72vdUZRbMXLoXx7yTgX76QEmTg v44tU2B6LjhXrhDynZrT4HkJSa7fnfrkHnmDSbTT+qJLo1vh6JW2+gg1z9DsvYePX5e/ pwd4lpiOEQ6Qq09YN+jDXdF8Zu8IvF8XiO/LQ= Received: by 10.140.127.13 with SMTP id z13mr1628263rvc.30.1235328534050; Sun, 22 Feb 2009 10:48:54 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k41sm5427345rvb.6.2009.02.22.10.48.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 10:48:53 -0800 (PST) Message-ID: <49A19E14.1020005@gmail.com> Date: Sun, 22 Feb 2009 10:48:52 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kajikawa Jeremy References: <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <49A089D6.7020104@gmail.com> <1235267232.7560.210.camel@localhost> In-Reply-To: <1235267232.7560.210.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 18:48:38 -0000 Kajikawa Jeremy wrote: > or are we all getting into transfer of objects before the sytems have a > transfer of "presence" where one or more systems have a common > "presence"? > > What is an "object"? To me, the object is the platonic ideal of that object, typically as embodied in running code on a "server" somewhere (for p2p systems, that "server" is also a "peer"). There is one, authoritative master version of that object. Then, there is "object presentation," which includes things like meshes, animation, playing sound, location in 3D, available UI commands/interactions, etc. Part of "object presentation" is also how the object affects other objects around it; specifically things like collision meshes (collision meshes present the object to a physics system; render meshes presents the object to a display system, etc). My proposal is that we provide a way to standardize "object presentation," so that any system can present an object that's operating on another system. This means that the user sees a large amount of interoperability, no matter what the specific implementation details are of the system the user is interoperating with. It also means that objects operating on different systems can interact with each other (collide, for example), without needing to "transport" the actual object, only the presentation affects of the object. > Messaging and other comminucations functions I see as being mapped using > the existing Instant-Messenger/Relay-Chat/Mail systems... > Unfortunately, existing messaging protocols (like OSCAR or IRC or Jabber) and voice communication protocols (like SIP or H.320) do not provide for 3D localization of data, or tieing the data to specific 3D world entities. I believe this capability is actually quite important to the 3D world experience, and it would be a shame if that was lost through standardization. Perhaps something like SIP can be extended to provide the necessary cross reference, though -- we should definitely consider that! Sincerely, jw From cfk@pacbell.net Sun Feb 22 10:50:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2B3E3A69FD for ; Sun, 22 Feb 2009 10:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuaPQY9CXxAt for ; Sun, 22 Feb 2009 10:50:32 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id 77A063A696B for ; Sun, 22 Feb 2009 10:50:32 -0800 (PST) Received: (qmail 73375 invoked by uid 60001); 22 Feb 2009 18:50:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=rSrWnjoEpZS6uh6QPCebuiAJd8Ze9U1KeFAqiUONnQH8NLjCBSCZEwIXD9BdqNqSQX96EFjTQvgGdgziYbTFBOhjCVurK81Uabpik7Cxhp0I9tLP1x4o0wfhxHLD7DSVL9S/6W2S1PlyOdn/mGzInoPlm3uuE+eIlcbdIcamtUM=; X-YMail-OSG: JOk8qzUVM1mq5_9eFiWBtLxENwYTANZnObLUeLheR3WTxsbszQrC7xLUdsqzKBdQ48O.uJYsVeCxg0Udh6dgNKGyIcwvV4KyUiEa3n2w3zGcQyhL1fiFg0n5YiTCgXGZw3h6g75z5nnaOzHvbPwcJyVQQOf8_dX4P_XnxoaSWW4uEtj2OHp.CNPN6BUH_.9Hqq8SQWL7JY4nK48RLh9hKfLLafI- Received: from [67.120.11.69] by web82602.mail.mud.yahoo.com via HTTP; Sun, 22 Feb 2009 10:50:48 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <647098.76086.qm@web82602.mail.mud.yahoo.com> <719A6D8A-1198-4A96-804B-5803165C5510@lindenlab.com> <499DDEED.2000109@gmail.com> <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <49A08104.3020400@cox.net> <182040.52962.qm@web82605.mail.mud.yahoo.com> <49A08B23.7000003@cox.net> <49A099F9.9040809@gmail.com> <179791.99540.qm@web82603.mail.mud.yahoo.com> <49A19BE9.2010604@gmail.com> Date: Sun, 22 Feb 2009 10:50:48 -0800 (PST) From: Charles Krinke To: Jon Watte MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1254419229-1235328648=:70613" Message-ID: <946084.70613.qm@web82602.mail.mud.yahoo.com> Cc: lenglish5@cox.net, "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 18:50:33 -0000 --0-1254419229-1235328648=:70613 Content-Type: text/plain; charset=us-ascii Well, actually, OpenSim and others are moving forward regardless of what we say here. Last night, in r8569, a new set of logic was committed to OpenSim for MXP, that is the MetaverseXchangeProtocol. So, adding ModRex & MXP with others working on adding things like VastPark is already deploying multiple clients connecting to a single sim server. I think from our viewpoint here, moving to get our group charter with a "rough consensus" and then agreeing on a protocol will help us participate rather then be spectators. Charles ________________________________ From: Jon Watte To: Charles Krinke Cc: lenglish5@cox.net; "mmox@ietf.org" Sent: Sunday, February 22, 2009 10:39:37 AM Subject: Re: [mmox] Learning from the past; focusing on the future Charles Krinke wrote: > I disagree. There is no reason for this to be either or. We certainly can make an interop spec that contemplates "prims", "meshes" or other geometric notions. > > As I see this situation evolving, there will be a number fields in negotiating capabilities between a client and a server in teleporting from one virtual world to another. Prims vs meshes are one. Havoc/ODE/Other physics engines are another. Scripting engines are a third. > > There will be a number of "world specific" capabilities that need to be negotiated between the client and the server the client is attempting to connect that will need capabilities fields. Why would a client connect to an unknown server? What actual benefit do you get from that? What would you do about user interface when connecting to a different system? How would you know to control an avatar at a different system from a client written for another system? How would you interoperate between two different systems that don't use the same basic object or simulation representation? I believe that a "universal client" does not actually solve any useful problems (it doesn't add any capability different from what you get by just installing multiple clients). It also is a lot of engineering, and locks system implementation into a restrictive/prescriptive model. If what you want to do is make sure that "second life" client can connect to "open sim" servers, and vice versa, then your proposal makes sense, but I don't believe that's a useful model of interoperability for the world at large. I think that level of interoperability should be specified in a forum specific for second life-derived technologies (such as the AWG, perhaps?) Sincerely, jw --0-1254419229-1235328648=:70613 Content-Type: text/html; charset=us-ascii
Well, actually, OpenSim and others are moving forward regardless of what we say here.

Last night, in r8569, a new set of logic was committed to OpenSim for MXP, that is the MetaverseXchangeProtocol.

So, adding ModRex & MXP with others working on adding things like VastPark is already deploying multiple clients connecting to a single sim server.

I think from our viewpoint here, moving to get our group charter with a "rough consensus" and then agreeing on a protocol will help us participate rather then be spectators.

Charles

From: Jon Watte <jwatte@gmail.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: lenglish5@cox.net; "mmox@ietf.org" <mmox@ietf.org>
Sent: Sunday, February 22, 2009 10:39:37 AM
Subject: Re: [mmox] Learning from the past; focusing on the future

Charles Krinke wrote:
> I disagree. There is no reason for this to be either or. We certainly can make an interop spec that contemplates "prims", "meshes" or other geometric notions.
>
> As I see this situation evolving, there will be a number fields in negotiating capabilities between a client and a server in teleporting from one virtual world to another. Prims vs meshes are one. Havoc/ODE/Other physics engines are another. Scripting engines are a third.
>
> There will be a number of "world specific" capabilities that need to be negotiated between the client and the server the client is attempting to connect that will need capabilities fields.

Why would a client connect to an unknown server? What actual benefit do you get from that?
What would you do about user interface when connecting to a different system?
How would you know to control an avatar at a different system from a client written for another system?
How would you interoperate between two different systems that don't use the same basic object or simulation representation?

I believe that a "universal client" does not actually solve any useful problems (it doesn't add any capability different from what you get by just installing multiple clients). It also is a lot of engineering, and locks system implementation into a restrictive/prescriptive model.

If what you want to do is make sure that "second life" client can connect to "open sim" servers, and vice versa, then your proposal makes sense, but I don't believe that's a useful model of interoperability for the world at large. I think that level of interoperability should be specified in a forum specific for second life-derived technologies (such as the AWG, perhaps?)

Sincerely,

jw

--0-1254419229-1235328648=:70613-- From jwatte@gmail.com Sun Feb 22 10:53:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188F03A699E for ; Sun, 22 Feb 2009 10:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx-Jq7iY3feB for ; Sun, 22 Feb 2009 10:53:54 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id ED1DE3A6998 for ; Sun, 22 Feb 2009 10:52:36 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1524622rvb.49 for ; Sun, 22 Feb 2009 10:52:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=r2N1OtiWRmf/11P9yvVYfvyQSn65NTI/rR6qphUqjRI=; b=sbAvy0Ov3j9chQ6AdNfJGZIRH304qImKte/lyZqz5QEOpYF7flC7dYHTVyaTXxPmk3 HU8fFQZL4RDONEMW1oo90mSIwVtZgEUr/kdGc/nnHtR3zVUFl3EjKT3y5v5Ks1E37gNh tT+8GS9j6HS1ayx6980bJrKxXBK0SDXZDZcLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=QOtBd/1sjG3uWlCrm/oZr44mKYCIs8DxvhgL9d3Iu7Izf73y1U/dEEeT4PFTcABFei msbfYnYhHmCvyWSs2PBBe+ETwKfHvV5b0rEkio03AMFJk3IWbsCbXr3+wPIG6CZExse2 ev7FQgjYvLbQUuRIuA2/d6qz7hji3qSLGrmlk= Received: by 10.141.168.2 with SMTP id v2mr1616199rvo.207.1235328774053; Sun, 22 Feb 2009 10:52:54 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b39sm5416915rvf.9.2009.02.22.10.52.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 10:52:53 -0800 (PST) Message-ID: <49A19F04.3070704@gmail.com> Date: Sun, 22 Feb 2009 10:52:52 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <49A08104.3020400@cox.net> <182040.52962.qm@web82605.mail.mud.yahoo.com> <49A08B23.7000003@cox.net> <49A099F9.9040809@gmail.com> <179791.99540.qm@web82603.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , lenglish5@cox.net Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 18:53:55 -0000 Morgaine wrote: > > I believe that we should focus on defining an extensible core protocol > that allows payloads of all of these types, and others, to be > carried. That's part of our general "mechanism, not policy" guideline. I am explicitly requesting that we define enough policy that we can guarantee interoperability between two systems if both systems claim to implement the protocol in question. I think that any kind of interoperability less than that would not be of sufficient value to be called an open standard. Adding the capability of negotiating richer/better/newer formats on top of the defined base is a good thing, but there needs to be a defined base. Some examples: "If you support displayable geometry, you must support COLLADA." "If you support voice chat, you must support GSM-11." "If you support distributed authentication, you must support OpenID." "If you support moving entities, you must support position, orientation, linear velocity and angular velocity with dead reckoning." Thus, someone could add COLLADA, GSM and OpenID capabilities to their system, and they would be guaranteed to have a useful level of interoperability. Otherwise, the interoperability standard is "interoperable" only in name. Sincerely, jw From jwatte@gmail.com Sun Feb 22 11:02:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B903A6953 for ; Sun, 22 Feb 2009 11:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DCoyw1dKusp for ; Sun, 22 Feb 2009 11:02:35 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id EF8613A688B for ; Sun, 22 Feb 2009 11:02:34 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1526541rvb.49 for ; Sun, 22 Feb 2009 11:02:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=647TVCKxUucJKzepN6/FmeR1nBAqUoxhEpZN2jnlhNQ=; b=vUh0HO7r05WaSshGGJbx+sumUGoeOhWagUeyECIUNssOTW/18sArLMtwWB1KhT2xPW 6ScYm8M9PVMnLJqX8tAbJ6QfkCvkSpArTvkL08BbGpbXv0BgQkdti3WKUHqah9QvcKR4 9mbpTamTDFwfInkem8u49mSUwPq8GaPdiOPUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rOVBi9nvOvJQvz8Cq7Hiy35geallD8X1NWydWHHtamb5XbXUUkP7FDuUst8fM37+g3 vXesicquAQGFQrXhfLtHPF6a4mP7gjFJXJgDCi9mQbY8VbA1lyj3qG2R5yd+Rzfqqon8 N3jSW+acjPhrVs9boayBt885bIwKyVftMXmXI= Received: by 10.140.201.6 with SMTP id y6mr1628620rvf.62.1235329370703; Sun, 22 Feb 2009 11:02:50 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k37sm4161933rvb.1.2009.02.22.11.02.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 11:02:49 -0800 (PST) Message-ID: <49A1A158.3020605@gmail.com> Date: Sun, 22 Feb 2009 11:02:48 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> In-Reply-To: <697430.23835.qm@web82605.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 19:02:36 -0000 Charles Krinke wrote: > If we do our job right, then we will eventually expect that any 3D > client can expect to connect to any 3D server, negotiate a > pre-described set of capabilities and services and act in an analagous > fashion that a web browser does now. > I think this is a mistake. Interactive content is very different from web content. Consider, instead, e-mail -- An Outlook client cannot connect to a Lotus SameTime server, but the Outlook client can send messages to a Lotus SameTime client through interoperability between the mail servers. The difference is in interactivity. Interactivity changes the game. Interactivity requires constantly running code, which is very different from a web server/browser system. Something that gets a little closer to that model is Web 2.0, but I think it's still a halting comparison. If you want to be able to "connect to any server from any client," then you could do that today. Define the client as being Internet Explorer with ActiveX controls, and define the server to be Apache, and you're done. *We can do that today*. However, nobody is doing it, because it doesn't actually provide any additional value. I believe it's crucially important that interoperability provides additional value to users -- it lets users do important new things that they cannot conceivably do using the existing paradigm. "Connecting to another server" falls very low on that scale. Sincerely, jw From jwatte@gmail.com Sun Feb 22 11:06:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 714773A6AB0 for ; Sun, 22 Feb 2009 11:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kg9MUm4qM2Ce for ; Sun, 22 Feb 2009 11:06:06 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id C33CE3A6818 for ; Sun, 22 Feb 2009 11:06:06 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so1555775rvb.5 for ; Sun, 22 Feb 2009 11:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=uR3DSADxB1MATPUnRos9wKqzur0W3FQeJKvBgSYjmAM=; b=GUlBO+rSEIMLZa5bz3+cMdOgsLm3Ja2K+z5NHU5pRFm6d4Pt6LeNBwFPcU59z8ExpW qLISF74Au//t5mZyTXf+BZ/ilios13cXP0CzsNVjEpBKrd2Btvdf7vkEtLpGUTVNxKuB lBtmZT+9uoMJw5lsyMfcEf7OXgCm/aAvU9f8M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qpWLLC8FaE+xj3wN1MMstC8mJRSVExcnVRd6/nuUzBc1TaYrva7O8UdISgQgDN/EnB GYjXQzZHyCp8BeOxFfLidmp5EgUupEpCjZBavU9SLWn6BAYhUBuouWNZVGQDZvvJqgTn u572YmFa6bnqdUNybKvDHzF939ungJ2VZHNjw= Received: by 10.141.155.15 with SMTP id h15mr1620332rvo.220.1235329582608; Sun, 22 Feb 2009 11:06:22 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b8sm11762004rvf.8.2009.02.22.11.06.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 11:06:22 -0800 (PST) Message-ID: <49A1A22D.3080100@gmail.com> Date: Sun, 22 Feb 2009 11:06:21 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> In-Reply-To: <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 19:06:07 -0000 Gareth Nelson wrote: > I propose HTTP for assets, with a standard base URL for each region > domain and agent domain, and a basic description of the avatar as > first step in defining the real "meat" of the 3D stuff. > Why is an avatar special? In fact, I find the idea of putting "rezzing" avatars into OGP very second life centric. Bringing an avatar to life is a function internal to the virtual world service provider, not something that needs to, itself, be interoperable. The question is: how and when does that avatar get presented to other systems? Btw: what does "rezzing" stand for? "Ressurecting"? In general object parlance, I think "instantiating" would be better, perhaps. Sincerely, jw From gareth@litesim.com Sun Feb 22 11:09:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B58A3A6AC4 for ; Sun, 22 Feb 2009 11:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlvWUel8h65m for ; Sun, 22 Feb 2009 11:09:18 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id CE1EC3A6AB9 for ; Sun, 22 Feb 2009 11:09:18 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1527852rvb.49 for ; Sun, 22 Feb 2009 11:09:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.28.4 with SMTP id f4mr1631791rvj.37.1235329775062; Sun, 22 Feb 2009 11:09:35 -0800 (PST) In-Reply-To: <49A1A22D.3080100@gmail.com> References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> <49A1A22D.3080100@gmail.com> Date: Sun, 22 Feb 2009 19:09:35 +0000 Message-ID: <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 19:09:19 -0000 Well, we need a description of the avatar itself, or what do we show to other systems? Note I didn't mention rezzing an avatar :) On Sun, Feb 22, 2009 at 7:06 PM, Jon Watte wrote: > Gareth Nelson wrote: >> >> I propose HTTP for assets, with a standard base URL for each region >> domain and agent domain, and a basic description of the avatar as >> first step in defining the real "meat" of the 3D stuff. >> > > Why is an avatar special? > > In fact, I find the idea of putting "rezzing" avatars into OGP very second > life centric. Bringing an avatar to life is a function internal to the > virtual world service provider, not something that needs to, itself, be > interoperable. The question is: how and when does that avatar get presented > to other systems? > > Btw: what does "rezzing" stand for? "Ressurecting"? In general object > parlance, I think "instantiating" would be better, perhaps. > > Sincerely, > > jw > > From gareth@litesim.com Sun Feb 22 11:13:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9213A68AC for ; Sun, 22 Feb 2009 11:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1tQQxFtNA-2 for ; Sun, 22 Feb 2009 11:13:25 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 6B6D13A6823 for ; Sun, 22 Feb 2009 11:13:25 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1528648rvb.49 for ; Sun, 22 Feb 2009 11:13:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.210.2 with SMTP id m2mr1617899rvq.284.1235330022517; Sun, 22 Feb 2009 11:13:42 -0800 (PST) In-Reply-To: <49A1A158.3020605@gmail.com> References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <49A1A158.3020605@gmail.com> Date: Sun, 22 Feb 2009 19:13:42 +0000 Message-ID: <61dbdd7d0902221113l7309d7abk1996ed04640a4b7a@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 19:13:26 -0000 > I think this is a mistake. Interactive content is very different from web > content. Consider, instead, e-mail -- An Outlook client cannot connect to a > Lotus SameTime server, but the Outlook client can send messages to a Lotus > SameTime client through interoperability between the mail servers. I can take my SMTP and POP3 compatible mail client to any ISP, some ISPs might offer extra value (spam filtering, webmail, mailing lists, etc), but the basics are the same. > The difference is in interactivity. Interactivity changes the game. > Interactivity requires constantly running code, which is very different from > a web server/browser system. Something that gets a little closer to that > model is Web 2.0, but I think it's still a halting comparison. If you want > to be able to "connect to any server from any client," then you could do > that today. Define the client as being Internet Explorer with ActiveX > controls, and define the server to be Apache, and you're done. *We can do > that today*. However, nobody is doing it, because it doesn't actually > provide any additional value. Any web browser that supports HTTP and HTML can connect to any httpd. Everyone does this today :) The additional value is obvious - any device which implements these 2 standards can be a web browser or a web server. I can browse on my PC running GNU/Linux or my Sony PSP. I can even post to forums with both these devices and let windows 98 users read my posts. > I believe it's crucially important that interoperability provides additional > value to users -- it lets users do important new things that they cannot > conceivably do using the existing paradigm. "Connecting to another server" > falls very low on that scale. Look at developing the standard protocol as being the enabler, a means to the end, rather than an end in itself From gareth@litesim.com Sun Feb 22 11:14:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 279BD3A6915 for ; Sun, 22 Feb 2009 11:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRzQuWvONeb2 for ; Sun, 22 Feb 2009 11:14:55 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 636D63A68AC for ; Sun, 22 Feb 2009 11:14:55 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1528972rvb.49 for ; Sun, 22 Feb 2009 11:15:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.48.6 with SMTP id a6mr1635626rvk.36.1235330112229; Sun, 22 Feb 2009 11:15:12 -0800 (PST) In-Reply-To: References: <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> Date: Sun, 22 Feb 2009 19:15:12 +0000 Message-ID: <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> From: Gareth Nelson To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 19:14:56 -0000 Just to nitpick, meshes and LCCs do work well together, just provide different LODs :) On Sat, Feb 21, 2009 at 8:18 PM, Morgaine wrote: > > > On Sat, Feb 21, 2009 at 7:02 PM, Jon Watte wrote: >> >> Personally, I believe that regular meshes with physics proxies are that >> minimum profile, because that most closely matches how most if not all of >> the distributed simulations in the world do things. > > > I'm afraid we have to do better than that. There is huge interest in what > we call Limited Capability Clients (LCCs), which are typically gadget-type > devices such as cellphones or PDAs used as virtual world clients, but they > could in principle be absolutely anything, even scripted objects within a > world itself. These tiny clients only pick those parts of a virtual world > service that they need and no more --- indeed, quite often they could not > cope with more. > > Support for such LCCs is important, both for flexibility and for > accessibility. Typical use cases for LCCs are audio-only clients for > attending live concerts in-world without needing visual presence, or braille > clients for attending in-world textual lectures. LCCs with hardware able to > display 3D visuals may choose to restrict download to only certain classes > of object to avoid overload (or just to save bandwidth costs), and disabling > meshes can easily be forseen as a requirement. > > So no, there is no minimum profile. This is one reason why LL/AWG took a > capability-based approach to resource access, potentially allowing clients > to pick and choose what is sent to them, although that work has not borne > fruit yet. In our work here, we will have to take the needs of LCCs into > account as well. > > Morgaine. > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From dcolivares@gmail.com Sun Feb 22 11:30:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 916183A696F for ; Sun, 22 Feb 2009 11:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peHQ4vS7JLKq for ; Sun, 22 Feb 2009 11:30:30 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.191]) by core3.amsl.com (Postfix) with ESMTP id 48C583A691D for ; Sun, 22 Feb 2009 11:30:29 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w9so1521834mue.9 for ; Sun, 22 Feb 2009 11:30:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1UIh1ia2ac/SEyY709669lObDG/uZ56rQFJpo1Nb+Kc=; b=Z/+Y1jNk8twZjQkV9rM9l4MY1lF6mIZl6CQeB6i+i9y8mNbdKFSXHzewqXtYq1GcmP n89emuoeUnZiwLXqKlQ7o4CjoTL4ChZFKwJm3DzhobFscNQjtDGSn7HZOnVEbOiDiLB3 Ant7409v4XQqiGzS03AT2Jh0gIWo82N1h+7EY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hB7dpL/su8r/kgXPWE4qpCkue6QuIWRZK/EaL1JwJT3u6kf6bIx8pD0+OzzyO0hyty 6tVL4bi8h8lyS2DQZ1U/EwyE4bihGx/cA7+s76/hGiYosh3Kka2e0mZ9eG8ePUgZ26eF 8cONTiQ6Qq3XnIyvCgh4hSEE7ZNFR6wRKaxZg= MIME-Version: 1.0 Received: by 10.103.178.17 with SMTP id f17mr2906994mup.45.1235331044255; Sun, 22 Feb 2009 11:30:44 -0800 (PST) In-Reply-To: <562887.12996.qm@web82607.mail.mud.yahoo.com> References: <562887.12996.qm@web82607.mail.mud.yahoo.com> Date: Sun, 22 Feb 2009 14:30:44 -0500 Message-ID: From: Dan Olivares To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 19:30:34 -0000 I'm reaching here, but I think Meadhbh might be referring to it's reliance on CICP to which, according to the creator in an article posted on slashdot, there's a provisional patent application filed. It seems that he is intending it to be public domain, but, the thought of patents scares a lot of people. Ref: http://ask.slashdot.org/article.pl?no_d2=1&sid=09/02/04/1934229 Best Regards Dan On Sun, Feb 22, 2009 at 11:19 AM, Charles Krinke wrote: > Dear Meadhbh: > > Can you help Tommi (and myself) understand what you mean? Was it > inappropriate to make the MXP post to this list? I do not understand what > the context is. > > Charles > > ________________________________ > From: Meadhbh Hamrick (Infinity) > To: Tommi Laukkanen > Cc: mmox@ietf.org > Sent: Sunday, February 22, 2009 1:03:05 AM > Subject: Re: [mmox] Other NVE protocol specification efforts > > tommi.. did you read the IPR disclosure rules? > On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen wrote: > > Hello > > I have been participating in an open source effort to specify a networked > virtual environment protocol. Although Metaverse Exchange Protocol (MXP) is > covering only part of the scope here I thought it might be interesting. > > MXP collects some good ideas to coherent theoretical model (Bubble Cloud) > and proposes working engineering solution. One of the MXP over UDP key > concepts is to have a minimal set of UDP messages for connectivity, > transport and distributed virtual environment scene graph synchronization. > All application specific information is transmitted as payload over the UDP > messages encoded in MXMP format. Another key concept is to multiplex all the > communication through one UDP port to simplify the session handling and > network connectivity. > > Working C# prototype exists which demonstrates the reference implementation. > > I believe that MXP is a good read currently for people interested in NVE > field. You can find the specification wiki from here: > > http://go-mxp.org > > best regards, > Tommi Laukkanen > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From cfk@pacbell.net Sun Feb 22 11:43:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FCEC3A6A71 for ; Sun, 22 Feb 2009 11:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8p2q6o7+BzS for ; Sun, 22 Feb 2009 11:43:20 -0800 (PST) Received: from web82602.mail.mud.yahoo.com (web82602.mail.mud.yahoo.com [68.142.201.119]) by core3.amsl.com (Postfix) with SMTP id E629E3A699E for ; Sun, 22 Feb 2009 11:43:19 -0800 (PST) Received: (qmail 16029 invoked by uid 60001); 22 Feb 2009 19:43:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=XFtPnSrWdU64rOHCt6PWGriPofZhLhiIlkCTUnehYDhcUMCYbpqydY/VrTu5R+nKi/LSZScDmbM/JHIkHk5QHc6F6nOt9YwPmFesCGa1/XAWcUgCwvGdAJ6BjTzPuaItrTlA8q4/oKWmG6WjQk29rosj8j+WdQEiorGoVcG6gEc=; X-YMail-OSG: 8OiJENwVM1kkRatJHGTMLS8wziSub8cEyZi1yAgD6julosMX5TWPX8.PolyUEwbrk2JYcuZo5j_oELkCoUkYp21RzRKMb9h3iBmYqPibOeRKCBNEUcSWL5Du8LJo6TM3aVejzdiOAtIB2DsM3j3uBhGwSYP_diTUbcqpEebJXWImItJXZaIFRqJdr1qHiFJiA.P1.wpFgfTBGZWKaiIpzYUKtSM- Received: from [67.120.11.69] by web82602.mail.mud.yahoo.com via HTTP; Sun, 22 Feb 2009 11:43:36 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <562887.12996.qm@web82607.mail.mud.yahoo.com> Date: Sun, 22 Feb 2009 11:43:36 -0800 (PST) From: Charles Krinke To: Dan Olivares MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-130098810-1235331816=:15324" Message-ID: <372016.15324.qm@web82602.mail.mud.yahoo.com> Cc: mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 19:43:21 -0000 --0-130098810-1235331816=:15324 Content-Type: text/plain; charset=us-ascii I understand, Dan. Mostly I was looking for Meadhbh (Infinity's) view as the co-chair of the working group. Charles ________________________________ From: Dan Olivares To: Charles Krinke Cc: mmox@ietf.org Sent: Sunday, February 22, 2009 11:30:44 AM Subject: Re: [mmox] Other NVE protocol specification efforts I'm reaching here, but I think Meadhbh might be referring to it's reliance on CICP to which, according to the creator in an article posted on slashdot, there's a provisional patent application filed. It seems that he is intending it to be public domain, but, the thought of patents scares a lot of people. Ref: http://ask.slashdot.org/article.pl?no_d2=1&sid=09/02/04/1934229 Best Regards Dan On Sun, Feb 22, 2009 at 11:19 AM, Charles Krinke wrote: > Dear Meadhbh: > > Can you help Tommi (and myself) understand what you mean? Was it > inappropriate to make the MXP post to this list? I do not understand what > the context is. > > Charles > > ________________________________ > From: Meadhbh Hamrick (Infinity) > To: Tommi Laukkanen > Cc: mmox@ietf.org > Sent: Sunday, February 22, 2009 1:03:05 AM > Subject: Re: [mmox] Other NVE protocol specification efforts > > tommi.. did you read the IPR disclosure rules? > On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen wrote: > > Hello > > I have been participating in an open source effort to specify a networked > virtual environment protocol. Although Metaverse Exchange Protocol (MXP) is > covering only part of the scope here I thought it might be interesting. > > MXP collects some good ideas to coherent theoretical model (Bubble Cloud) > and proposes working engineering solution. One of the MXP over UDP key > concepts is to have a minimal set of UDP messages for connectivity, > transport and distributed virtual environment scene graph synchronization. > All application specific information is transmitted as payload over the UDP > messages encoded in MXMP format. Another key concept is to multiplex all the > communication through one UDP port to simplify the session handling and > network connectivity. > > Working C# prototype exists which demonstrates the reference implementation. > > I believe that MXP is a good read currently for people interested in NVE > field. You can find the specification wiki from here: > > http://go-mxp.org > > best regards, > Tommi Laukkanen > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --0-130098810-1235331816=:15324 Content-Type: text/html; charset=us-ascii
I understand, Dan. Mostly I was looking for Meadhbh (Infinity's) view as the co-chair of the working group.

Charles

From: Dan Olivares <dcolivares@gmail.com>
To: Charles Krinke <cfk@pacbell.net>
Cc: mmox@ietf.org
Sent: Sunday, February 22, 2009 11:30:44 AM
Subject: Re: [mmox] Other NVE protocol specification efforts

I'm reaching here, but I think Meadhbh might be referring to it's
reliance on CICP to which, according to the creator in an article
posted on slashdot, there's a provisional patent application filed.
It seems that he is intending it to be public domain, but, the thought
of patents scares a lot of people. Ref:
http://ask.slashdot.org/article.pl?no_d2=1&sid=09/02/04/1934229

Best Regards

Dan

On Sun, Feb 22, 2009 at 11:19 AM, Charles Krinke <cfk@pacbell.net> wrote:
> Dear Meadhbh:
>
> Can you help Tommi (and myself) understand what you mean? Was it
> inappropriate to make the MXP post to this list? I do not understand what
> the context is.
>
> Charles
>
> ________________________________
> From: Meadhbh Hamrick (Infinity) <infinity@lindenlab.com>
> To: Tommi Laukkanen <tommi.s.e.laukkanen@gmail.com>
> Cc: mmox@ietf.org
> Sent: Sunday, February 22, 2009 1:03:05 AM
> Subject: Re: [mmox] Other NVE protocol specification efforts
>
> tommi.. did you read the IPR disclosure rules?
> On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen wrote:
>
> Hello
>
> I have been participating in an open source effort to specify a networked
> virtual environment protocol. Although Metaverse Exchange Protocol (MXP) is
> covering only part of the scope here I thought it might be interesting.
>
> MXP collects some good ideas to coherent theoretical model (Bubble Cloud)
> and proposes working engineering solution. One of the MXP over UDP key
> concepts is to have a minimal set of UDP messages for connectivity,
> transport and distributed virtual environment scene graph synchronization.
> All application specific information is transmitted as payload over the UDP
> messages encoded in MXMP format. Another key concept is to multiplex all the
> communication through one UDP port to simplify the session handling and
> network connectivity.
>
> Working C# prototype exists which demonstrates the reference implementation.
>
> I believe that MXP is a good read currently for people interested in NVE
> field. You can find the specification wiki from here:
>
> http://go-mxp.org
>
> best regards,
> Tommi Laukkanen
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
>
--0-130098810-1235331816=:15324-- From dcolivares@gmail.com Sun Feb 22 12:00:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1921128C106 for ; Sun, 22 Feb 2009 12:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks93RQxxbkSb for ; Sun, 22 Feb 2009 12:00:09 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 6660B28C1CD for ; Sun, 22 Feb 2009 12:00:04 -0800 (PST) Received: by fxm11 with SMTP id 11so1167764fxm.13 for ; Sun, 22 Feb 2009 12:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kiVRR9bzDObq+7mbpVif664p8p47YK+xKtR1tfHX53g=; b=k713ah8IINMOwg0EZMgwNPouBTid3IE2fPV/tN6SY4wlqS90Aqs637k9/JmQA+FWSo kIx8hsIHiq0F7q+hrByEdgkfFwqYfHqnYNj5bhc+jHg8mSwxrd2jycqjmHlyG6zpInW1 HETryrYDqO6YeXeakDLdGgr9Z9z/rRGLHADgY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=i2982kAQuKCuzRk18Y7EiIyZ33uBY6POPcptoDxWmUAPUO19h/f1JXx3i1gQx0s1pl XMtqE6TMmVCT5m8Fj3vpi7W5U6YdLDu6/hHIb0Zn4PPusKqMNmq6DU5Vh7asam6kq5CX sd9BHX4jJjf+DLp6kT4OicAzIeDH2qHcoiAZY= MIME-Version: 1.0 Received: by 10.103.172.9 with SMTP id z9mr2918399muo.39.1235332818435; Sun, 22 Feb 2009 12:00:18 -0800 (PST) In-Reply-To: <372016.15324.qm@web82602.mail.mud.yahoo.com> References: <562887.12996.qm@web82607.mail.mud.yahoo.com> <372016.15324.qm@web82602.mail.mud.yahoo.com> Date: Sun, 22 Feb 2009 15:00:18 -0500 Message-ID: From: Dan Olivares To: Tommi Laukkanen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:00:10 -0000 Tommil For more information about the IETF IPR Disclosure policy, please read https://datatracker.ietf.org/ipr/about/ Best Regards Dan On Sun, Feb 22, 2009 at 2:43 PM, Charles Krinke wrote: > I understand, Dan. Mostly I was looking for Meadhbh (Infinity's) view as the > co-chair of the working group. > > Charles > > ________________________________ > From: Dan Olivares > To: Charles Krinke > Cc: mmox@ietf.org > Sent: Sunday, February 22, 2009 11:30:44 AM > Subject: Re: [mmox] Other NVE protocol specification efforts > > I'm reaching here, but I think Meadhbh might be referring to it's > reliance on CICP to which, according to the creator in an article > posted on slashdot, there's a provisional patent application filed. > It seems that he is intending it to be public domain, but, the thought > of patents scares a lot of people. Ref: > http://ask.slashdot.org/article.pl?no_d2=1&sid=09/02/04/1934229 > > Best Regards > > Dan > > On Sun, Feb 22, 2009 at 11:19 AM, Charles Krinke wrote: >> Dear Meadhbh: >> >> Can you help Tommi (and myself) understand what you mean? Was it >> inappropriate to make the MXP post to this list? I do not understand what >> the context is. >> >> Charles >> >> ________________________________ >> From: Meadhbh Hamrick (Infinity) >> To: Tommi Laukkanen >> Cc: mmox@ietf.org >> Sent: Sunday, February 22, 2009 1:03:05 AM >> Subject: Re: [mmox] Other NVE protocol specification efforts >> >> tommi.. did you read the IPR disclosure rules? >> On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen wrote: >> >> Hello >> >> I have been participating in an open source effort to specify a networked >> virtual environment protocol. Although Metaverse Exchange Protocol (MXP) >> is >> covering only part of the scope here I thought it might be interesting. >> >> MXP collects some good ideas to coherent theoretical model (Bubble Cloud) >> and proposes working engineering solution. One of the MXP over UDP key >> concepts is to have a minimal set of UDP messages for connectivity, >> transport and distributed virtual environment scene graph synchronization. >> All application specific information is transmitted as payload over the >> UDP >> messages encoded in MXMP format. Another key concept is to multiplex all >> the >> communication through one UDP port to simplify the session handling and >> network connectivity. >> >> Working C# prototype exists which demonstrates the reference >> implementation. >> >> I believe that MXP is a good read currently for people interested in NVE >> field. You can find the specification wiki from here: >> >> http://go-mxp.org >> >> best regards, >> Tommi Laukkanen >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > From tommi.s.e.laukkanen@gmail.com Sun Feb 22 12:04:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24E983A6AA7 for ; Sun, 22 Feb 2009 12:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1y9C4xTUIAg8 for ; Sun, 22 Feb 2009 12:04:00 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id CBEA93A68C5 for ; Sun, 22 Feb 2009 12:02:12 -0800 (PST) Received: by bwz5 with SMTP id 5so4167583bwz.13 for ; Sun, 22 Feb 2009 12:02:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OaFskapYdmo7LOaj1yeQJTyW4oL0AljH3NgERj15T0s=; b=Eopl0F3BhKgbrB7H7GZVPEzyF9Js0GSH7w8+GIEOz4w2mLWqYWUhLTRJZccdF+QVYJ 1bqaWqrNyHxFrIi3x6XLRd3Q6kRLSJFPNPzVnWkcMpZLb+R2Sey4wc5bMBL5mDSaMqsD U9g9yTYAiap1a6ihQKjylOt+mrk7Ej5PyR4Bk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ql6T7/AJ8Nz3KNoWRPCUH5r4mrw9+tDF/qpypfraMVBGFqRONSgpAtqF6RfErslI8Z zX3Ty9Hg/Kg1uJ6CpsdDEmSfmxfMLZ82YtSwwJvNrc+4BaUcpD9EIsJQMKJ0XK8ja47M 4q+hOnfNzzvyiJxsBPOOymv7lJQP+Lm8Qaed0= MIME-Version: 1.0 Received: by 10.181.145.7 with SMTP id x7mr1225286bkn.96.1235332945929; Sun, 22 Feb 2009 12:02:25 -0800 (PST) In-Reply-To: References: <562887.12996.qm@web82607.mail.mud.yahoo.com> Date: Sun, 22 Feb 2009 22:02:25 +0200 Message-ID: From: Tommi Laukkanen To: Dan Olivares Content-Type: multipart/alternative; boundary=0016e65097fe6be4f50463875dde Cc: mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:04:01 -0000 --0016e65097fe6be4f50463875dde Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello I can very well understand patent concerns. All our MXP work has been licensed under Apache 2.0 License which states the following about patents: 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. Here is Bens recent blog post about his patent application which he made for CICP before our collaboration started: http://www.cybertechnews.org/?p=765 We are only reusing ideas and design principles from CICP. No algorithms, message structures, message sequences or the kind has been copied. The reference implementation has been made by me alone and I have not seen any CICP code. For anyone still feeling concern I suggest brief study of these two protocol specifications. We are mentioning CICP and SETP as acknowledgement for our previous work before MXP collaboration. CICP stands for Content Injection and Control Protocol: http://greenphosphor.com:8080/CICP_v1_spec.pdf There are not many professionals in the field who have not been participating in some work which has been patented... best regards, Tommi Laukkanen --0016e65097fe6be4f50463875dde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello
 
I can very well understand patent concerns. All our MXP work has been = licensed under Apache 2.0 License which states the following about patents:=
 
   3. Grant of Patent License. Subject to the terms and cond= itions of
      this License, each Contributor = hereby grants to You a perpetual,
      worldwi= de, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent li= cense to make, have made,
      use, offer to s= ell, sell, import, and otherwise transfer the Work,
   &n= bsp;  where such license applies only to those patent claims licensabl= e
      by such Contributor that are necessarily inf= ringed by their
      Contribution(s) alone or = by combination of their Contribution(s)
      w= ith the Work to which such Contribution(s) was submitted. If You
 &= nbsp;    institute patent litigation against any entity (inc= luding a
      cross-claim or counterclaim in a lawsuit) al= leging that the Work
      or a Contribution in= corporated within the Work constitutes direct
    &n= bsp; or contributory patent infringement, then any patent licenses
 = ;     granted to You under this License for that Work s= hall terminate
      as of the date such litigation is filed.
=
Here is Bens recent blog post about his patent application which he ma= de for CICP before our collaboration started: http://www.cybertechnews.org/?p=3D765
 
We are only reusing ideas and design principles from CICP. No algorith= ms, message structures, message sequences or the kind has been co= pied. The reference implementation has been made by me alone and I have not= seen any CICP code. For anyone still feeling concern I suggest b= rief study of these two protocol specifications. We are mentioning CICP and= SETP as acknowledgement for our previous work before MXP collaboratio= n. CICP stands for Content Injection and Control Protocol: http://greenphosphor.com:8080/CI= CP_v1_spec.pdf
 
There are not many professionals in the field who have not been partic= ipating in some work which has been patented...
 
best regards,
Tommi Laukkanen
--0016e65097fe6be4f50463875dde-- From jwatte@gmail.com Sun Feb 22 12:09:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886853A6407 for ; Sun, 22 Feb 2009 12:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1krAhBtDJI3N for ; Sun, 22 Feb 2009 12:09:38 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 71E693A68C5 for ; Sun, 22 Feb 2009 12:09:38 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1539402rvb.49 for ; Sun, 22 Feb 2009 12:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=a07WgJNFMPceVdMOoupX75dXTFWaaN2rlDrlUnX8GgY=; b=S1UtVTM+QFXStgqoje/MCtvzhKpL7gEqvqC0lYE+Y6YlXokUIBdEIzxiLea2jL8zkJ jbNXsOn4jQkdbgwWOp52cMhGlIeWVGsIV0HXUgOd2sPbkpR0MM9CPKdzEFVDtAGTuB4O jkCl8+p6mbGl7OB8nTcD6EDSbF4nOg/VD0WN0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=QFjoEB8ZgsIOG6gZqC61Nx2ByqapI6cYltRWRLyKSemTe+UjJkj4Yg4PhNM0Gn2Lf9 CJUskEIEqJHxfEkR1CQsIS9TgpBNH+yCv/ZdpAOEMQs3WUl3yDvSzMVbIjgch+S7LLv9 nVHzmq1uqcrjUniiLER2+1J5fSItwZcJLpH7c= Received: by 10.141.29.14 with SMTP id g14mr1642866rvj.150.1235333394660; Sun, 22 Feb 2009 12:09:54 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id l31sm11880295rvb.5.2009.02.22.12.09.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 12:09:54 -0800 (PST) Message-ID: <49A1B111.8010506@gmail.com> Date: Sun, 22 Feb 2009 12:09:53 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Mark P. McCahill" References: <49A04DEB.4060301@gmail.com> <49A16F4D.8070007@comlounge.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:09:39 -0000 Mark P. McCahill wrote: > If we accept the idea of federated identity, avatar names as used in > current practice need to change. They would need to include the party > that > issued the identity - something like this: > Mysterio_Sinister@secondlife.com or > mccahill@duke.edu. I agree. I do think there may be a difference between "identity" and "presentation" though. In general, the "label" put over an avatar is "presentation" and might be something simple like "jwatte" (my Forterra internal avatar name), or something elaborate like "The Guy Your Mother Warned You About." Meanwhile, each system would generally have to provide a way to query/display the underlying identity of that avatar/presence. Some systems may even choose to not use the "presentation" aspect at all, choosing to always display the underlying identity. When it comes to identity, I feel that the following things are needed: 1) Some standard way to identify the identity provider for a given entity. 2) Some token issued by that provider that represents the identity. 3) Some standardized way to contact the identity provider to verify identity (detect impersonation.) Specifically, if your avatar /claims/ to be "mrpresident" with the identity provider "whitehouse.gov," then there needs to be a way for me to verify that that's actually true, that probably involves contacting the whitehouse.gov identity provider, again using some standard protocol. Then, in the end, my trust for that entity will be based on my trust for the identity provider. Sincerely, jw From jwatte@gmail.com Sun Feb 22 12:16:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD81A3A68C5 for ; Sun, 22 Feb 2009 12:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3YzSI5Lmpu8 for ; Sun, 22 Feb 2009 12:16:33 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.158]) by core3.amsl.com (Postfix) with ESMTP id 6C7D03A6407 for ; Sun, 22 Feb 2009 12:16:32 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so5826529poe.4 for ; Sun, 22 Feb 2009 12:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mKb6qaRyjqRtUbDFgvQrTLGQKxzED4Nl8QpdMds1ADg=; b=gflQQLamlZHVdXHTvSP2nLiKPa3i41VHFqD5W/fLpuVW9QITZ/ULu6j/ePnsHkobDA HWcx3Qr58oM1c5jgX2Wu7OAWOk3v5ZYxaV4GeGs++jqdIjgCBCIGn6PHRqb8c4XGqxWp epfo7Yo8YRIFUpJoB98XMHyEo2IOhza7IiyV4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KE6jTgc7v7ZYq/HeeCJuxfCdYJ0haLjEF7wvg1XkM1t/0/8yO2Imkr8k6VWHoPGtd5 KP7IU8cgKDLWZIZ6do7Zm9T1h/U390gIRWkAeWvaQOG2Qo9tv7hb1jMBTLfn/fDscLql tO2z49DvavqBH4l+J6QbDahnnaPbbY5rnovIk= Received: by 10.141.133.14 with SMTP id k14mr1646886rvn.98.1235333808426; Sun, 22 Feb 2009 12:16:48 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id f21sm11900935rvb.2.2009.02.22.12.16.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 12:16:48 -0800 (PST) Message-ID: <49A1B2AE.10804@gmail.com> Date: Sun, 22 Feb 2009 12:16:46 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <49A1A158.3020605@gmail.com> <61dbdd7d0902221113l7309d7abk1996ed04640a4b7a@mail.gmail.com> In-Reply-To: <61dbdd7d0902221113l7309d7abk1996ed04640a4b7a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:16:34 -0000 Gareth Nelson wrote: >> model is Web 2.0, but I think it's still a halting comparison. If you want >> to be able to "connect to any server from any client," then you could do >> that today. Define the client as being Internet Explorer with ActiveX >> controls, and define the server to be Apache, and you're done. *We can do >> that today*. However, nobody is doing it, because it doesn't actually >> provide any additional value. >> > Any web browser that supports HTTP and HTML can connect to any httpd. > Everyone does this today :) > The additional value is obvious - any device which implements these 2 > standards can be a web browser or a web server. I can browse on my PC > running GNU/Linux or my Sony PSP. I can even post to forums with both > these devices and let windows 98 users read my posts. > > Why is the value of a standardized virtual world client protocol obvious? Why would a protocol separate from HTTP and ActiveX (or Mozilla plug-ins) add any value compared to what can be done today? A protocol is great when it enables additional applications -- when you can actually do things when using the protocol, that you couldn't do when you didn't have the protocol. The value of the protocol is directly proportional to the things you can do with it, that you couldn't do without it. Connecting a given client machine to more than one world is something that could be done today, using HTTP and regular web browsers. Adding a protocol that is specific to some stand-alone program that's not a web browser adds nothing new. We don't need a new protocol for that, because we already have HTTP and browser plug-ins. Meanwhile, connecting different simulation domains so that they can each provide to the same user-visible simulation is something new, that provides a lot of value. It allows interactive objects developed from one system to be presented to and affect simulations in another system, without the systems having to agree on things like physics engines, scripting languages, or any other implementation details -- only presentation. Sincerely, jw From jwatte@gmail.com Sun Feb 22 12:18:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9263A6823 for ; Sun, 22 Feb 2009 12:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvlrnHtwCJeJ for ; Sun, 22 Feb 2009 12:18:34 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.153]) by core3.amsl.com (Postfix) with ESMTP id 750F63A6407 for ; Sun, 22 Feb 2009 12:18:34 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so5828799poe.4 for ; Sun, 22 Feb 2009 12:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=K68suj52VyWjLxMJ2tnAk1/jtmyqYRIAn3muR0TbAck=; b=jQB2oEwTrKoIvhBltxJlaoa/fh9gYcLHa87eUWJ8ycTQY3wLQaoKTk+A8l00du8xHj g9xGj9ebIkPMI2vA3gjGzTwXHQoBWhMDUmET/TLdhJl7/GCTK3YbMbb46n96NtHbQopL 9tX7Ol+rUQMeNclkEhz2rAKGccl5XI83I44ZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DEYWx2jnqbXqq6gUb+/cUFwBxPUGelbttNnFUItnziTHJHVPEDYYHJG2RBjtYfjOsn 4tJQ3uCjfv9TlV0m+H4ZPWHk3FYkll9efioe9VaSBgF+PrNYEiIhxmlmYe5RxX+UvABM ucrZn8vWlnuS/tx3ng9v9B+y3cHfGpJrRS+Fw= Received: by 10.140.136.5 with SMTP id j5mr1655182rvd.39.1235333929549; Sun, 22 Feb 2009 12:18:49 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id l31sm11898490rvb.5.2009.02.22.12.18.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 12:18:49 -0800 (PST) Message-ID: <49A1B328.5090506@gmail.com> Date: Sun, 22 Feb 2009 12:18:48 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dan Olivares References: <562887.12996.qm@web82607.mail.mud.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:18:35 -0000 Dan Olivares wrote: > I'm reaching here, but I think Meadhbh might be referring to it's > reliance on CICP to which, according to the creator in an article > posted on slashdot, there's a provisional patent application filed. > It seems that he is intending it to be public domain, but, the thought > of patents scares a lot of people. Ref: > http://ask.slashdot.org/article.pl?no_d2=1&sid=09/02/04/1934229 > > I believe there may be significant prior art to CICP. Also, given my experience with the current approach to patent examination in the patent office, it's unlikely that something like CICP would actually pass muster (see some recent case law that has made general software patents significantly harder to obtain). Of course, nobody knows how it will actually work out, so a written declaration of public domain dedication of that provisional patent would be safest, if you worry about that particular detail. Sincerely, jw From gareth@litesim.com Sun Feb 22 12:24:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCBD28C0E1 for ; Sun, 22 Feb 2009 12:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjBegcjSfkpV for ; Sun, 22 Feb 2009 12:24:40 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id C57ED3A6823 for ; Sun, 22 Feb 2009 12:24:40 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1542227rvb.49 for ; Sun, 22 Feb 2009 12:24:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.71.14 with SMTP id y14mr1650887rvk.131.1235334297197; Sun, 22 Feb 2009 12:24:57 -0800 (PST) In-Reply-To: <49A1B2AE.10804@gmail.com> References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <49A1A158.3020605@gmail.com> <61dbdd7d0902221113l7309d7abk1996ed04640a4b7a@mail.gmail.com> <49A1B2AE.10804@gmail.com> Date: Sun, 22 Feb 2009 20:24:57 +0000 Message-ID: <61dbdd7d0902221224o47b1ebdai1c3dd0ef22b52523@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:24:41 -0000 The value is that it turns the "3D web" into a commodity just like the 2D web is On Sun, Feb 22, 2009 at 8:16 PM, Jon Watte wrote: > Gareth Nelson wrote: >>> >>> model is Web 2.0, but I think it's still a halting comparison. If you >>> want >>> to be able to "connect to any server from any client," then you could do >>> that today. Define the client as being Internet Explorer with ActiveX >>> controls, and define the server to be Apache, and you're done. *We can do >>> that today*. However, nobody is doing it, because it doesn't actually >>> provide any additional value. >>> >> >> Any web browser that supports HTTP and HTML can connect to any httpd. >> Everyone does this today :) >> The additional value is obvious - any device which implements these 2 >> standards can be a web browser or a web server. I can browse on my PC >> running GNU/Linux or my Sony PSP. I can even post to forums with both >> these devices and let windows 98 users read my posts. >> >> > > Why is the value of a standardized virtual world client protocol obvious? > Why would a protocol separate from HTTP and ActiveX (or Mozilla plug-ins) > add any value compared to what can be done today? > > A protocol is great when it enables additional applications -- when you can > actually do things when using the protocol, that you couldn't do when you > didn't have the protocol. The value of the protocol is directly proportional > to the things you can do with it, that you couldn't do without it. > > Connecting a given client machine to more than one world is something that > could be done today, using HTTP and regular web browsers. Adding a protocol > that is specific to some stand-alone program that's not a web browser adds > nothing new. We don't need a new protocol for that, because we already have > HTTP and browser plug-ins. > > Meanwhile, connecting different simulation domains so that they can each > provide to the same user-visible simulation is something new, that provides > a lot of value. It allows interactive objects developed from one system to > be presented to and affect simulations in another system, without the > systems having to agree on things like physics engines, scripting languages, > or any other implementation details -- only presentation. > > Sincerely, > > jw > > From jwatte@gmail.com Sun Feb 22 12:50:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DEB528C178 for ; Sun, 22 Feb 2009 12:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkhiHtC7Zz1A for ; Sun, 22 Feb 2009 12:50:25 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.158]) by core3.amsl.com (Postfix) with ESMTP id 8C20028C145 for ; Sun, 22 Feb 2009 12:50:25 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so5850695poe.4 for ; Sun, 22 Feb 2009 12:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=uZnR7hcxcD+lwIP73kUfP0jFeFoCc/Ac37CYtMwTeY0=; b=crtmARtXlRu9F05hb1+HeC914wSXEZI/i2qXUX+KRUkDi1+XpW5pzwhsq00aMa8OOq gFUjSp0hpdCL2f4sEI+Nolk0xPwRVCOg1M1TLga4yz7CAOYi5E1kSFVMkTO3BnoDuO7I yqI1w7ta9Tq4kChyBohULLGLBTbrpJYWP+/IQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Ity2jeBZvih5EDHQSUxji9ps/yOJlEpEMqM6s6UHgDSZ78rPF9moRmqZtrUNFYHo8a DfPiFO370VT7cSa74uN2oGPUY8cT0ih1wCidgq50I9mXUhj+FiAsLsvlq2PNv3A6U0Xo H+OckkU+sKYRNneQpYrPMprJwuRGVsh2qA9LM= Received: by 10.115.16.14 with SMTP id t14mr1362246wai.185.1235335842177; Sun, 22 Feb 2009 12:50:42 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k37sm13228064rvb.1.2009.02.22.12.50.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 12:50:41 -0800 (PST) Message-ID: <49A1BAA0.7080702@gmail.com> Date: Sun, 22 Feb 2009 12:50:40 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <49A1A158.3020605@gmail.com> <61dbdd7d0902221113l7309d7abk1996ed04640a4b7a@mail.gmail.com> <49A1B2AE.10804@gmail.com> <61dbdd7d0902221224o47b1ebdai1c3dd0ef22b52523@mail.gmail.com> In-Reply-To: <61dbdd7d0902221224o47b1ebdai1c3dd0ef22b52523@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 20:50:26 -0000 Gareth Nelson wrote: > The value is that it turns the "3D web" into a commodity just like the 2D web is > How is it doing this differently from already being able to view 3D content in a web browser? To the user, what is the difference in capabilities? Sincerely, jw From lenglish5@cox.net Sun Feb 22 13:14:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001533A6AE3 for ; Sun, 22 Feb 2009 13:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.829 X-Spam-Level: X-Spam-Status: No, score=0.829 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo+VNMW23Gog for ; Sun, 22 Feb 2009 13:14:18 -0800 (PST) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id A581E28C1D5 for ; Sun, 22 Feb 2009 13:11:57 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090222211214.WRCN2948.fed1rmmtao101.cox.net@fed1rmimpo03.cox.net>; Sun, 22 Feb 2009 16:12:14 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id K9CE1b0064N6T0Q049CECF; Sun, 22 Feb 2009 16:12:14 -0500 X-Authority-Analysis: v=1.0 c=1 a=cvwy08X6BTcA:10 a=goDEM_hwrrwA:10 a=Wajolswj7cQA:10 a=DIgASRjHeOlMM7tXtj8A:9 a=QtHZZ6XZ2YIusjTQ9ah75SCaT9MA:4 a=6UxOEEjT9BUA:10 X-CM-Score: 0.00 Message-ID: <49A1BFAE.3060705@cox.net> Date: Sun, 22 Feb 2009 14:12:14 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gareth Nelson References: <499F0B85.8060807@gmail.com> <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> In-Reply-To: <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 21:14:19 -0000 Gareth Nelson wrote: > Just to nitpick, meshes and LCCs do work well together, just provide > different LODs :) > Well, the ideal thing is to be able to turn off graphical stuff completely. Text-based chat via a smartphone needs no graphical stuff, though navigating via the map system might be worth implementing. L From infinity@lindenlab.com Sun Feb 22 13:30:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4510728C12C for ; Sun, 22 Feb 2009 13:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8CP7JA-2FYj for ; Sun, 22 Feb 2009 13:30:05 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 2A73E3A6879 for ; Sun, 22 Feb 2009 13:30:05 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id BED083DBC098; Sun, 22 Feb 2009 13:30:21 -0800 (PST) Message-Id: <744D5200-2829-4CF1-B513-2566367CB804@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Charles Krinke In-Reply-To: <562887.12996.qm@web82607.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary=Apple-Mail-6--667018066 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Feb 2009 13:30:19 -0800 References: <562887.12996.qm@web82607.mail.mud.yahoo.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 21:30:06 -0000 --Apple-Mail-6--667018066 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit no. it's just considered good form to disclose patent encumbrance when introducing a new technology. so.. my read on IPR policy is we're free to introduce protocols, techniques, etc., to mailing list discussions that may be covered by some IP regime and when you submit a draft that makes use of encumbered technology, you MUST disclose your IPR interest. we're probably in a bit of limbo here 'cause we're not even a working group yet this _is_ an ietf mailing list, so discussions brought to it must be in accord with the IETF IPR disclosure policy. anecdotal accounts from the web indicate MXP is based on CICP, and the IP status of CICP is "complicated." i am unfortunately unfamiliar with the contents of MXP or CICP, so i can't comment on how they might relate to anything that happens here. so... i was hoping that the people responsible for either MXP or CICP, who have a good understanding of those proposals disclose the IPR interests. -cheers -m On Feb 22, 2009, at 8:19 AM, Charles Krinke wrote: > Dear Meadhbh: > > Can you help Tommi (and myself) understand what you mean? Was it > inappropriate to make the MXP post to this list? I do not understand > what the context is. > > Charles > > From: Meadhbh Hamrick (Infinity) > To: Tommi Laukkanen > Cc: mmox@ietf.org > Sent: Sunday, February 22, 2009 1:03:05 AM > Subject: Re: [mmox] Other NVE protocol specification efforts > > tommi.. did you read the IPR disclosure rules? > > On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen wrote: > >> Hello >> >> I have been participating in an open source effort to specify a >> networked virtual environment protocol. Although Metaverse Exchange >> Protocol (MXP) is covering only part of the scope here I thought it >> might be interesting. >> >> MXP collects some good ideas to coherent theoretical model (Bubble >> Cloud) and proposes working engineering solution. One of the MXP >> over UDP key concepts is to have a minimal set of UDP messages for >> connectivity, transport and distributed virtual environment scene >> graph synchronization. All application specific information is >> transmitted as payload over the UDP messages encoded in MXMP >> format. Another key concept is to multiplex all the communication >> through one UDP port to simplify the session handling and network >> connectivity. >> >> Working C# prototype exists which demonstrates the reference >> implementation. >> >> I believe that MXP is a good read currently for people interested >> in NVE field. You can find the specification wiki from here: >> >> http://go-mxp.org >> >> best regards, >> Tommi Laukkanen >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > --Apple-Mail-6--667018066 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable no. it's just considered good = form to disclose patent encumbrance when introducing a new = technology.

so.. my read on IPR policy is we're free = to introduce protocols, techniques, etc., to mailing list discussions = that may be covered by some IP regime and when you submit a draft that = makes use of encumbered technology, you MUST disclose your IPR interest. = we're probably in a bit of limbo here 'cause we're not even a working = group yet this _is_ an ietf mailing list, so discussions brought to it = must be in accord with the IETF IPR disclosure = policy.

anecdotal accounts from the web = indicate MXP is based on CICP, and the IP status of CICP is = "complicated." i am unfortunately unfamiliar with the contents of MXP or = CICP, so i can't comment on how they might relate to anything that = happens here.

so... i was hoping that the = people responsible for either MXP or CICP, who have a good understanding = of those proposals disclose the IPR = interests.

-cheers
-m

On Feb 22, 2009, at 8:19 AM, Charles Krinke wrote:

Dear Meadhbh:

Can you help Tommi (and myself) = understand what you mean? Was it inappropriate to make the MXP post to = this list? I do not understand what the context = is.

Charles

From: Meadhbh Hamrick (Infinity) = <infinity@lindenlab.com>
<= span style=3D"font-weight: bold; ">To: Tommi Laukkanen <tommi.s.e.laukkanen@gmail.co= m>
Cc: mmox@ietf.org
Sent: Sunday, February 22, 2009 = 1:03:05 AM
 Re: [mmox] Other NVE = protocol specification efforts

tommi.. did you read the = IPR disclosure rules?

On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen = wrote:

Hello
 
I have been = participating in an open source effort to specify a networked virtual = environment protocol. Although Metaverse Exchange Protocol (MXP) is = covering only part of the scope here I thought it might be = interesting.
 
MXP collects some good ideas to coherent = theoretical model (Bubble Cloud) and proposes working engineering = solution. One of the MXP over UDP key concepts is to have a minimal set = of UDP messages for connectivity, transport and distributed virtual = environment scene graph synchronization. All application specific = information is transmitted as payload over the UDP messages encoded in = MXMP format. Another key concept is to multiplex all the communication = through one UDP port to simplify the session handling and network = connectivity. 
 
Working C# = prototype exists which demonstrates the reference = implementation.
 
I believe that MXP is a good read currently = for people interested in NVE field. You can find the specification wiki = from here:
 
http://go-mxp.org
 
best = regards,
Tommi Laukkanen



= --Apple-Mail-6--667018066-- From gareth@litesim.com Sun Feb 22 13:32:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8DD83A69FC for ; Sun, 22 Feb 2009 13:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAqyWt8hDgsr for ; Sun, 22 Feb 2009 13:32:36 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 07D6E3A6954 for ; Sun, 22 Feb 2009 13:32:35 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1555237rvb.49 for ; Sun, 22 Feb 2009 13:32:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.49.18 with SMTP id b18mr1674875rvk.96.1235338371986; Sun, 22 Feb 2009 13:32:51 -0800 (PST) In-Reply-To: <49A1BAA0.7080702@gmail.com> References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <49A1A158.3020605@gmail.com> <61dbdd7d0902221113l7309d7abk1996ed04640a4b7a@mail.gmail.com> <49A1B2AE.10804@gmail.com> <61dbdd7d0902221224o47b1ebdai1c3dd0ef22b52523@mail.gmail.com> <49A1BAA0.7080702@gmail.com> Date: Sun, 22 Feb 2009 21:32:51 +0000 Message-ID: <61dbdd7d0902221332s442d0dadm6661a836cdbfcb25@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 21:32:36 -0000 This is turning into a "what can we do in virtual worlds that can't be done with web browsers?", to which i'll respond "nothing, since we can put virtual worlds into browsers", but that's irrelevant essentially. Proof that plugins can do anything: http://www.flickr.com/photos/gwengareth/2914357868/ http://www.flickr.com/photos/gwengareth/2828674099/ http://www.flickr.com/photos/gwengareth/2829338568/in/photostream/ But of course, my point was that these plugins still need the standard protocols, the above example is just SL in a browser for example. On Sun, Feb 22, 2009 at 8:50 PM, Jon Watte wrote: > Gareth Nelson wrote: >> >> The value is that it turns the "3D web" into a commodity just like the 2D >> web is >> > > How is it doing this differently from already being able to view 3D content > in a web browser? > To the user, what is the difference in capabilities? > > Sincerely, > > jw > > From gareth@litesim.com Sun Feb 22 13:33:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B28B33A69FC for ; Sun, 22 Feb 2009 13:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W98EcMt8JYf for ; Sun, 22 Feb 2009 13:33:28 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 75A1F3A6879 for ; Sun, 22 Feb 2009 13:33:28 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1555413rvb.49 for ; Sun, 22 Feb 2009 13:33:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.161.6 with SMTP id n6mr1683185rvo.0.1235338425574; Sun, 22 Feb 2009 13:33:45 -0800 (PST) In-Reply-To: <49A1BFAE.3060705@cox.net> References: <314782.22040.qm@web82601.mail.mud.yahoo.com> <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> Date: Sun, 22 Feb 2009 21:33:45 +0000 Message-ID: <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> From: Gareth Nelson To: lenglish5@cox.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 21:33:29 -0000 Of course, I was suggesting multiple LODs only when you actually request them, not as something mandatory. On Sun, Feb 22, 2009 at 9:12 PM, Lawson English wrote: > Gareth Nelson wrote: >> >> Just to nitpick, meshes and LCCs do work well together, just provide >> different LODs :) >> > > Well, the ideal thing is to be able to turn off graphical stuff completely. > Text-based chat via a smartphone > needs no graphical stuff, though navigating via the map system might be > worth implementing. > > > > L > From dwl@us.ibm.com Sun Feb 22 14:34:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0353A683D; Sun, 22 Feb 2009 14:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQiiT9Cl7+GX; Sun, 22 Feb 2009 14:34:54 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 88AD93A68EF; Sun, 22 Feb 2009 14:34:50 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1MMWqBK006046; Sun, 22 Feb 2009 17:32:52 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1MMZ4wH183602; Sun, 22 Feb 2009 17:35:06 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1MMXqtf032708; Sun, 22 Feb 2009 17:33:52 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1MMXqLC032702; Sun, 22 Feb 2009 17:33:52 -0500 In-Reply-To: <744D5200-2829-4CF1-B513-2566367CB804@lindenlab.com> To: "Meadhbh Hamrick (Infinity)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Sun, 22 Feb 2009 17:35:04 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/22/2009 17:35:03, Serialize complete at 02/22/2009 17:35:03 Content-Type: multipart/alternative; boundary="=_alternative 007C0F6585257565_=" Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 22:34:56 -0000 This is a multipart message in MIME format. --=_alternative 007C0F6585257565_= Content-Type: text/plain; charset="US-ASCII" I am, in no way a lawyer, so use the usual grains lf salt. We're on an IETF mailing list, and NOTEWELL fully applies. I believe that, anyone who suggests an existing piece of technology that they *know* is IP encumbered is supposed to disclose the encumberance. That certainly applies on any formal submissions, and it is cerainly in the spirit of the rules. Encumberance doesn't prohibit discussing it at all, just it needs to be disclossed. As I read the IETF rules, anything which would get specificed wihch in encumbered has to be available under RAND (Reasonable and Non Discremenatory) terms, The IETF, encourages, members to donate patented material for free use, and, encourages solutions which don't use encumbered material. - David W. Levine ~ Zha Ewry (ISL) "Meadhbh Hamrick (Infinity)" Sent by: mmox-bounces@ietf.org 02/22/2009 04:30 PM To Charles Krinke cc mmox@ietf.org Subject Re: [mmox] Other NVE protocol specification efforts no. it's just considered good form to disclose patent encumbrance when introducing a new technology. so.. my read on IPR policy is we're free to introduce protocols, techniques, etc., to mailing list discussions that may be covered by some IP regime and when you submit a draft that makes use of encumbered technology, you MUST disclose your IPR interest. we're probably in a bit of limbo here 'cause we're not even a working group yet this _is_ an ietf mailing list, so discussions brought to it must be in accord with the IETF IPR disclosure policy. anecdotal accounts from the web indicate MXP is based on CICP, and the IP status of CICP is "complicated." i am unfortunately unfamiliar with the contents of MXP or CICP, so i can't comment on how they might relate to anything that happens here. so... i was hoping that the people responsible for either MXP or CICP, who have a good understanding of those proposals disclose the IPR interests. -cheers -m On Feb 22, 2009, at 8:19 AM, Charles Krinke wrote: Dear Meadhbh: Can you help Tommi (and myself) understand what you mean? Was it inappropriate to make the MXP post to this list? I do not understand what the context is. Charles From: Meadhbh Hamrick (Infinity) To: Tommi Laukkanen Cc: mmox@ietf.org Sent: Sunday, February 22, 2009 1:03:05 AM Subject: Re: [mmox] Other NVE protocol specification efforts tommi.. did you read the IPR disclosure rules? On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen wrote: Hello I have been participating in an open source effort to specify a networked virtual environment protocol. Although Metaverse Exchange Protocol (MXP) is covering only part of the scope here I thought it might be interesting. MXP collects some good ideas to coherent theoretical model (Bubble Cloud) and proposes working engineering solution. One of the MXP over UDP key concepts is to have a minimal set of UDP messages for connectivity, transport and distributed virtual environment scene graph synchronization. All application specific information is transmitted as payload over the UDP messages encoded in MXMP format. Another key concept is to multiplex all the communication through one UDP port to simplify the session handling and network connectivity. Working C# prototype exists which demonstrates the reference implementation. I believe that MXP is a good read currently for people interested in NVE field. You can find the specification wiki from here: http://go-mxp.org best regards, Tommi Laukkanen _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --=_alternative 007C0F6585257565_= Content-Type: text/html; charset="US-ASCII"
I am,  in no way a lawyer, so use the usual grains lf salt. We're on an IETF mailing list, and NOTEWELL fully applies.  I believe that, anyone who suggests an existing piece of technology that they *know* is IP encumbered is supposed to disclose the encumberance. That certainly applies on any formal submissions, and it is cerainly in the spirit of the  rules. Encumberance doesn't prohibit discussing it at all, just it needs to be disclossed.  As I read the IETF rules, anything which would get specificed wihch in encumbered has to be available under RAND (Reasonable and Non Discremenatory) terms, The IETF, encourages, members to donate patented material for free use, and, encourages solutions which don't use encumbered material.

- David W. Levine
~ Zha Ewry (ISL)


"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
Sent by: mmox-bounces@ietf.org

02/22/2009 04:30 PM

To
Charles Krinke <cfk@pacbell.net>
cc
mmox@ietf.org
Subject
Re: [mmox] Other NVE protocol specification efforts





no. it's just considered good form to disclose patent encumbrance when introducing a new technology.

so.. my read on IPR policy is we're free to introduce protocols, techniques, etc., to mailing list discussions that may be covered by some IP regime and when you submit a draft that makes use of encumbered technology, you MUST disclose your IPR interest. we're probably in a bit of limbo here 'cause we're not even a working group yet this _is_ an ietf mailing list, so discussions brought to it must be in accord with the IETF IPR disclosure policy.

anecdotal accounts from the web indicate MXP is based on CICP, and the IP status of CICP is "complicated." i am unfortunately unfamiliar with the contents of MXP or CICP, so i can't comment on how they might relate to anything that happens here.

so... i was hoping that the people responsible for either MXP or CICP, who have a good understanding of those proposals disclose the IPR interests.

-cheers
-m

On Feb 22, 2009, at 8:19 AM, Charles Krinke wrote:

Dear Meadhbh:

Can you help Tommi (and myself) understand what you mean? Was it inappropriate to make the MXP post to this list? I do not understand what the context is.

Charles

From: Meadhbh Hamrick (Infinity) <infinity@lindenlab.com>
To: Tommi Laukkanen <tommi.s.e.laukkanen@gmail.com>
Cc: mmox@ietf.org
Sent: Sunday, February 22, 2009 1:03:05 AM
Subject: Re: [mmox] Other NVE protocol specification efforts

tommi.. did you read the IPR disclosure rules?

On Feb 22, 2009, at 12:47 AM, Tommi Laukkanen wrote:

Hello

I have been participating in an open source effort to specify a networked virtual environment protocol. Although Metaverse Exchange Protocol (MXP) is covering only part of the scope here I thought it might be interesting.

MXP collects some good ideas to coherent theoretical model (Bubble Cloud) and proposes working engineering solution. One of the MXP over UDP key concepts is to have a minimal set of UDP messages for connectivity, transport and distributed virtual environment scene graph synchronization. All application specific information is transmitted as payload over the UDP messages encoded in MXMP format. Another key concept is to multiplex all the communication through one UDP port to simplify the session handling and network connectivity.

Working C# prototype exists which demonstrates the reference implementation.

I believe that MXP is a good read currently for people interested in NVE field. You can find the specification wiki from here:

http://go-mxp.org

best regards,
Tommi Laukkanen
 
_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox


_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
--=_alternative 007C0F6585257565_=-- From jwatte@gmail.com Sun Feb 22 14:35:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F8383A683D for ; Sun, 22 Feb 2009 14:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZdTnEJq0utI for ; Sun, 22 Feb 2009 14:35:05 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.236]) by core3.amsl.com (Postfix) with ESMTP id B23DC3A6AB3 for ; Sun, 22 Feb 2009 14:35:05 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id e34so1107658qbe.41 for ; Sun, 22 Feb 2009 14:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=lJx3lhp2h2TJM2adyWuhR5v1Rabg8SHHPuhnIBxocmM=; b=KCMvnE5N8nIJC44zUzVsXQc4xt+ZytmoiyWuzZufbq96Hbxziiqt9JEPNlyW1LUy0w LuFBvBHqJVoAduLA1MhK+7iyILHjECBYOAm3YDPHy1jQjpSCPlraBL/HS1MHVex2f2D/ tPiKB4fqbQOnqOPB6hAcnAIsKEvcRLF+19RyA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=sYbxP1Ofyf82ru8E+7T4K62S/7OccAygFpRgbUVbSMELq8nLrp5K7o8tyz5PrTUzqf QKzTqG9uWGLI3uefHU4Oe9142h2W4xi/LvfH/Nf/Sh+b0TNwYQ6z3WF/l+xIg+HCisnD jPwyIc9ejHXZ18hXjpQPzcEOBJbg/Yn7JStCA= Received: by 10.141.195.5 with SMTP id x5mr1681574rvp.282.1235342121049; Sun, 22 Feb 2009 14:35:21 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id f42sm888527rvb.3.2009.02.22.14.35.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 14:35:20 -0800 (PST) Message-ID: <49A1D327.90502@gmail.com> Date: Sun, 22 Feb 2009 14:35:19 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <49A1A158.3020605@gmail.com> <61dbdd7d0902221113l7309d7abk1996ed04640a4b7a@mail.gmail.com> <49A1B2AE.10804@gmail.com> <61dbdd7d0902221224o47b1ebdai1c3dd0ef22b52523@mail.gmail.com> <49A1BAA0.7080702@gmail.com> <61dbdd7d0902221332s442d0dadm6661a836cdbfcb25@mail.gmail.com> In-Reply-To: <61dbdd7d0902221332s442d0dadm6661a836cdbfcb25@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 22:35:07 -0000 Gareth Nelson wrote: > This is turning into a "what can we do in virtual worlds that can't be > done with web browsers?", to which i'll respond "nothing, since we can > put virtual worlds into browsers", but that's irrelevant essentially. > That's not actually true, because there are things you can do with a virtual world interoperability protocol used between server peers, that you can't do in a browser-only world. That server peer system is what I'm hoping to accomplish here. Anything that is client-only is unlikely to provide much added value, and unlikely to be adopted by most of the various vendors in the market, for reasons I've already discussed at length on this list. Given the lack of added value in client standardization work for virtual worlds, I view work on that as wasted effort. > But of course, my point was that these plugins still need the standard > protocols, the above example is just SL in a browser for example. > They don't need any new standard protocols, because you already have a standard execution environment (the browser, with a DOM, JavaScript, and a plug-in model), and the standard transport (using HTTP). For anything "additional" they can use a custom protocol; there is no need to standardize there. To the user, any browser-based VWs will already appear "standard" because the user can use the browser to surf from one to the other. However, that just doesn't add much value -- as evidenced by most systems not actually doing that. Sincerely, jw From dwl@us.ibm.com Sun Feb 22 14:37:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 451653A686C; Sun, 22 Feb 2009 14:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=0.690, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pJ4PHqaetN6; Sun, 22 Feb 2009 14:37:11 -0800 (PST) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 0D8DE3A683D; Sun, 22 Feb 2009 14:37:10 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1MMYdPU023412; Sun, 22 Feb 2009 17:34:39 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n1MMbRhn198992; Sun, 22 Feb 2009 17:37:27 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n1MMbR0G004895; Sun, 22 Feb 2009 17:37:27 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n1MMbRqR004892; Sun, 22 Feb 2009 17:37:27 -0500 In-Reply-To: <744D5200-2829-4CF1-B513-2566367CB804@lindenlab.com> To: mmox@ietf.org, mmox-bounces@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Sun, 22 Feb 2009 17:37:27 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/22/2009 17:37:27, Serialize complete at 02/22/2009 17:37:27 Content-Type: multipart/alternative; boundary="=_alternative 007C473F85257565_=" Subject: [mmox] MMOX: Worth reading... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 22:37:12 -0000 This is a multipart message in MIME format. --=_alternative 007C473F85257565_= Content-Type: text/plain; charset="US-ASCII" Grace McDunnough posted an excellent blog entry with some relevant thoughts. I bring everyone's attention to http://phasinggrace.blogspot.com/2009/02/mmox-and-social-architecture.html - David ~ Zha --=_alternative 007C473F85257565_= Content-Type: text/html; charset="US-ASCII"
Grace McDunnough posted an excellent blog entry with some relevant thoughts. I bring everyone's attention to http://phasinggrace.blogspot.com/2009/02/mmox-and-social-architecture.html

- David
~ Zha
--=_alternative 007C473F85257565_=-- From dcolivares@gmail.com Sun Feb 22 15:21:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53133A69DD for ; Sun, 22 Feb 2009 15:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naYyyOEGKNrc for ; Sun, 22 Feb 2009 15:21:43 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 28B253A67E3 for ; Sun, 22 Feb 2009 15:21:43 -0800 (PST) Received: by fxm11 with SMTP id 11so1264916fxm.13 for ; Sun, 22 Feb 2009 15:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NQzwvgJoA+w49U5tnonPJZJVXpyci0vUIdl0NahTe18=; b=YhJaPp7aP4Eqqpr5HCK7rvoMuh9a9abuiPjr+dxveB5OQ/oMt2st9XFnzUxZtinInJ bMggzKNjykN6C9Kn3ng0w4XF73WFAXrqmC/fiTOO52ON9Jyfb47xvJn7/iJg8rafOR86 73evEEP6JLfXCDLzSuuLHNFZOyV1LrFSySlks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SSs2zx2/E/+/Pl07NBCSFCI+ObekhADiObDqHcB0Qk8kdzvzw3a9s4Jqx2HJQQKSqt pEiBnf+fSsppVlmeBHA/DMkSBLzYMd3tj0LEG1WSl0B6WQBs+gu5neOObnAWSxB9bTNK /vuz8iRrNuAy1wn8PN6pkP4KVX2dJAv+NlQqU= MIME-Version: 1.0 Received: by 10.103.102.17 with SMTP id e17mr2960709mum.136.1235344918635; Sun, 22 Feb 2009 15:21:58 -0800 (PST) In-Reply-To: <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> References: <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> Date: Sun, 22 Feb 2009 18:21:58 -0500 Message-ID: From: Dan Olivares To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 23:21:44 -0000 Since one of the topics we're discussing here is the inclusion of a universal object description for interoperability as a potential deliverable and the prim vs mesh debate was brought up, I wanted to bring up that there is a New BSD Licensed (MIT) library developed in C# for receiving LLPrim type object descriptions and converting them to a full mesh (with UV definitions) mostly developed by Tom Hoff. The current project location is: http://forge.opensimulator.org/gf/project/primmesher/ . This is relevant because it is a completely free, open, and tested code implementation of generating the mesh components of LLPrim. This letter is NOT to suggest that we SHOULD use LLPrim specifically in the standard. It does, however, demonstrate that there is code that anyone can refer to or use in working with the LLPrim parametric geometry type. LLPrim also has a specification for using a heightfield type graphic with several different mappings (that can be compressed) for producing a mesh that contains a maximum of 1024 verticies(32x32 heightfield) called the 'sculpted prim'. For more information on the sculpted prim, see: http://wiki.secondlife.com/wiki/Sculpted_Prims:_Technical_Explanation or refer to the implementation in PrimMesher. Best Regards Daniel Olivares On Sun, Feb 22, 2009 at 4:33 PM, Gareth Nelson wrote: > Of course, I was suggesting multiple LODs only when you actually > request them, not as something mandatory. > > On Sun, Feb 22, 2009 at 9:12 PM, Lawson English wrote: >> Gareth Nelson wrote: >>> >>> Just to nitpick, meshes and LCCs do work well together, just provide >>> different LODs :) >>> >> >> Well, the ideal thing is to be able to turn off graphical stuff completely. >> Text-based chat via a smartphone >> needs no graphical stuff, though navigating via the map system might be >> worth implementing. >> >> >> >> L >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From gareth@litesim.com Sun Feb 22 15:36:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BFE53A69BB for ; Sun, 22 Feb 2009 15:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.945 X-Spam-Level: X-Spam-Status: No, score=-2.945 tagged_above=-999 required=5 tests=[AWL=1.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28xQk8NK0Phu for ; Sun, 22 Feb 2009 15:36:11 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 3813D3A67E3 for ; Sun, 22 Feb 2009 15:36:11 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1578611rvb.49 for ; Sun, 22 Feb 2009 15:36:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.71.14 with SMTP id y14mr1713542rvk.131.1235345787205; Sun, 22 Feb 2009 15:36:27 -0800 (PST) In-Reply-To: References: <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> Date: Sun, 22 Feb 2009 23:36:27 +0000 Message-ID: <61dbdd7d0902221536m662a7605q915fa9c90563a2b@mail.gmail.com> From: Gareth Nelson To: Dan Olivares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 23:36:12 -0000 Does primmesher support multiple LODs? Last I checked it was fairly simplistic in the way it created meshes and had a few anomalies in the final product. Bear in mind that I last played with this about 5 or 6 months ago. On Sun, Feb 22, 2009 at 11:21 PM, Dan Olivares wrote: > Since one of the topics we're discussing here is the inclusion of a > universal object description for interoperability as a potential > deliverable and the prim vs mesh debate was brought up, I wanted to > bring up that there is a New BSD Licensed (MIT) library developed in > C# for receiving LLPrim type object descriptions and converting them > to a full mesh (with UV definitions) mostly developed by Tom Hoff. > The current project location is: > http://forge.opensimulator.org/gf/project/primmesher/ . > > This is relevant because it is a completely free, open, and tested > code implementation of generating the mesh components of LLPrim. > > This letter is NOT to suggest that we SHOULD use LLPrim specifically > in the standard. It does, however, demonstrate that there is code > that anyone can refer to or use in working with the LLPrim parametric > geometry type. LLPrim also has a specification for using a > heightfield type graphic with several different mappings (that can be > compressed) for producing a mesh that contains a maximum of 1024 > verticies(32x32 heightfield) called the 'sculpted prim'. For more > information on the sculpted prim, see: > http://wiki.secondlife.com/wiki/Sculpted_Prims:_Technical_Explanation > or refer to the implementation in PrimMesher. > > Best Regards > > Daniel Olivares > > On Sun, Feb 22, 2009 at 4:33 PM, Gareth Nelson wrote: >> Of course, I was suggesting multiple LODs only when you actually >> request them, not as something mandatory. >> >> On Sun, Feb 22, 2009 at 9:12 PM, Lawson English wrote: >>> Gareth Nelson wrote: >>>> >>>> Just to nitpick, meshes and LCCs do work well together, just provide >>>> different LODs :) >>>> >>> >>> Well, the ideal thing is to be able to turn off graphical stuff completely. >>> Text-based chat via a smartphone >>> needs no graphical stuff, though navigating via the map system might be >>> worth implementing. >>> >>> >>> >>> L >>> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From dcolivares@gmail.com Sun Feb 22 15:44:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8EE3A6807 for ; Sun, 22 Feb 2009 15:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=0.917, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V44Ewnz7V8Rv for ; Sun, 22 Feb 2009 15:44:22 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 389AD3A67E3 for ; Sun, 22 Feb 2009 15:44:22 -0800 (PST) Received: by fxm11 with SMTP id 11so1273173fxm.13 for ; Sun, 22 Feb 2009 15:44:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fa47UOGNmC1bDm4ag0TUaOP5DWcik1KymuSZqTDYi8M=; b=juyj8foYbkZ4+2lCVMH/dMjEFoG4d8GVfLXEzz+kF/98+dyEHEOGOT9pOIP28lO8qv 3Ac+yrv2gMiLXTGG5o806hbsA0IRu9s+vZokMrdaWIuIeJYurVLmAftMYhlUTiRoVWOk 6qQsIrmreHuE78tgeeZiS2nagUc+v7h8dZheM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Mp8OFbcmyHL7Dj/EcVV+nXtMqmf9rLtf5rrJatNhMaBVtFyVzBuRmJt4yqnNID5Qro 09CHXXktm3+jCWta/i+vIpiJEazsimp03Ki+MvyNIcZLQz9R6nY/kKY834/lJUOrF8R4 rXdXh59Kqx9b5BhXw0wnBek/D5my0/vITo9YM= MIME-Version: 1.0 Received: by 10.103.92.10 with SMTP id u10mr2983769mul.22.1235346278298; Sun, 22 Feb 2009 15:44:38 -0800 (PST) In-Reply-To: <61dbdd7d0902221536m662a7605q915fa9c90563a2b@mail.gmail.com> References: <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> <61dbdd7d0902221536m662a7605q915fa9c90563a2b@mail.gmail.com> Date: Sun, 22 Feb 2009 18:44:38 -0500 Message-ID: From: Dan Olivares To: Gareth Nelson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 23:44:24 -0000 "Does primmesher support multiple LODs?", Yes, by defining the number of revolutions during the extrude and initial face verticies, it's possible to generate meshes at multiple levels of detail. "had a few anomalies in the final product" As far as I could tell (and, I've had experience with two different applications that use it OpenSimulator and IdealistViewer), the mesh is quite accurate. Last I checked, there was one shape where the extruded hollow had a UV anomoly. Best Regards Daniel Olivares On Sun, Feb 22, 2009 at 6:36 PM, Gareth Nelson wrote: > Does primmesher support multiple LODs? > Last I checked it was fairly simplistic in the way it created meshes > and had a few anomalies in the final product. > Bear in mind that I last played with this about 5 or 6 months ago. > > > On Sun, Feb 22, 2009 at 11:21 PM, Dan Olivares wrote: >> Since one of the topics we're discussing here is the inclusion of a >> universal object description for interoperability as a potential >> deliverable and the prim vs mesh debate was brought up, I wanted to >> bring up that there is a New BSD Licensed (MIT) library developed in >> C# for receiving LLPrim type object descriptions and converting them >> to a full mesh (with UV definitions) mostly developed by Tom Hoff. >> The current project location is: >> http://forge.opensimulator.org/gf/project/primmesher/ . >> >> This is relevant because it is a completely free, open, and tested >> code implementation of generating the mesh components of LLPrim. >> >> This letter is NOT to suggest that we SHOULD use LLPrim specifically >> in the standard. It does, however, demonstrate that there is code >> that anyone can refer to or use in working with the LLPrim parametric >> geometry type. LLPrim also has a specification for using a >> heightfield type graphic with several different mappings (that can be >> compressed) for producing a mesh that contains a maximum of 1024 >> verticies(32x32 heightfield) called the 'sculpted prim'. For more >> information on the sculpted prim, see: >> http://wiki.secondlife.com/wiki/Sculpted_Prims:_Technical_Explanation >> or refer to the implementation in PrimMesher. >> >> Best Regards >> >> Daniel Olivares >> >> On Sun, Feb 22, 2009 at 4:33 PM, Gareth Nelson wrote: >>> Of course, I was suggesting multiple LODs only when you actually >>> request them, not as something mandatory. >>> >>> On Sun, Feb 22, 2009 at 9:12 PM, Lawson English wrote: >>>> Gareth Nelson wrote: >>>>> >>>>> Just to nitpick, meshes and LCCs do work well together, just provide >>>>> different LODs :) >>>>> >>>> >>>> Well, the ideal thing is to be able to turn off graphical stuff completely. >>>> Text-based chat via a smartphone >>>> needs no graphical stuff, though navigating via the map system might be >>>> worth implementing. >>>> >>>> >>>> >>>> L >>>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > From gareth@litesim.com Sun Feb 22 16:23:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304E028C11E for ; Sun, 22 Feb 2009 16:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bgyUglZjtHu for ; Sun, 22 Feb 2009 16:23:44 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 8C66728C0F6 for ; Sun, 22 Feb 2009 16:23:44 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1588679rvb.49 for ; Sun, 22 Feb 2009 16:24:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.164.1 with SMTP id m1mr1739792rve.8.1235348640640; Sun, 22 Feb 2009 16:24:00 -0800 (PST) Date: Mon, 23 Feb 2009 00:24:00 +0000 Message-ID: <61dbdd7d0902221624k7f434619o2181672f781cdeeb@mail.gmail.com> From: Gareth Nelson To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mmox] (offtopic) jabber room on mmox@jabber.ietf.org X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 00:23:45 -0000 Anyone else having trouble connecting to jabber.ietf.org? I keep on getting service unavailable in multiple clients. I'm suspicious this may be due to my domain not being setup correctly though, trying to connect from gareth@garethnelson.com using my google talk account. From gareth@litesim.com Sun Feb 22 16:30:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76F23A6AE2 for ; Sun, 22 Feb 2009 16:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZD-9fRe9pTI for ; Sun, 22 Feb 2009 16:30:14 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 610293A6783 for ; Sun, 22 Feb 2009 16:30:14 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1590143rvb.49 for ; Sun, 22 Feb 2009 16:30:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.125.19 with SMTP id x19mr1728718rvc.187.1235349028908; Sun, 22 Feb 2009 16:30:28 -0800 (PST) In-Reply-To: <61dbdd7d0902221624k7f434619o2181672f781cdeeb@mail.gmail.com> References: <61dbdd7d0902221624k7f434619o2181672f781cdeeb@mail.gmail.com> Date: Mon, 23 Feb 2009 00:30:28 +0000 Message-ID: <61dbdd7d0902221630xeff311fvf4217ac3fdbd3aac@mail.gmail.com> From: Gareth Nelson To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] (offtopic) jabber room on mmox@jabber.ietf.org X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 00:30:15 -0000 Ignore this, it was a DNS issue - works fine with litesim.com after I setup SRV records On Mon, Feb 23, 2009 at 12:24 AM, Gareth Nelson wrote: > Anyone else having trouble connecting to jabber.ietf.org? > I keep on getting service unavailable in multiple clients. I'm > suspicious this may be due to my domain not being setup correctly > though, trying to connect from gareth@garethnelson.com using my google > talk account. > From jwatte@gmail.com Sun Feb 22 16:59:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EF1D3A6B34 for ; Sun, 22 Feb 2009 16:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Be7c8Gt-HQDD for ; Sun, 22 Feb 2009 16:59:11 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.157]) by core3.amsl.com (Postfix) with ESMTP id 7EB663A6B24 for ; Sun, 22 Feb 2009 16:59:11 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so5992697poe.4 for ; Sun, 22 Feb 2009 16:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ZeIsOYEsihFPgrsZ/i+8q303b407/xL8++n7k+3JQ18=; b=lFOoeSHnTjyFxjV+wIXFrxpyN5ifLfEXYMTVWoexIMypMplmdR/sr7r24/BezY0Vv1 pcjtvxKlutBr6vOPoFkWc3PPPOqJlV8yCTHAnXQ7ObJxxt+wIJ60G8JBot8vej1whXFs kEgRHYuDT6tsiDVlcLarXdjDeEO/QZUMuvkuY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hqJ6bBT5BxJDSN6hXcusfOP30rSdjjIWKa/cvbbD56QRdwCo3CDL1HDdQB7yOq5zGo 7rhicMGHK/8TZZ+W2JgjfGQIZkOiLFPbBHrDboJBAG9E5iS+QUHJ3GVIOOy16YROrdOv L+3QhjWypAsQ6zfUuuObmydvkaBMIFpU0llMs= Received: by 10.141.19.16 with SMTP id w16mr1738616rvi.146.1235350767629; Sun, 22 Feb 2009 16:59:27 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id g31sm12335143rvb.7.2009.02.22.16.59.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 16:59:27 -0800 (PST) Message-ID: <49A1F4EE.4000305@gmail.com> Date: Sun, 22 Feb 2009 16:59:26 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dan Olivares References: <499F3667.4000901@gmail.com> <244573.52942.qm@web82607.mail.mud.yahoo.com> <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 00:59:12 -0000 Dan Olivares wrote: > This is relevant because it is a completely free, open, and tested > code implementation of generating the mesh components of LLPrim. > The problem is that 95% of the world's 3D content is in mesh form. I'm thinking things like AutoCAD models for public buildings and offices, ESRI data for land, GIS data, and even the Google Warehouse. I hope you're not seriously suggesting that all of the world's CAD and 3D content be re-developed using Prims to be able to be imported into a virtual world? I agree that it's a solved problem to turn prims into meshes. However, it is not a solved problem to turn meshes into prims. Thus, meshes are the lowest common denominator, and anyone who wants to interoperate ought to be capable of understanding and generating meshes, because it's not reasonable to require that everyone can /generate/ prims. Sincerely, jw From gareth@litesim.com Sun Feb 22 17:01:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF1E3A6B34 for ; Sun, 22 Feb 2009 17:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4uZuqLj8dlY for ; Sun, 22 Feb 2009 17:01:57 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 9D05F3A6B08 for ; Sun, 22 Feb 2009 17:01:57 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1597879rvb.49 for ; Sun, 22 Feb 2009 17:02:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.197.21 with SMTP id z21mr1730638rvp.267.1235350933781; Sun, 22 Feb 2009 17:02:13 -0800 (PST) In-Reply-To: <49A1F4EE.4000305@gmail.com> References: <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> <49A1F4EE.4000305@gmail.com> Date: Mon, 23 Feb 2009 01:02:13 +0000 Message-ID: <61dbdd7d0902221702x5bcbc921i5b75be7fc3ad410e@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 01:01:58 -0000 Ironically (given LL's heavy involvement) this means SL is in for major changes in order to join in if meshes are to become a mandatory part of the standard. Of course, SL could just keep prims and add meshes as an extra, but by that point you might as well drop prims completely at the protocol level (the UI of course can maintain prims still). On Mon, Feb 23, 2009 at 12:59 AM, Jon Watte wrote: > Dan Olivares wrote: >> >> This is relevant because it is a completely free, open, and tested >> code implementation of generating the mesh components of LLPrim. >> > > The problem is that 95% of the world's 3D content is in mesh form. I'm > thinking things like AutoCAD models for public buildings and offices, ESRI > data for land, GIS data, and even the Google Warehouse. I hope you're not > seriously suggesting that all of the world's CAD and 3D content be > re-developed using Prims to be able to be imported into a virtual world? > > I agree that it's a solved problem to turn prims into meshes. However, it is > not a solved problem to turn meshes into prims. Thus, meshes are the lowest > common denominator, and anyone who wants to interoperate ought to be capable > of understanding and generating meshes, because it's not reasonable to > require that everyone can /generate/ prims. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From gareth@litesim.com Sun Feb 22 17:09:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CC328C1B0 for ; Sun, 22 Feb 2009 17:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pthbx5I50KTu for ; Sun, 22 Feb 2009 17:09:03 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 09D8E28C11E for ; Sun, 22 Feb 2009 17:09:02 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1599696rvb.49 for ; Sun, 22 Feb 2009 17:09:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.180.5 with SMTP id h5mr1749322rvp.51.1235351359675; Sun, 22 Feb 2009 17:09:19 -0800 (PST) In-Reply-To: <49A1D327.90502@gmail.com> References: <697430.23835.qm@web82605.mail.mud.yahoo.com> <49A1A158.3020605@gmail.com> <61dbdd7d0902221113l7309d7abk1996ed04640a4b7a@mail.gmail.com> <49A1B2AE.10804@gmail.com> <61dbdd7d0902221224o47b1ebdai1c3dd0ef22b52523@mail.gmail.com> <49A1BAA0.7080702@gmail.com> <61dbdd7d0902221332s442d0dadm6661a836cdbfcb25@mail.gmail.com> <49A1D327.90502@gmail.com> Date: Mon, 23 Feb 2009 01:09:19 +0000 Message-ID: <61dbdd7d0902221709p7c75da15h76bda440057d9c6b@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 01:09:03 -0000 On Sun, Feb 22, 2009 at 10:35 PM, Jon Watte wrote: > Gareth Nelson wrote: >> >> This is turning into a "what can we do in virtual worlds that can't be >> done with web browsers?", to which i'll respond "nothing, since we can >> put virtual worlds into browsers", but that's irrelevant essentially. >> > > That's not actually true, because there are things you can do with a virtual > world interoperability protocol used between server peers, that you can't do > in a browser-only world. That server peer system is what I'm hoping to > accomplish here. Anything that is client-only is unlikely to provide much > added value, and unlikely to be adopted by most of the various vendors in > the market, for reasons I've already discussed at length on this list. Given > the lack of added value in client standardization work for virtual worlds, I > view work on that as wasted effort. My point was that "browser-only" still really involves "browser with plugins". But going off into web browser plugins is not of relevance to the question of a standardised client/server protocol. What "value" does it add to email to have multiple email clients and servers, what value does it add to IRC to have different IRC clients? I can answer that one easily: Bots, automated scripts, different UIs, different platforms >> But of course, my point was that these plugins still need the standard >> protocols, the above example is just SL in a browser for example. >> > > They don't need any new standard protocols, because you already have a > standard execution environment (the browser, with a DOM, JavaScript, and a > plug-in model), and the standard transport (using HTTP). For anything > "additional" they can use a custom protocol; there is no need to standardize > there. To the user, any browser-based VWs will already appear "standard" > because the user can use the browser to surf from one to the other. However, > that just doesn't add much value -- as evidenced by most systems not > actually doing that. But they can't go from one to the other using the same UI - the UI is defined in the HTML and can't be altered most of the time. Nor can things be automated or easily ported to other platforms where plugins are required. To make this even more clear, I often alternate between irssi and ksirc for using IRC, while connecting to freenode, efnet and my own network. This is impossible to do with virtual worlds unless they support one standard protocol for client interaction. Hence where the value for client<>server standard protocols comes. From tme@multicasttech.com Sun Feb 22 17:36:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61D9B3A6844 for ; Sun, 22 Feb 2009 17:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.569 X-Spam-Level: X-Spam-Status: No, score=-103.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALDmrqeBhZVn for ; Sun, 22 Feb 2009 17:36:45 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 5F1573A67A8 for ; Sun, 22 Feb 2009 17:36:45 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14746954; Sun, 22 Feb 2009 20:34:58 -0500 Message-Id: <417A7D30-754B-4E1A-BDC7-82163169C37C@multicasttech.com> From: Marshall Eubanks To: Gareth Nelson In-Reply-To: <61dbdd7d0902221624k7f434619o2181672f781cdeeb@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 22 Feb 2009 20:36:54 -0500 References: <61dbdd7d0902221624k7f434619o2181672f781cdeeb@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] (offtopic) jabber room on mmox@jabber.ietf.org X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 01:36:46 -0000 Seems ok at 8:36 PM EST. Marshall On Feb 22, 2009, at 7:24 PM, Gareth Nelson wrote: > Anyone else having trouble connecting to jabber.ietf.org? > I keep on getting service unavailable in multiple clients. I'm > suspicious this may be due to my domain not being setup correctly > though, trying to connect from gareth@garethnelson.com using my google > talk account. > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From eh2th-mmox@yahoo.com Sun Feb 22 18:12:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D62F3A68F5 for ; Sun, 22 Feb 2009 18:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CTDR57hOQv0 for ; Sun, 22 Feb 2009 18:12:08 -0800 (PST) Received: from web65711.mail.ac4.yahoo.com (web65711.mail.ac4.yahoo.com [76.13.9.103]) by core3.amsl.com (Postfix) with SMTP id 6E4473A68B4 for ; Sun, 22 Feb 2009 18:12:08 -0800 (PST) Received: (qmail 23958 invoked by uid 60001); 23 Feb 2009 02:12:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=MmPDR0EesjHsiKK8OpzPJqBjAiaKRCUH+lg+QxUw3ko7YhorCN/p3XgASOHdQHpDqZqAp0IOKAU2c9c6jHlf3aEI6rkTsAjDaiZaQTOSrTXTmJhhQ536WAyvppP5XRhG3pidWWlm3ghhGq+GCaclXpAb7JP/bZYrRaBAXztyg6M=; X-YMail-OSG: zESLPucVM1n8C3eWvQ7MJQIru_AP311OTa4mSGP5QUEyasc96N.rCCqZXFhVSRUJZ1QTjkbOpWsXA48qXY1dygE0menAIv38j1JeWnqU7.L94EY1tv7HtiN1YaO8l1zBwqxAVlRzebXcnrmRwllwuqK7hAD0PQ2b.dDrG4K2j7AA4GVlB59kpA5EBOgqzz4Il53Kp.M77jmNdstZQYSqHB_sHQ-- Received: from [72.220.236.152] by web65711.mail.ac4.yahoo.com via HTTP; Sun, 22 Feb 2009 18:12:25 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> <49A1F4EE.4000305@gmail.com> <61dbdd7d0902221702x5bcbc921i5b75be7fc3ad410e@mail.gmail.com> Date: Sun, 22 Feb 2009 18:12:25 -0800 (PST) From: eh2th-mmox@yahoo.com To: Gareth Nelson , Jon Watte MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <127984.23284.qm@web65711.mail.ac4.yahoo.com> Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 02:12:09 -0000 Then again it could be argued that prims offer Linden Lab a way for it's users to easily create and share objects without first learning more traditional modeling methods. I suspect that prims may also reduce storage costs for these shared objects as well as reduce over the wire bandwidth requirements It seems though that LL would need to add a traditional mesh display capability to any viewer they chose to use for interoperating with other worlds, but they may not necessarily need to add it to their current service. --Tom ----- Original Message ---- From: Gareth Nelson To: Jon Watte Cc: "mmox@ietf.org" Sent: Sunday, February 22, 2009 5:02:13 PM Subject: Re: [mmox] Learning from the past; focusing on the future Ironically (given LL's heavy involvement) this means SL is in for major changes in order to join in if meshes are to become a mandatory part of the standard. Of course, SL could just keep prims and add meshes as an extra, but by that point you might as well drop prims completely at the protocol level (the UI of course can maintain prims still). On Mon, Feb 23, 2009 at 12:59 AM, Jon Watte wrote: > Dan Olivares wrote: >> >> This is relevant because it is a completely free, open, and tested >> code implementation of generating the mesh components of LLPrim. >> > > The problem is that 95% of the world's 3D content is in mesh form. I'm > thinking things like AutoCAD models for public buildings and offices, ESRI > data for land, GIS data, and even the Google Warehouse. I hope you're not > seriously suggesting that all of the world's CAD and 3D content be > re-developed using Prims to be able to be imported into a virtual world? > > I agree that it's a solved problem to turn prims into meshes. However, it is > not a solved problem to turn meshes into prims. Thus, meshes are the lowest > common denominator, and anyone who wants to interoperate ought to be capable > of understanding and generating meshes, because it's not reasonable to > require that everyone can /generate/ prims. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox From gareth@litesim.com Sun Feb 22 18:39:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B67A43A6AA5 for ; Sun, 22 Feb 2009 18:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gu4cL+dyrdUQ for ; Sun, 22 Feb 2009 18:39:21 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id CED0D3A696A for ; Sun, 22 Feb 2009 18:39:21 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1625771rvb.49 for ; Sun, 22 Feb 2009 18:39:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.147.18 with SMTP id u18mr879272rvd.105.1235356778120; Sun, 22 Feb 2009 18:39:38 -0800 (PST) In-Reply-To: <127984.23284.qm@web65711.mail.ac4.yahoo.com> References: <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> <49A1F4EE.4000305@gmail.com> <61dbdd7d0902221702x5bcbc921i5b75be7fc3ad410e@mail.gmail.com> <127984.23284.qm@web65711.mail.ac4.yahoo.com> Date: Mon, 23 Feb 2009 02:39:38 +0000 Message-ID: <61dbdd7d0902221839h70bd1bd3xa7cbb2d233c98b98@mail.gmail.com> From: Gareth Nelson To: eh2th-mmox@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 02:39:22 -0000 They could of course prevent users from creating mesh objects locally, but that seems like a rather arbitary limitation. Can we have a linden speak to this? On Mon, Feb 23, 2009 at 2:12 AM, wrote: > Then again it could be argued that prims offer Linden Lab a way for it's = users to easily create and share objects without first learning more tradit= ional modeling methods. I suspect that prims may also reduce storage costs = for these shared objects as well as reduce over the wire bandwidth requirem= ents > > It seems though that LL would need to add a traditional mesh display capa= bility to any viewer they chose to use for interoperating with other worlds= , but they may not necessarily need to add it to their current service. > > --Tom > > > ----- Original Message ---- > From: Gareth Nelson > To: Jon Watte > Cc: "mmox@ietf.org" > Sent: Sunday, February 22, 2009 5:02:13 PM > Subject: Re: [mmox] Learning from the past; focusing on the future > > Ironically (given LL's heavy involvement) this means SL is in for > major changes in order to join in if meshes are to become a mandatory > part of the standard. > > Of course, SL could just keep prims and add meshes as an extra, but by > that point you might as well drop prims completely at the protocol > level (the UI of course can maintain prims still). > > On Mon, Feb 23, 2009 at 12:59 AM, Jon Watte wrote: >> Dan Olivares wrote: >>> >>> This is relevant because it is a completely free, open, and tested >>> code implementation of generating the mesh components of LLPrim. >>> >> >> The problem is that 95% of the world's 3D content is in mesh form. I'm >> thinking things like AutoCAD models for public buildings and offices, ES= RI >> data for land, GIS data, and even the Google Warehouse. I hope you're no= t >> seriously suggesting that all of the world's CAD and 3D content be >> re-developed using Prims to be able to be imported into a virtual world? >> >> I agree that it's a solved problem to turn prims into meshes. However, i= t is >> not a solved problem to turn meshes into prims. Thus, meshes are the low= est >> common denominator, and anyone who wants to interoperate ought to be cap= able >> of understanding and generating meshes, because it's not reasonable to >> require that everyone can /generate/ prims. >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From jwatte@gmail.com Sun Feb 22 20:06:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0346D3A6810 for ; Sun, 22 Feb 2009 20:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGoUfms2alQy for ; Sun, 22 Feb 2009 20:06:38 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235]) by core3.amsl.com (Postfix) with ESMTP id 3F5C53A67A1 for ; Sun, 22 Feb 2009 20:06:38 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1652581rvb.49 for ; Sun, 22 Feb 2009 20:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rb3SoUMMuqj3/qS3aIx0iSz593nUxbVC5KLwkiHVLUU=; b=kxpp0MfhSHp8UyWKhemxhzmGQ52EMgQCUP+9u59WXy9p69P3XdtOv88h0FThZTAFND uta9XbcdzBECmOvJXGnpScyWJn53Fp+jqn+Wvt+KybOLSbHaGrX+ddF4JHJuCLoF/9aJ HPkbeYmAjqJE9Qv7e2vV0RHPNNd/u8FUczvSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=HTmVo9R2vjZ9szpjfwYJOzkiQzQn27zdjTJVwFl2iOJ2pVeeql39d0oXsspbxVKDyD R5GtmxcQQxhv908qC4thauRwIievomXzwqZupyL9gOtSzXR2YsputbN1zugL9WsIfbSs lv9Lj/LjccFm6kuXC7moQurBXZY19TqQnctUE= Received: by 10.140.248.15 with SMTP id v15mr1805944rvh.165.1235362015240; Sun, 22 Feb 2009 20:06:55 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id f42sm5914464rvb.3.2009.02.22.20.06.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 20:06:54 -0800 (PST) Message-ID: <49A220DD.2020300@gmail.com> Date: Sun, 22 Feb 2009 20:06:53 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> <49A1F4EE.4000305@gmail.com> <61dbdd7d0902221702x5bcbc921i5b75be7fc3ad410e@mail.gmail.com> In-Reply-To: <61dbdd7d0902221702x5bcbc921i5b75be7fc3ad410e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 04:06:39 -0000 Gareth Nelson wrote: > Ironically (given LL's heavy involvement) this means SL is in for > major changes in order to join in if meshes are to become a mandatory > part of the standard. > > It seems unavoidable that SL and derived technologies would get meshes at some level, yes. I don't think users would be particularly mad, though ;-) > Of course, SL could just keep prims and add meshes as an extra, but by > that point you might as well drop prims completely at the protocol > level (the UI of course can maintain prims still). > I fully expect prims to remain within the SL system as a first class citizen. Their claim is that sending an object based on a prim recipe uses less bandwidth than sending the prim recipe "cooked" as a mesh, and I see no reason to doubt that claim. (Whether a custom-built mesh would be more or less compact is a different question, the answer to which is "it depends.") In fact, for the case where SL talks to OpenSim, or some other SL derived technology, I would expect them to negotiate to exchange only prims and not meshes. Meanwhile, some subset of prims may very well make for a suitable physics proxy representation even for objects that are complex meshes at their core. It is quite common for mesh-based systems to only actually use concave physics meshes for static geometry, and use proxy shapes (like boxes, spheres, capsules and convex hulls) for physics. Anyway, that's the background that makes me believe that one fundament of object interoperability is that everyone must understand meshes at some level, and then you can add as much negotiated fancy on top as you want. Sincerely, jw From jwatte@gmail.com Sun Feb 22 20:14:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DF3D3A696A for ; Sun, 22 Feb 2009 20:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9-wETvunwSB for ; Sun, 22 Feb 2009 20:14:16 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 7A1633A68D4 for ; Sun, 22 Feb 2009 20:14:16 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1654892rvb.49 for ; Sun, 22 Feb 2009 20:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=odAJC7B8SaX72FneXEOxVVdnflyGo0gX6cM8jREQDRQ=; b=TvFmXSK8+PWulwxWYRf//awgch6l2W0rja977mHpNzlmu+xFVZxHE6r1fSQIRuJ2nT gzHV8pDEhn4RFlEzHvj0ZdCI2tGhKnQZAhSK35uJuAO7fKnmNXAG0SyQcCFqVFzKAkWx aJmgspJaxRBSdTpaOVCQ4Aag2vvZvr/366Zok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=tOZ9AFrpTdzudeRIklDFxoSSna34qP9IkmEdeWeT6KEswLah2MY0+lhn6D7jdSKCCa 2AwddTwv3IDi/inwaYSDh1hpjZAgcLL+wj8Tmus2ywy/2hswBXy4EdifjfVtXI2dbj0y /2H1dUH8x53IuT6Oz2WP1ZQ/krEYddxKQrrLM= Received: by 10.141.154.8 with SMTP id g8mr1805322rvo.235.1235362472857; Sun, 22 Feb 2009 20:14:32 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b39sm5894636rvf.9.2009.02.22.20.14.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 20:14:32 -0800 (PST) Message-ID: <49A222A7.7040309@gmail.com> Date: Sun, 22 Feb 2009 20:14:31 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <697430.23835.qm@web82605.mail.mud.yahoo.com> <49A1A158.3020605@gmail.com> <61dbdd7d0902221113l7309d7abk1996ed04640a4b7a@mail.gmail.com> <49A1B2AE.10804@gmail.com> <61dbdd7d0902221224o47b1ebdai1c3dd0ef22b52523@mail.gmail.com> <49A1BAA0.7080702@gmail.com> <61dbdd7d0902221332s442d0dadm6661a836cdbfcb25@mail.gmail.com> <49A1D327.90502@gmail.com> <61dbdd7d0902221709p7c75da15h76bda440057d9c6b@mail.gmail.com> In-Reply-To: <61dbdd7d0902221709p7c75da15h76bda440057d9c6b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 04:14:17 -0000 Gareth Nelson wrote: > Hence where the value for client<>server standard protocols comes. > Well, you'd better buy stock in Multiverse, then, because that's exactly their approach to the world. Define one client protocol, and let developers build whatever they want on the back end. Personally, I believe that the case of interactive simulation actually makes it a different animal entirely from a web browser. I don't think you can define a common client protocol, unless you define: - a common simulation language - a common simulation API - a common world semantic - a common scene graph (good luck on that :-) - a common user interface language - a common distribution model You should know that VRML actually attempted to specify all that back in 1995 -- it actually solves that particular problem(!). There's a modern version of it called X3D, which has been updated since 1995. However, most people don't care, because that's not the important problems to solve, according to the market. The applications deployed today have very different approaches to these rather heavy-weight areas, for good reason: they serve different customers. Trying to unify them all is unlikely to be realistic anytime soon. If you think they should be, you should be arguing for VRML/X3D, because it's an existing W3C standard that does just that! Sincerely, jw From lenglish5@cox.net Sun Feb 22 20:53:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7773A685E for ; Sun, 22 Feb 2009 20:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.749 X-Spam-Level: X-Spam-Status: No, score=0.749 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQvblDmOBmME for ; Sun, 22 Feb 2009 20:53:49 -0800 (PST) Received: from fed1rmmtao104.cox.net (fed1rmmtao104.cox.net [68.230.241.42]) by core3.amsl.com (Postfix) with ESMTP id 547023A6784 for ; Sun, 22 Feb 2009 20:53:49 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090223045405.YLYI16134.fed1rmmtao104.cox.net@fed1rmimpo02.cox.net>; Sun, 22 Feb 2009 23:54:05 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id KGu41b0034N6T0Q04Gu4Kt; Sun, 22 Feb 2009 23:54:04 -0500 X-Authority-Analysis: v=1.0 c=1 a=OWsrh9V_QYAA:10 a=PQp3fo3PBBsA:10 a=Wajolswj7cQA:10 a=YYfYW692mghmdWMKu0gA:9 a=bWO5YHfINP1fD2jp5ZPhGwHC_VYA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <49A22BEC.6090902@cox.net> Date: Sun, 22 Feb 2009 21:54:04 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <697430.23835.qm@web82605.mail.mud.yahoo.com> <49A1A158.3020605@gmail.com> <61dbdd7d0902221113l7309d7abk1996ed04640a4b7a@mail.gmail.com> <49A1B2AE.10804@gmail.com> <61dbdd7d0902221224o47b1ebdai1c3dd0ef22b52523@mail.gmail.com> <49A1BAA0.7080702@gmail.com> <61dbdd7d0902221332s442d0dadm6661a836cdbfcb25@mail.gmail.com> <49A1D327.90502@gmail.com> <61dbdd7d0902221709p7c75da15h76bda440057d9c6b@mail.gmail.com> <49A222A7.7040309@gmail.com> In-Reply-To: <49A222A7.7040309@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 04:53:50 -0000 Jon Watte wrote: > Gareth Nelson wrote: >> Hence where the value for client<>server standard protocols comes. >> > > Well, you'd better buy stock in Multiverse, then, because that's > exactly their approach to the world. Define one client protocol, and > let developers build whatever they want on the back end. > > Personally, I believe that the case of interactive simulation actually > makes it a different animal entirely from a web browser. I don't think > you can define a common client protocol, unless you define: > > - a common simulation language > - a common simulation API > - a common world semantic > - a common scene graph (good luck on that :-) > - a common user interface language > - a common distribution model > > You should know that VRML actually attempted to specify all that back > in 1995 -- it actually solves that particular problem(!). There's a > modern version of it called X3D, which has been updated since 1995. > However, most people don't care, because that's not the important > problems to solve, according to the market. > > The applications deployed today have very different approaches to > these rather heavy-weight areas, for good reason: they serve different > customers. Trying to unify them all is unlikely to be realistic > anytime soon. If you think they should be, you should be arguing for > VRML/X3D, because it's an existing W3C standard that does just that! > > Sincerely, Ah, but does it do prims? L From MysticalDemina@xrgrid.com Sun Feb 22 22:49:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C9F3A68D2 for ; Sun, 22 Feb 2009 22:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLiahi8y+6Ez for ; Sun, 22 Feb 2009 22:49:26 -0800 (PST) Received: from k2smtpout01-01.prod.mesa1.secureserver.net (k2smtpout01-01.prod.mesa1.secureserver.net [64.202.189.88]) by core3.amsl.com (Postfix) with SMTP id 639263A677C for ; Sun, 22 Feb 2009 22:49:26 -0800 (PST) Received: (qmail 7828 invoked from network); 23 Feb 2009 06:49:43 -0000 Received: from unknown (HELO TWEEDY001.kevin-tweedy.com) (68.178.225.179) by k2smtpout01-01.prod.mesa1.secureserver.net (64.202.189.88) with ESMTP; 23 Feb 2009 06:49:43 -0000 Received: from KEVINPC ([173.49.10.182]) by kevin-tweedy.com with MailEnable ESMTP; Sun, 22 Feb 2009 23:49:43 -0700 From: "Mystical Demina" To: Date: Mon, 23 Feb 2009 01:49:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C3_01C99558.EE70CB80" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmVgtaLepik2V/rRru+ZHIpbipKPQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 06:49:31 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C3_01C99558.EE70CB80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Seems to be this discussion on whether to support meshes or prims is interesting but if the goal is to have an interoperable protocol between systems that we should be looking at a higher level abstraction in which to define the semantics between systems and talk in more general terms at first such as defining a collection of abstractions of which there could exist an object, objects could have a name, a type and a body or a reference to its details. The type would be something like the MIME type we use on web pages. Then it would be up to virtual worlds to support the MIME types that they would like to support. Could even get more complicated as things grow for a system to make available a list of types it supports. If Lindens would like to have prims supported as one of those types they can submit a MIME type and the specification for it. Also to just say because most of the work is meshes as well isn't the best either. There are tons of mesh standards, OBJ, etc. I think until we define things in these terms the actual physical protocols don't do us much good. Seems there are some basic problems that could be tacked first like the URL that define locations in a virtual world. Can't teleport till we define where we are teleporting to. Once we can define a location then we can talk about context and types of data that we wish to exchange. There are a lot of things that already exist in the web that I think we can look to implement like anonymous access, cookies so when we return to a location we don't have to log in again. Kevin Tweedy http://www.XRGrid.com SL: Mystical Demina ------=_NextPart_000_00C3_01C99558.EE70CB80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Seems to be this discussion on whether to support = meshes or prims is interesting but if the goal is to have an interoperable = protocol between systems that we should be looking at a higher level abstraction in which = to define the semantics between systems and talk in more general terms at first = such as defining a collection of abstractions of which there could exist an object, = objects could have a name, a type and a body or a reference to its details.  The = type would be something like the MIME type we use on web pages.  Then it would be = up to virtual worlds to support the MIME types that they would like to = support.  Could even get more complicated as things grow for a system to make = available a list of types it supports.  If Lindens would like to have prims = supported as one of those types they can submit a MIME type and the specification for = it.  Also to just say because most of the work is meshes as well isn’t the = best either.  There are tons of mesh standards, OBJ, = etc.

 

I think until we define things in these terms the = actual physical protocols don’t do us much = good.

 

Seems there are some basic problems that could be = tacked first like the URL that define locations in a virtual world.  = Can’t teleport till we define where we are teleporting to.  Once we can = define a location then we can talk about context and types of data that we wish = to exchange.  There are a lot of things that already exist in the web = that I think we can look to implement like anonymous access, cookies so when we = return to a location we don’t have to log in = again.

 

Kevin Tweedy

http://www.XRGrid.com

SL: Mystical Demina

 

------=_NextPart_000_00C3_01C99558.EE70CB80-- From jwatte@gmail.com Sun Feb 22 23:28:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB2B3A681D for ; Sun, 22 Feb 2009 23:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd-M4WCo7sya for ; Sun, 22 Feb 2009 23:28:01 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 009C53A67A1 for ; Sun, 22 Feb 2009 23:28:00 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1715184rvb.49 for ; Sun, 22 Feb 2009 23:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Xwpkh/fCVfHPBPVsr2nEPVUlKH39s8ePSKVOKRbxQoo=; b=d7I5ocHLCPnK9co3OoBCXy4F33/Nel1nve2IExGkqjX6EJ56Azs34Cn8dDQbEd9LVg MvaByaLW699zCLId6c8/vN41eUG++eF3bEGnbOHlk9lVSfxc5DPURR8Uis3kgRuwgBqR pOrPm8v3lnEq3BNqHYir1U7vvesfUwJ2l+OeU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DliZu8TXObK65rEdFdwzE730DRZPLXQGaqn84FoQ2DebqFHPbG9eP3xEfbnJV3RAm4 JlQ52PXpXcYKYJiy+0iYFySM0hob/JosRnUgCwGf3r1++h5Ih0rgUdsB9CTdALhPHyTQ lsEgGfPlStkQvXMmjXmPJUXgy2cdxqt+PgXxg= Received: by 10.141.122.20 with SMTP id z20mr1894259rvm.171.1235374097476; Sun, 22 Feb 2009 23:28:17 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id c20sm6116216rvf.1.2009.02.22.23.28.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 23:28:17 -0800 (PST) Message-ID: <49A2500F.3000104@gmail.com> Date: Sun, 22 Feb 2009 23:28:15 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mystical Demina References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 07:28:01 -0000 Mystical Demina wrote: > > I think until we define things in these terms the actual physical > protocols don’t do us much good. > There have actually been a lot of those proposals on the list already. The reason we're talking about meshes vs prims is to make the point that /only/ specifying the mechanism is not sufficient to actually achieve interoperability; specifying a reliable minimum capability for each mechanism ("if you support the mechanism, you support at least this format") is necessary for actual interoperability. Meshes just turned out to be one of the illustrative examples of why this is so. I think the /first/ thing we need to decide is whether we're building: 1) A protocol that lets some number of second-life derived client softwares cross-connect to some number of second-life derived services, possibly bringing along some number of second-life derived assets (I've heard proposals that boil down to this from a few people) or 2) A protocol that lets significantly different virutal world systems interoperate to share in creating a single, bigger, more diverse simulation (Some other people, including me, are presenting proposals along these lines). However, right now, I don't even think we know how to make that decision. We need to make this decision, so that the people who aren't interested in "the other" approach can properly decide where and how to spend time and resources. Sincerely, jw Sincerely, jw From gareth@litesim.com Sun Feb 22 23:52:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C523A6806 for ; Sun, 22 Feb 2009 23:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19LY7g74IWlw for ; Sun, 22 Feb 2009 23:52:00 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.155]) by core3.amsl.com (Postfix) with ESMTP id 21F263A67A1 for ; Sun, 22 Feb 2009 23:52:00 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6338502poe.4 for ; Sun, 22 Feb 2009 23:52:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.161.11 with SMTP id j11mr1919423rve.15.1235375536422; Sun, 22 Feb 2009 23:52:16 -0800 (PST) In-Reply-To: <49A220DD.2020300@gmail.com> References: <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> <49A1F4EE.4000305@gmail.com> <61dbdd7d0902221702x5bcbc921i5b75be7fc3ad410e@mail.gmail.com> <49A220DD.2020300@gmail.com> Date: Mon, 23 Feb 2009 07:52:16 +0000 Message-ID: <61dbdd7d0902222352h749ab41duf7ee1c32ba801087@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 07:52:01 -0000 We were discussing the prims vs meshes issue in the chatroom earlier, and I noted that we have no hard numbers on which takes up more bytes: prims or meshes. To clarify, it's possible an optimised mesh could be more efficient than the same build described in terms of prims. What I proposed there was to treat the prims like source code, and the mesh like object code. But the source code also include other "block types". Basically, when placing a prim you just deform a standard mesh and use it as one of your blocks, then for sending over the wire you send the "baked" mesh. This may be more inefficient for some scenarios, but it's much more compatible for systems that might not render prims the same way or even support them. On Mon, Feb 23, 2009 at 4:06 AM, Jon Watte wrote: > Gareth Nelson wrote: >> >> Ironically (given LL's heavy involvement) this means SL is in for >> major changes in order to join in if meshes are to become a mandatory >> part of the standard. >> >> > > It seems unavoidable that SL and derived technologies would get meshes at > some level, yes. I don't think users would be particularly mad, though ;-) > >> Of course, SL could just keep prims and add meshes as an extra, but by >> that point you might as well drop prims completely at the protocol >> level (the UI of course can maintain prims still). >> > > I fully expect prims to remain within the SL system as a first class > citizen. Their claim is that sending an object based on a prim recipe uses > less bandwidth than sending the prim recipe "cooked" as a mesh, and I see no > reason to doubt that claim. (Whether a custom-built mesh would be more or > less compact is a different question, the answer to which is "it depends.") > In fact, for the case where SL talks to OpenSim, or some other SL derived > technology, I would expect them to negotiate to exchange only prims and not > meshes. > > Meanwhile, some subset of prims may very well make for a suitable physics > proxy representation even for objects that are complex meshes at their core. > It is quite common for mesh-based systems to only actually use concave > physics meshes for static geometry, and use proxy shapes (like boxes, > spheres, capsules and convex hulls) for physics. > > Anyway, that's the background that makes me believe that one fundament of > object interoperability is that everyone must understand meshes at some > level, and then you can add as much negotiated fancy on top as you want. > > Sincerely, > > jw > > From gareth@litesim.com Sun Feb 22 23:54:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7AC728C1B0 for ; Sun, 22 Feb 2009 23:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of-BD1NtZrV6 for ; Sun, 22 Feb 2009 23:54:12 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.159]) by core3.amsl.com (Postfix) with ESMTP id 2F3C83A67A1 for ; Sun, 22 Feb 2009 23:54:12 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6340909poe.4 for ; Sun, 22 Feb 2009 23:54:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.115.20 with SMTP id s20mr1914597rvm.70.1235375668680; Sun, 22 Feb 2009 23:54:28 -0800 (PST) In-Reply-To: <49A2500F.3000104@gmail.com> References: <49A2500F.3000104@gmail.com> Date: Mon, 23 Feb 2009 07:54:28 +0000 Message-ID: <61dbdd7d0902222354y4f41058fufcb1426b9f95bf84@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mystical Demina , mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 07:54:12 -0000 > 1) A protocol that lets some number of second-life derived client softwares > cross-connect to some number of second-life derived services, possibly > bringing along some number of second-life derived assets (I've heard > proposals that boil down to this from a few people) > I think this is to be avoided, for obvious reasons (i.e SL-bias) > 2) A protocol that lets significantly different virutal world systems > interoperate to share in creating a single, bigger, more diverse simulation > (Some other people, including me, are presenting proposals along these > lines). This is where the future lies > However, right now, I don't even think we know how to make that decision. We > need to make this decision, so that the people who aren't interested in "the > other" approach can properly decide where and how to spend time and > resources. We definitely need more agreement on the basics of what kinds of world and how specific the standards should be. There's a tradeoff between biasing towards 1 kind of world and compatibility with all worlds. From eh2th-mmox@yahoo.com Sun Feb 22 23:58:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39F983A68A8 for ; Sun, 22 Feb 2009 23:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68v1DMMogtAM for ; Sun, 22 Feb 2009 23:58:12 -0800 (PST) Received: from web65716.mail.ac4.yahoo.com (web65716.mail.ac4.yahoo.com [76.13.9.108]) by core3.amsl.com (Postfix) with SMTP id 272563A67A1 for ; Sun, 22 Feb 2009 23:58:12 -0800 (PST) Received: (qmail 10390 invoked by uid 60001); 23 Feb 2009 07:58:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=ftQvr4aO/vKUfcNsX/PFka+fP6ME4+j7CXMAM5qq66cb5aQvd2UI3wqZun+5+9GtgxA4ocDpdkym3O4DiNpPNWxWEI1wIpq7NOm64tmp0XJB4X3kw0mAV5Nz1f42TWwSHunKXz7SVlNtdGgc30fmp0bXy7bWvm01eZr38dGcU6k=; X-YMail-OSG: tKzxuTEVM1mVKJCrCAmpZ9E93YYycWPzz.j0dplE_R5xd9h9aHIBAzYWtI9GN1t35sd14rOyKIdIIigA37ynmT5IO52eB2hy34zzG_tRcjCV4UWXpTV5P9L006pn1423HVxsm8pinS_GrW_h82KMZ21F7CN0FYJPdtOx03drMxcSsEibAWdf2Rbh3XJ1D1izUmEwEwXzAzYZFP5QfY7JGsD1sA-- Received: from [72.220.236.152] by web65716.mail.ac4.yahoo.com via HTTP; Sun, 22 Feb 2009 23:58:29 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <499F5220.5010207@gmail.com> <49A04FBE.2080504@gmail.com> <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> <49A1F4EE.4000305@gmail.com> <61dbdd7d0902221702x5bcbc921i5b75be7fc3ad410e@mail.gmail.com> <49A220DD.2020300@gmail.com> Date: Sun, 22 Feb 2009 23:58:29 -0800 (PST) From: eh2th-mmox@yahoo.com To: Jon Watte , Gareth Nelson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <566568.8998.qm@web65716.mail.ac4.yahoo.com> Cc: "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 07:58:13 -0000 I can't speak for the SecondLife (SL) implementation as it's a black box to me, but from my collision tests, I am inclined to believe that since SL implemented the Havok 4 physics engine on their servers, that they are using fairly high level of detail mesh representations of their prims for proxies. In OpenSim, if the Open Dynamics (ODE) physics engine is configured, and if the "Meshmerizer" option is chosen, then the prim proxies are meshed by the PrimMesher library at a fairly high level of detail which approaches the highest level of detail in the second life viewer. This configuration has been somewhat optimized over the last several months to yield quite reasonable performance for collisions and memory usage. There are some cases where internal ODE representations of proxies are still used: when prims are simple boxes or spheres. "Sculpties", or sculpted prims, are a newer feature in SL which can display simple mesh objects. SL uses simple proxies for sculpties, and many content creators simply mark them as "Phantom" and then use regular prims inside the sculptie to make a user defined proxy. OpenSim has added an experimental feature where a low level of detail sculptie mesh can also be used as a proxy. This seems to work well in many cases, however users are becoming more clever at making increasingly complex sculpties, and due to the limited level of detail, the resulting mesh collision proxy can often differ significantly in shape. --Tom ----- Original Message ---- From: Jon Watte To: Gareth Nelson Cc: "mmox@ietf.org" Sent: Sunday, February 22, 2009 8:06:53 PM Subject: Re: [mmox] Learning from the past; focusing on the future Gareth Nelson wrote: > Ironically (given LL's heavy involvement) this means SL is in for > major changes in order to join in if meshes are to become a mandatory > part of the standard. > > It seems unavoidable that SL and derived technologies would get meshes at some level, yes. I don't think users would be particularly mad, though ;-) > Of course, SL could just keep prims and add meshes as an extra, but by > that point you might as well drop prims completely at the protocol > level (the UI of course can maintain prims still). > I fully expect prims to remain within the SL system as a first class citizen. Their claim is that sending an object based on a prim recipe uses less bandwidth than sending the prim recipe "cooked" as a mesh, and I see no reason to doubt that claim. (Whether a custom-built mesh would be more or less compact is a different question, the answer to which is "it depends.") In fact, for the case where SL talks to OpenSim, or some other SL derived technology, I would expect them to negotiate to exchange only prims and not meshes. Meanwhile, some subset of prims may very well make for a suitable physics proxy representation even for objects that are complex meshes at their core. It is quite common for mesh-based systems to only actually use concave physics meshes for static geometry, and use proxy shapes (like boxes, spheres, capsules and convex hulls) for physics. Anyway, that's the background that makes me believe that one fundament of object interoperability is that everyone must understand meshes at some level, and then you can add as much negotiated fancy on top as you want. Sincerely, jw _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox From gareth@litesim.com Mon Feb 23 00:07:47 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F6B28C202 for ; Mon, 23 Feb 2009 00:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXZUXOqDIl8N for ; Mon, 23 Feb 2009 00:07:47 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 0A7EA28C1F3 for ; Mon, 23 Feb 2009 00:07:47 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1727047rvb.49 for ; Mon, 23 Feb 2009 00:08:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.133.10 with SMTP id g10mr1922183rvd.57.1235376483565; Mon, 23 Feb 2009 00:08:03 -0800 (PST) In-Reply-To: <566568.8998.qm@web65716.mail.ac4.yahoo.com> References: <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> <49A1F4EE.4000305@gmail.com> <61dbdd7d0902221702x5bcbc921i5b75be7fc3ad410e@mail.gmail.com> <49A220DD.2020300@gmail.com> <566568.8998.qm@web65716.mail.ac4.yahoo.com> Date: Mon, 23 Feb 2009 08:08:03 +0000 Message-ID: <61dbdd7d0902230008m1b9a2059gc404c9b90639bf18@mail.gmail.com> From: Gareth Nelson To: eh2th-mmox@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:07:48 -0000 "many content creators simply mark them as "Phantom" and then use regular prims inside the sculptie to make a user defined proxy." I never knew the physics proxy was so badly out of sync in sculpties, what is the actual ratio in LOD between the rendered graphic and the physics proxy? On Mon, Feb 23, 2009 at 7:58 AM, wrote: > I can't speak for the SecondLife (SL) implementation as it's a black box = to me, but from my collision tests, I am inclined to believe that since SL = implemented the Havok 4 physics engine on their servers, that they are usin= g fairly high level of detail mesh representations of their prims for proxi= es. > > In OpenSim, if the Open Dynamics (ODE) physics engine is configured, and = if the "Meshmerizer" option is chosen, then the prim proxies are meshed by = the PrimMesher library at a fairly high level of detail which approaches th= e highest level of detail in the second life viewer. This configuration has= been somewhat optimized over the last several months to yield quite reason= able performance for collisions and memory usage. There are some cases wher= e internal ODE representations of proxies are still used: when prims are si= mple boxes or spheres. > > "Sculpties", or sculpted prims, are a newer feature in SL which can displ= ay simple mesh objects. SL uses simple proxies for sculpties, and many cont= ent creators simply mark them as "Phantom" and then use regular prims insid= e the sculptie to make a user defined proxy. > > OpenSim has added an experimental feature where a low level of detail scu= lptie mesh can also be used as a proxy. This seems to work well in many cas= es, however users are becoming more clever at making increasingly complex s= culpties, and due to the limited level of detail, the resulting mesh collis= ion proxy can often differ significantly in shape. > > --Tom > > > > ----- Original Message ---- > From: Jon Watte > To: Gareth Nelson > Cc: "mmox@ietf.org" > Sent: Sunday, February 22, 2009 8:06:53 PM > Subject: Re: [mmox] Learning from the past; focusing on the future > > Gareth Nelson wrote: >> Ironically (given LL's heavy involvement) this means SL is in for >> major changes in order to join in if meshes are to become a mandatory >> part of the standard. >> >> > > It seems unavoidable that SL and derived technologies would get meshes at= some level, yes. I don't think users would be particularly mad, though ;-) > >> Of course, SL could just keep prims and add meshes as an extra, but by >> that point you might as well drop prims completely at the protocol >> level (the UI of course can maintain prims still). >> > > I fully expect prims to remain within the SL system as a first class citi= zen. Their claim is that sending an object based on a prim recipe uses less= bandwidth than sending the prim recipe "cooked" as a mesh, and I see no re= ason to doubt that claim. (Whether a custom-built mesh would be more or les= s compact is a different question, the answer to which is "it depends.") In= fact, for the case where SL talks to OpenSim, or some other SL derived tec= hnology, I would expect them to negotiate to exchange only prims and not me= shes. > > Meanwhile, some subset of prims may very well make for a suitable physics= proxy representation even for objects that are complex meshes at their cor= e. It is quite common for mesh-based systems to only actually use concave p= hysics meshes for static geometry, and use proxy shapes (like boxes, sphere= s, capsules and convex hulls) for physics. > > Anyway, that's the background that makes me believe that one fundament of= object interoperability is that everyone must understand meshes at some le= vel, and then you can add as much negotiated fancy on top as you want. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From tommi.s.e.laukkanen@gmail.com Mon Feb 23 00:15:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D4E428C20F; Mon, 23 Feb 2009 00:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cGeeKvzjAKD; Mon, 23 Feb 2009 00:15:09 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id A346628C200; Mon, 23 Feb 2009 00:15:08 -0800 (PST) Received: by bwz5 with SMTP id 5so4449391bwz.13 for ; Mon, 23 Feb 2009 00:15:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=uwnz9UxLG2aBbM/ah8dtOAmi1ESsdNDl8Jr6CHeNAuU=; b=r01L4YkAtj/o8p9LPM4lpEwTcj+//++CbKr+owk8Fxak+Wd0u+L0yUqXs1CCKaZPkE /JLVim8cdUKCx+vaVI6l/QPgiJytj0nrKCBBxQo1eqkzKraG63aosyYRkZgq7qV9FE5M 7mxX3F0v9D2Xcooe9xuByFzmtL3DCM9vdOUhM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c/vbeK32sCuyGMboQ3X1x1zEzqyXgESWQwo6CdeWAyUwNiVlSv0ryyWQBJgcu3qGPH KtGkJZaNmAeJ+IHv1tQrQeGE6wriC2jykZELgvBhW6itNBAjwhnaVH75ex3rkNXv3Xv+ mYp/u+KB2XfXSFAiJ1/2ZIskIotBe4t6diuDk= MIME-Version: 1.0 Received: by 10.181.240.10 with SMTP id s10mr1434653bkr.108.1235376924599; Mon, 23 Feb 2009 00:15:24 -0800 (PST) In-Reply-To: References: <744D5200-2829-4CF1-B513-2566367CB804@lindenlab.com> Date: Mon, 23 Feb 2009 10:15:24 +0200 Message-ID: From: Tommi Laukkanen To: David W Levine Content-Type: multipart/alternative; boundary=001636c5a826c124600463919a41 Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:15:10 -0000 --001636c5a826c124600463919a41 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Thank you for your continuing interest in MXP. MXP does not have license encumberances especially as CICP does not have them either. Please read the blog post I included in the previous mail: http://www.cybertechnews.org/?p=765 It is an article where Ben *publishes the provisional patent application to public domain.* best regards, Tommi Laukkanen --001636c5a826c124600463919a41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello
 
Thank you for your continuing interest in MXP. MXP does not have licen= se encumberances especially as CICP does not have them either. Please = read the blog post I included in the previous mail: http://www.cybertechnews.org/?p=3D765
 
It is an article where Ben publishes the provisional patent ap= plication to public domain.
 
best regards,
Tommi Laukkanen
--001636c5a826c124600463919a41-- From gareth@litesim.com Mon Feb 23 00:18:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6F228C210; Mon, 23 Feb 2009 00:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCQMCDCtzAlc; Mon, 23 Feb 2009 00:18:22 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.156]) by core3.amsl.com (Postfix) with ESMTP id 4529828C200; Mon, 23 Feb 2009 00:16:30 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6361849poe.4 for ; Mon, 23 Feb 2009 00:16:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.49.18 with SMTP id b18mr1920756rvk.96.1235377006745; Mon, 23 Feb 2009 00:16:46 -0800 (PST) In-Reply-To: References: <744D5200-2829-4CF1-B513-2566367CB804@lindenlab.com> Date: Mon, 23 Feb 2009 08:16:46 +0000 Message-ID: <61dbdd7d0902230016h1a346ecsc5bffd9bb6caf421@mail.gmail.com> From: Gareth Nelson To: Tommi Laukkanen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:18:23 -0000 Is it actually meaningful to post a patent (and a provisional patent no less) to the public domain? Really, without at least 2 lawyers saying "yes", I think anything that has patent interests on it is risky. On Mon, Feb 23, 2009 at 8:15 AM, Tommi Laukkanen wrote: > Hello > > Thank you for your continuing interest in MXP. MXP does not have license > encumberances especially as CICP does not have them either. Please read the > blog post I included in the previous mail: > http://www.cybertechnews.org/?p=765 > > It is an article where Ben publishes the provisional patent application to > public domain. > > best regards, > Tommi Laukkanen > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From eh2th-mmox@yahoo.com Mon Feb 23 00:20:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63A23A672F for ; Mon, 23 Feb 2009 00:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnMaWlnSdPdU for ; Mon, 23 Feb 2009 00:20:10 -0800 (PST) Received: from web65705.mail.ac4.yahoo.com (web65705.mail.ac4.yahoo.com [76.13.9.97]) by core3.amsl.com (Postfix) with SMTP id 7855F3A67A1 for ; Mon, 23 Feb 2009 00:20:10 -0800 (PST) Received: (qmail 33162 invoked by uid 60001); 23 Feb 2009 08:20:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=vaGzqaWNGXhjm16tp2dqSX+qgJSaH0hw64AetzYCNbA/4V2/pHlJ/E2wiJjVQIBtTkjFCJ5fsXtvApWKKkqtplJQ9OGhFPVhKCtZOklujWbBayJxFb2y5IV4eYmY0IKhHWMNRvMKTaPccdbyKKQ8/t+eg/1soJaqMJ1IOMUSoJw=; X-YMail-OSG: 25s6yYQVM1kbgK1Hx3Tc1rqm.DY6XAqynwuK0Y3zjHByqtJUNMG4Jp55xDFbE_1kfiBXcpJPR2KpLuaR7JNLeFyZ6SjVK7ankME.1mKstlUe7N9xFdfE2rqc1XgI2MowkTpkR6HjOuCd8bnoj_Cn5bGdJjqvEX1ZtXGb8H9Wohn.JeEtuheG2lH7_3DozXB8Dzw1DDYn4U1gX4Y.VJ_tS.zxcw-- Received: from [72.220.236.152] by web65705.mail.ac4.yahoo.com via HTTP; Mon, 23 Feb 2009 00:20:27 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> <49A1F4EE.4000305@gmail.com> <61dbdd7d0902221702x5bcbc921i5b75be7fc3ad410e@mail.gmail.com> <49A220DD.2020300@gmail.com> <566568.8998.qm@web65716.mail.ac4.yahoo.com> <61dbdd7d0902230008m1b9a2059gc404c9b90639bf18@mail.gmail.com> Date: Mon, 23 Feb 2009 00:20:27 -0800 (PST) From: eh2th-mmox@yahoo.com To: Gareth Nelson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <282670.32064.qm@web65705.mail.ac4.yahoo.com> Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:20:12 -0000 The difference in Secondlife? I'm not really sure what they use for a proxy.. could be a sphere or a torus? In OpenSim, the level of detail is a configuration option, it defaults to a 16x16 maximum. Counting vertices in wireframe mode in the SL viewer shows sculptie LOD to be 32x32 at the highest level. ----- Original Message ---- From: Gareth Nelson To: eh2th-mmox@yahoo.com Cc: Jon Watte ; "mmox@ietf.org" Sent: Monday, February 23, 2009 12:08:03 AM Subject: Re: [mmox] Learning from the past; focusing on the future "many content creators simply mark them as "Phantom" and then use regular prims inside the sculptie to make a user defined proxy." I never knew the physics proxy was so badly out of sync in sculpties, what is the actual ratio in LOD between the rendered graphic and the physics proxy? On Mon, Feb 23, 2009 at 7:58 AM, wrote: > I can't speak for the SecondLife (SL) implementation as it's a black box to me, but from my collision tests, I am inclined to believe that since SL implemented the Havok 4 physics engine on their servers, that they are using fairly high level of detail mesh representations of their prims for proxies. > > In OpenSim, if the Open Dynamics (ODE) physics engine is configured, and if the "Meshmerizer" option is chosen, then the prim proxies are meshed by the PrimMesher library at a fairly high level of detail which approaches the highest level of detail in the second life viewer. This configuration has been somewhat optimized over the last several months to yield quite reasonable performance for collisions and memory usage. There are some cases where internal ODE representations of proxies are still used: when prims are simple boxes or spheres. > > "Sculpties", or sculpted prims, are a newer feature in SL which can display simple mesh objects. SL uses simple proxies for sculpties, and many content creators simply mark them as "Phantom" and then use regular prims inside the sculptie to make a user defined proxy. > > OpenSim has added an experimental feature where a low level of detail sculptie mesh can also be used as a proxy. This seems to work well in many cases, however users are becoming more clever at making increasingly complex sculpties, and due to the limited level of detail, the resulting mesh collision proxy can often differ significantly in shape. > > --Tom > > > > ----- Original Message ---- > From: Jon Watte > To: Gareth Nelson > Cc: "mmox@ietf.org" > Sent: Sunday, February 22, 2009 8:06:53 PM > Subject: Re: [mmox] Learning from the past; focusing on the future > > Gareth Nelson wrote: >> Ironically (given LL's heavy involvement) this means SL is in for >> major changes in order to join in if meshes are to become a mandatory >> part of the standard. >> >> > > It seems unavoidable that SL and derived technologies would get meshes at some level, yes. I don't think users would be particularly mad, though ;-) > >> Of course, SL could just keep prims and add meshes as an extra, but by >> that point you might as well drop prims completely at the protocol >> level (the UI of course can maintain prims still). >> > > I fully expect prims to remain within the SL system as a first class citizen. Their claim is that sending an object based on a prim recipe uses less bandwidth than sending the prim recipe "cooked" as a mesh, and I see no reason to doubt that claim. (Whether a custom-built mesh would be more or less compact is a different question, the answer to which is "it depends.") In fact, for the case where SL talks to OpenSim, or some other SL derived technology, I would expect them to negotiate to exchange only prims and not meshes. > > Meanwhile, some subset of prims may very well make for a suitable physics proxy representation even for objects that are complex meshes at their core. It is quite common for mesh-based systems to only actually use concave physics meshes for static geometry, and use proxy shapes (like boxes, spheres, capsules and convex hulls) for physics. > > Anyway, that's the background that makes me believe that one fundament of object interoperability is that everyone must understand meshes at some level, and then you can add as much negotiated fancy on top as you want. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From dcolivares@gmail.com Mon Feb 23 00:20:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F653A68A8 for ; Mon, 23 Feb 2009 00:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBWBX4cWGH2K for ; Mon, 23 Feb 2009 00:20:39 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 577F73A68AF for ; Mon, 23 Feb 2009 00:20:39 -0800 (PST) Received: by fxm11 with SMTP id 11so1458235fxm.13 for ; Mon, 23 Feb 2009 00:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=WUTugX/vq9IFjlhA2VikdfV2w7x+pB+LDP4jUbhAlT8=; b=Hm/6xFcekPzDN8B9fH7+S5HS31yPMEYJeS7lJ9RL22YIC+aUnj89iHRiq6uwGwJiEU V8aHAV2woCvMBCdXrExlgEUc8h4IBFfcwnZAg+o6nXLtakQclJIl36BHHEy//YDb+I4y 6vBza+Z9U4PPylaDYghleeHHnkHqs37iIEos8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lsoWtRviBDz/I3SJQxbVZsuUSnlHdxY4eT23OL3d8NToiKK+W+0eDmJ/Vqj7/Yx0Cw doP0SpBcB3h5jcV9oSAZWAKDUvOWkhZu57TPMMe1O0lC7GBiF1OoIVaCTWH4zy8yEHVG W0J2oIXmRHbLFgrS1IB9fvyMdtwESR52iCdzg= MIME-Version: 1.0 Received: by 10.103.172.7 with SMTP id z7mr3106221muo.129.1235377255360; Mon, 23 Feb 2009 00:20:55 -0800 (PST) In-Reply-To: <61dbdd7d0902230008m1b9a2059gc404c9b90639bf18@mail.gmail.com> References: <61dbdd7d0902221115h70773f67gdd69796a461ecb3e@mail.gmail.com> <49A1BFAE.3060705@cox.net> <61dbdd7d0902221333o2e20eeecof6f0a0945d0e9189@mail.gmail.com> <49A1F4EE.4000305@gmail.com> <61dbdd7d0902221702x5bcbc921i5b75be7fc3ad410e@mail.gmail.com> <49A220DD.2020300@gmail.com> <566568.8998.qm@web65716.mail.ac4.yahoo.com> <61dbdd7d0902230008m1b9a2059gc404c9b90639bf18@mail.gmail.com> Date: Mon, 23 Feb 2009 03:20:55 -0500 Message-ID: From: Dan Olivares To: Gareth Nelson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:20:41 -0000 In SecondLife, it's represented by a torus or sphere (which is often VERY different from the appearence). They make no attempt to actually represent physically, the way it appears. In PrimMesher(And OpenSimulator), the physics proxy is very similar to the visible mesh and LOD is configurable, however, I tend to limit it to a total of 1024 vertices for static meshes and 256 vertices for 'physically active simulated' meshes to limit the load on the processor. And, now back to your regularly scheduled discussion on architecting for extensibility... Best Regards Dan On Mon, Feb 23, 2009 at 3:08 AM, Gareth Nelson wrote: > "many content creators simply mark them as "Phantom" and then use > regular prims inside the sculptie to make a user defined proxy." > I never knew the physics proxy was so badly out of sync in sculpties, > what is the actual ratio in LOD between the rendered graphic and the > physics proxy? > > On Mon, Feb 23, 2009 at 7:58 AM, wrote: >> I can't speak for the SecondLife (SL) implementation as it's a black box= to me, but from my collision tests, I am inclined to believe that since SL= implemented the Havok 4 physics engine on their servers, that they are usi= ng fairly high level of detail mesh representations of their prims for prox= ies. >> >> In OpenSim, if the Open Dynamics (ODE) physics engine is configured, and= if the "Meshmerizer" option is chosen, then the prim proxies are meshed by= the PrimMesher library at a fairly high level of detail which approaches t= he highest level of detail in the second life viewer. This configuration ha= s been somewhat optimized over the last several months to yield quite reaso= nable performance for collisions and memory usage. There are some cases whe= re internal ODE representations of proxies are still used: when prims are s= imple boxes or spheres. >> >> "Sculpties", or sculpted prims, are a newer feature in SL which can disp= lay simple mesh objects. SL uses simple proxies for sculpties, and many con= tent creators simply mark them as "Phantom" and then use regular prims insi= de the sculptie to make a user defined proxy. >> >> OpenSim has added an experimental feature where a low level of detail sc= ulptie mesh can also be used as a proxy. This seems to work well in many ca= ses, however users are becoming more clever at making increasingly complex = sculpties, and due to the limited level of detail, the resulting mesh colli= sion proxy can often differ significantly in shape. >> >> --Tom >> >> >> >> ----- Original Message ---- >> From: Jon Watte >> To: Gareth Nelson >> Cc: "mmox@ietf.org" >> Sent: Sunday, February 22, 2009 8:06:53 PM >> Subject: Re: [mmox] Learning from the past; focusing on the future >> >> Gareth Nelson wrote: >>> Ironically (given LL's heavy involvement) this means SL is in for >>> major changes in order to join in if meshes are to become a mandatory >>> part of the standard. >>> >>> >> >> It seems unavoidable that SL and derived technologies would get meshes a= t some level, yes. I don't think users would be particularly mad, though ;-= ) >> >>> Of course, SL could just keep prims and add meshes as an extra, but by >>> that point you might as well drop prims completely at the protocol >>> level (the UI of course can maintain prims still). >>> >> >> I fully expect prims to remain within the SL system as a first class cit= izen. Their claim is that sending an object based on a prim recipe uses les= s bandwidth than sending the prim recipe "cooked" as a mesh, and I see no r= eason to doubt that claim. (Whether a custom-built mesh would be more or le= ss compact is a different question, the answer to which is "it depends.") I= n fact, for the case where SL talks to OpenSim, or some other SL derived te= chnology, I would expect them to negotiate to exchange only prims and not m= eshes. >> >> Meanwhile, some subset of prims may very well make for a suitable physic= s proxy representation even for objects that are complex meshes at their co= re. It is quite common for mesh-based systems to only actually use concave = physics meshes for static geometry, and use proxy shapes (like boxes, spher= es, capsules and convex hulls) for physics. >> >> Anyway, that's the background that makes me believe that one fundament o= f object interoperability is that everyone must understand meshes at some l= evel, and then you can add as much negotiated fancy on top as you want. >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From morgaine.dinova@googlemail.com Mon Feb 23 00:30:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6FD228C202 for ; Mon, 23 Feb 2009 00:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9JUy4MUuHRX for ; Mon, 23 Feb 2009 00:30:51 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 75EA928C14A for ; Mon, 23 Feb 2009 00:30:50 -0800 (PST) Received: by fxm11 with SMTP id 11so1465529fxm.13 for ; Mon, 23 Feb 2009 00:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qlYxkm6l+uelvIP0dAZyYw5hl1+L93Qi4PgionyDqOk=; b=PftSRzywv7A7HFpSwkbsD44VAUdYYmVvku7GL2s4YJDvteLLRCLoBl8dhb2I1DdAIc fv1lA2ak4trU+7Z/1/5tzGCn77I5ITfY/iXHQX1KlIp7YI/3pXi+Eacy5ychIQnD6pyT SW0efQ67qoGvJn86kwN6hFEXN07Zpq0V8DpWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=yERmpijFhp7rrmLgKSAyhZOMxEK82UfQMWf5IlrMJWWDqk6ZAO4vE8ysZxkLBT5/kH +1sokLlsSQaZm4qIijh3TGHaJmKyahY6AJ/MMD9w4f6KUDNl/HxCAwHH2DUM1czzFcFh pgKrOvcKNN0KrkrALCHKY0YIplBsxPzfGWcpY= MIME-Version: 1.0 Received: by 10.181.197.6 with SMTP id z6mr343866bkp.213.1235377866282; Mon, 23 Feb 2009 00:31:06 -0800 (PST) In-Reply-To: <49A2500F.3000104@gmail.com> References: <49A2500F.3000104@gmail.com> Date: Mon, 23 Feb 2009 08:31:06 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=00504502cd72e21822046391d240 Cc: Mystical Demina , mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:30:52 -0000 --00504502cd72e21822046391d240 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Feb 23, 2009 at 7:28 AM, Jon Watte wrote: > > I think the /first/ thing we need to decide is whether we're building: > > 1) A protocol that lets some number of second-life derived client softwares > cross-connect to some number of second-life derived services, possibly > bringing along some number of second-life derived assets (I've heard > proposals that boil down to this from a few people) > > or > > 2) A protocol that lets significantly different virutal world systems > interoperate to share in creating a single, bigger, more diverse simulation > (Some other people, including me, are presenting proposals along these > lines). > I can't understand why you continue to raise the spectre that we're here to rubberstamp SL standards. We aren't. I'm not aware of anybody with that agenda. The latest version #4 of the draft charter doesn't even mention OGP, because we reworded it specifically to be vendor-neutral: http://www.ietf.org/mail-archive/web/mmox/current/msg00066.html . And please note that this was done with the Linden co-chair's approval, stated desire, and encouragement. Our #4 still mentions LLSD, admittedly, but if you think it's inappropriate on either vendor-neutrality or on technical grounds then please pick up the baton and give us draft charter #5. I'm looking forward to it. Our work is very explicitly targeted at embracing the needs of many diverse worlds, hopefully far beyond merely those few worlds that currently have representation here. We are working in good faith towards your item 2), while noting that item 2) means interop with "all" reasonable worlds, and that includes Linden worlds. It's not either/or, it's both. Please grant us that, so that we can actually make headway. *(Proviso: your item 2) says **single ... simulation**, which is incorrect, as we have no remit to straightjacket diverse worlds into a single simulation.)* Morgaine. --00504502cd72e21822046391d240 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 23, 2009 at 7:28 AM, Jon Wat= te <jwatte@gmail.c= om> wrote:

I think the /first/ thing we need to decide is whether we're building:<= br>
1) A protocol that lets some number of second-life derived client softwares= cross-connect to some number of second-life derived services, possibly bri= nging along some number of second-life derived assets (I've heard propo= sals that boil down to this from a few people)

or

2) A protocol that lets significantly different virutal world systems inter= operate to share in creating a single, bigger, more diverse simulation (Som= e other people, including me, are presenting proposals along these lines).<= br>


I can't understand why you continue to raise = the spectre that we're here to rubberstamp SL standards.  We aren&= #39;t.  I'm not aware of anybody with that agenda.

The late= st version #4 of the draft charter doesn't even mention OGP, because we= reworded it specifically to be vendor-neutral:  http://www.ietf.org/= mail-archive/web/mmox/current/msg00066.html .  And please note tha= t this was done with the Linden co-chair's approval, stated desire, and= encouragement.

Our #4 still mentions LLSD, admittedly, but if you think it's inapp= ropriate on either vendor-neutrality or on technical grounds then please pi= ck up the baton and give us draft charter #5.  I'm looking forward= to it.

Our work is very explicitly targeted at embracing the needs of many div= erse worlds, hopefully far beyond merely those few worlds that currently ha= ve representation here.

We are working in good faith towards your it= em 2), while noting that item 2) means interop with "all" reasona= ble worlds, and that includes Linden worlds.  It's not either/or, = it's both.  Please grant us that, so that we can actually make hea= dway.

(Proviso: your item 2) says single ... simulation, whi= ch is incorrect, as we have no remit to straightjacket diverse worlds into = a single simulation.)

Morgaine.
--00504502cd72e21822046391d240-- From tommi.s.e.laukkanen@gmail.com Mon Feb 23 00:53:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0B03A6934; Mon, 23 Feb 2009 00:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScMBl1NfyT6M; Mon, 23 Feb 2009 00:53:28 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 48B813A6924; Mon, 23 Feb 2009 00:52:35 -0800 (PST) Received: by bwz5 with SMTP id 5so4477333bwz.13 for ; Mon, 23 Feb 2009 00:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=9j3bZuk62gwhGP6iIcL/llmb53pDwlvVTq7c+jniSkA=; b=rbRVCaho//cL8WnAFts908es9uek7E6AHlNIum/csYtYczG7osoF399RPTtpSAhpLg xLjbO83Rzm/55FnNXo68caiOyoacohglS6Dir55NT58QbkIoNhBFHdvPNTj7dDBJ1X8v skES19xvI4wh4a5+jAy4OIzZ/Sm2Uf22gGSsw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CmFmXfDUu8JIU2TPh+LKXtUOg1Hb97LbfsI+1sZfovAXkMNNJEXyhP1mjnsy3GyMHB s+DE2fadSQni5R9yQUqvA8wCDlRLJ0rTB4GnnP7LMtmdaznnEXDcSfefIsAlNMkiRvgn kWqQFb8p7VvlXOQCsculMt5zkSYrbtLrAI/L0= MIME-Version: 1.0 Received: by 10.181.24.14 with SMTP id b14mr1445613bkj.104.1235379171440; Mon, 23 Feb 2009 00:52:51 -0800 (PST) In-Reply-To: <61dbdd7d0902230016h1a346ecsc5bffd9bb6caf421@mail.gmail.com> References: <744D5200-2829-4CF1-B513-2566367CB804@lindenlab.com> <61dbdd7d0902230016h1a346ecsc5bffd9bb6caf421@mail.gmail.com> Date: Mon, 23 Feb 2009 10:52:51 +0200 Message-ID: From: Tommi Laukkanen To: Gareth Nelson Content-Type: multipart/alternative; boundary=001636c5a976ad39ee04639220eb Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:53:29 -0000 --001636c5a976ad39ee04639220eb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello We have played this game long enough. Let me speak frankly and bear with me. It would probably serve better to approach these patent issues logically and based on facts instead of vague references to risks. I understand that some parties are not interested in MXP. Trying to slander alternative approaches is still quite unprofessional. I would say that adequate facts has been presented to clear up these IRP concerns for now. If it happens that MXP becomes official candidate for a standard then there is good time for any number of lawyers to go through the public domain patent application. In the mean time anyone still concerned can ask their lawyers for councel. All the material is publicly available for review. best regards, Tommi Laukkanen --001636c5a976ad39ee04639220eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello
 
We have played this game long enough. Let me speak frankly and bear wi= th me. It would probably serve better to approach these patent issues logic= ally and based on facts instead of vague references to risks. I understand&= nbsp;that some parties are not interested in MXP. Trying to slander alterna= tive approaches is still quite unprofessional.
 
I would say that adequate facts has been presented to clear = up these IRP concerns for now. If it happens that MXP becomes official cand= idate for a standard then there is good time for any number of la= wyers to go through the public domain patent application. In the mean time = anyone still concerned can ask their lawyers for councel. All the material = is publicly available for review.
 
best regards,
Tommi Laukkanen
--001636c5a976ad39ee04639220eb-- From gareth@litesim.com Mon Feb 23 00:55:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F300D3A688C; Mon, 23 Feb 2009 00:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6jOdIO+3EAW; Mon, 23 Feb 2009 00:55:23 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.154]) by core3.amsl.com (Postfix) with ESMTP id 337E93A672F; Mon, 23 Feb 2009 00:55:23 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6398434poe.4 for ; Mon, 23 Feb 2009 00:55:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.29.16 with SMTP id g16mr1943572rvj.92.1235379339643; Mon, 23 Feb 2009 00:55:39 -0800 (PST) In-Reply-To: References: <744D5200-2829-4CF1-B513-2566367CB804@lindenlab.com> <61dbdd7d0902230016h1a346ecsc5bffd9bb6caf421@mail.gmail.com> Date: Mon, 23 Feb 2009 08:55:39 +0000 Message-ID: <61dbdd7d0902230055n7a8eaedeyb6cf5b27023aacf9@mail.gmail.com> From: Gareth Nelson To: Tommi Laukkanen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:55:24 -0000 The problem is that we need to know NOW if we should be concerned, before potentially going to the effort of developing a standard that accidentally is patent-encumbered. On Mon, Feb 23, 2009 at 8:52 AM, Tommi Laukkanen wrote: > Hello > > We have played this game long enough. Let me speak frankly and bear with me. > It would probably serve better to approach these patent issues logically and > based on facts instead of vague references to risks. I understand that some > parties are not interested in MXP. Trying to slander alternative approaches > is still quite unprofessional. > > I would say that adequate facts has been presented to clear up these IRP > concerns for now. If it happens that MXP becomes official candidate for a > standard then there is good time for any number of lawyers to go through the > public domain patent application. In the mean time anyone still concerned > can ask their lawyers for councel. All the material is publicly available > for review. > > best regards, > Tommi Laukkanen From gareth@litesim.com Mon Feb 23 00:56:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6C613A6903; Mon, 23 Feb 2009 00:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZVi4O1dbDUx; Mon, 23 Feb 2009 00:56:44 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.152]) by core3.amsl.com (Postfix) with ESMTP id 0083B3A6908; Mon, 23 Feb 2009 00:56:43 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6399907poe.4 for ; Mon, 23 Feb 2009 00:57:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.42.10 with SMTP id u10mr1943840rvj.61.1235379420997; Mon, 23 Feb 2009 00:57:00 -0800 (PST) In-Reply-To: <61dbdd7d0902230055n7a8eaedeyb6cf5b27023aacf9@mail.gmail.com> References: <744D5200-2829-4CF1-B513-2566367CB804@lindenlab.com> <61dbdd7d0902230016h1a346ecsc5bffd9bb6caf421@mail.gmail.com> <61dbdd7d0902230055n7a8eaedeyb6cf5b27023aacf9@mail.gmail.com> Date: Mon, 23 Feb 2009 08:57:00 +0000 Message-ID: <61dbdd7d0902230057r70643ea2u2961ff29c7de50c3@mail.gmail.com> From: Gareth Nelson To: Tommi Laukkanen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:56:48 -0000 I should also note that i'm not of the opinion that CICP or potential derivatives should be completely avoided, just that we should not expend significant effort in anything which may be dependent before having a statement from someone with a law degree. On Mon, Feb 23, 2009 at 8:55 AM, Gareth Nelson wrote: > The problem is that we need to know NOW if we should be concerned, > before potentially going to the effort of developing a standard that > accidentally is patent-encumbered. > > On Mon, Feb 23, 2009 at 8:52 AM, Tommi Laukkanen > wrote: >> Hello >> >> We have played this game long enough. Let me speak frankly and bear with me. >> It would probably serve better to approach these patent issues logically and >> based on facts instead of vague references to risks. I understand that some >> parties are not interested in MXP. Trying to slander alternative approaches >> is still quite unprofessional. >> >> I would say that adequate facts has been presented to clear up these IRP >> concerns for now. If it happens that MXP becomes official candidate for a >> standard then there is good time for any number of lawyers to go through the >> public domain patent application. In the mean time anyone still concerned >> can ask their lawyers for councel. All the material is publicly available >> for review. >> >> best regards, >> Tommi Laukkanen > From dcolivares@gmail.com Mon Feb 23 00:57:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C980A3A6944; Mon, 23 Feb 2009 00:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.787 X-Spam-Level: X-Spam-Status: No, score=-2.787 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+mmT7wWddYc; Mon, 23 Feb 2009 00:57:09 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 4D9F23A672F; Mon, 23 Feb 2009 00:57:08 -0800 (PST) Received: by bwz5 with SMTP id 5so4480850bwz.13 for ; Mon, 23 Feb 2009 00:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nTFcezpZgt5ICj6U8wE82fN2pZjrZ/LpVFk/PWnYPwE=; b=LslsSTfEmUEYmXP9Dadndo1jyrT5RYZxN4rSy3vm4DUO76czlLlUS7D3CDFi5DWugk K2joEY+uLLn6vRhI/UIolJADGgdVsgXcg+ZSuKLdOjBYhS7zdrcaIieD19UN8SXwlPQr ZCmbqkGZV8sw+r9HTxFAVqheWGh6fzn2RVIO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Jm1NCJY4syL1C1rpgThIxIRSo1hhFf+dfsX/mXybwhx/kgAmZ3k6NF+QLf4Nd5P0Aq ZYU1ahkizh6ZBDlbkxyyNbd7+2phFQvfebihVu8oSc9JM07ySFTgBZWG91Ly3vw3EfP/ GUzwfl6TkEMYUBA6DvGImzr+KbYLjfBzyzOGg= MIME-Version: 1.0 Received: by 10.103.222.1 with SMTP id z1mr3132081muq.100.1235379443680; Mon, 23 Feb 2009 00:57:23 -0800 (PST) In-Reply-To: References: <744D5200-2829-4CF1-B513-2566367CB804@lindenlab.com> <61dbdd7d0902230016h1a346ecsc5bffd9bb6caf421@mail.gmail.com> Date: Mon, 23 Feb 2009 03:57:23 -0500 Message-ID: From: Dan Olivares To: Tommi Laukkanen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] Other NVE protocol specification efforts X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:57:09 -0000 Tommil As far as I can tell, there isn't anyone slandering your alternative approach. It is stated, in the rules of the IETF, that Intellectual property rights *MUST* be disclosed using the IPR disclosure tool. This has nothing to do with whether or not the license to use the patent is granted. The disclosure must still be made. Best Regards Dan On Mon, Feb 23, 2009 at 3:52 AM, Tommi Laukkanen wrote: > Hello > > We have played this game long enough. Let me speak frankly and bear with me. > It would probably serve better to approach these patent issues logically and > based on facts instead of vague references to risks. I understand that some > parties are not interested in MXP. Trying to slander alternative approaches > is still quite unprofessional. > > I would say that adequate facts has been presented to clear up these IRP > concerns for now. If it happens that MXP becomes official candidate for a > standard then there is good time for any number of lawyers to go through the > public domain patent application. In the mean time anyone still concerned > can ask their lawyers for councel. All the material is publicly available > for review. > > best regards, > Tommi Laukkanen > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From gareth@litesim.com Mon Feb 23 00:59:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957FB3A69DA for ; Mon, 23 Feb 2009 00:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.077 X-Spam-Level: X-Spam-Status: No, score=-1.077 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuVWw-RdJtW8 for ; Mon, 23 Feb 2009 00:59:33 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.152]) by core3.amsl.com (Postfix) with ESMTP id B252D3A6998 for ; Mon, 23 Feb 2009 00:59:33 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6403243poe.4 for ; Mon, 23 Feb 2009 00:59:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.97.5 with SMTP id z5mr1931612rvl.212.1235379590314; Mon, 23 Feb 2009 00:59:50 -0800 (PST) Date: Mon, 23 Feb 2009 08:59:50 +0000 Message-ID: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> From: Gareth Nelson To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 08:59:34 -0000 Just been talking to Adam about this and knocked out a very very rough spec. It may be early in the game to discuss this issue, but it's one that drives a lot of emotion in people on all sides of the debate. So, without further a-do, here's a rough spec for a DSL (Domain Specific Language) for permissions to discuss (copied and pasted from my vim session, excuse any formatting weirdness): Original concept courtesy of Adam Frisby, see http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/ Very very rough thinking out loud Each asset has a set of metadata fields: Author Creation timestamp Last modified timestamp Logs of modifications? (TBD) Possible actions: Copy Modify Transfer Transfer for cash Each action attached to a simple function that returns a boolean value if action is allowed. Data types: Entity Describes a user, organisation, system or network Asset Describes an asset ;) Location Describes a virtual location, rather than a physical system Time Date and time :) Entity has these fields: Name UUID Class (person, organisation, system, network) Optional fields for person entities: Agent domain? (TBD) System (what system is the user connecting from - may be withheld for privacy reasons) Location (where in the metaverse are they?) Optional fields for organisation entities: Organisation type (nonprofit/commercial/government etc) Company type (for corporations: LLC/Ltd/PLC/whatever) Address (i.e postal address) Technical contact (a person entity!) Optional fields for system entities: Platform System hash (hash of various bits of hardware, HD serial and ethernet MAC etc) Network Current IP address Optional fields for network entity Technical contact (heh, redundant) CIDR prefix Asset Name MIME type UUID Creator Creation time Last modified time Last modified by Location TBD (Obviously not the SL style Region/x/y/z) Time You need to ask? ok, Day Week Month Year Hour Minute Second All integers Simple comparision operators to match on what is passed to the functions !=, ==, >, <, >=, <=, a few simple string functions, the usual suspects function prototypes: copy(Entity src, Location location, Time time, Asset ass) src == the user currently holding the asset who wishes to copy it location == the location the requesting user is inhabiting at present time == the time the request was made at (just in case there's batch processing or serious latency) ass == the asset being copied modify(Entity modifier, Asset ass, Time time, Location loc) modifier == the entity trying to modify ass == the entity they're trying to modify time == the current time loc == where is our modifier while they're trying to modify? transfer(Entity src, Entity dst, Location loc, Time time, Asset ass) Same as copy essentially sell() is just transfer, but invoked for transfers in exchange for compensation The modify() function could probably do with a description (if possible) of the modification being requested, for example in my own work i'd want to prohibit modifications to the permissions in order to enforce the GPL, others may have different requirements. DANGER! DANGER! READ: Any system that can be proposed here can only be used to express intent, it can express that intent very clearly using a DSL as i've roughly spec'ed out above, but it will never be possible to actually enforce it on systems that do not want to enforce it. I'll note that personally I absolutely hate DRM for the most part, but if it's going to be a reality it should be done right, and should allow any type of license to be roughly expressed in a way that can be handled by automated systems. If for no other reason than mere practicality, a decent DSL for specifying what permissions an author of a copyrighted work has granted under existing copyright law can be useful and saves having to pester the author. From jesrad@gmail.com Mon Feb 23 01:07:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97ED728C0EE for ; Mon, 23 Feb 2009 01:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prf1b-TJYm2E for ; Mon, 23 Feb 2009 01:07:53 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 4D2313A6A73 for ; Mon, 23 Feb 2009 01:07:53 -0800 (PST) Received: by fxm11 with SMTP id 11so1494797fxm.13 for ; Mon, 23 Feb 2009 01:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=6HX1OS2v9U4wmp0D/O1Gd4l8sSA/UMaee4u1n+bLRYQ=; b=lqNWL7D1xUsGuylOh6s+31LiABWDkxu8scn+XH2NjM8ZhDz2UtFOIL5+10qF3BuUsF OA/VYir2qdvsB5pLW/xw47u3jdnECr2TWYkYv1nmdcw81VWMddSvXyCbreRxicaPZFo+ Yo0jq9E7cxK7Li4BQj5gljWGcjVUIhU1G+lw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=TqapGhbGeFm2qHdbzIhZhoWnoRNyRIM50EzTn5Upsn10s1BsryBxHe92Fa0gZKMrhn KY/J7wsILq08LPlqrMuAgrPF2XbRpEk0qKDdyafuekFCthmELAEnjyc58UHrpB2/SGXv FlXXgnQxpRRavJrgnAbyiaxnFg6UlLtTp92KQ= MIME-Version: 1.0 Received: by 10.181.208.15 with SMTP id k15mr1447774bkq.130.1235380089712; Mon, 23 Feb 2009 01:08:09 -0800 (PST) In-Reply-To: <53cd6c2e0902230107n1bf6b47fp9a9eb2995bda3250@mail.gmail.com> References: <27a487810902210015t7040f42ck98e08e0d1d82213e@mail.gmail.com> <53cd6c2e0902230107n1bf6b47fp9a9eb2995bda3250@mail.gmail.com> Date: Mon, 23 Feb 2009 10:08:09 +0100 Message-ID: <53cd6c2e0902230108x1f6e9461t32abe95e18edf55b@mail.gmail.com> From: Jesrad To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mmox] "home" system of object X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 09:07:54 -0000 The original remark can be expanded upon: it is quite simple to make a client viewer receive content from more than one source, provided the content itself is designed to be compartimentalized data on the hosting domain in the first place. It's a matter of opening a few more network sockets and managing a few more data flows. To the end-user, what matters is the single renderview - the fact that all the elements displayed there are seperately hosted and simulated would, in my experience, make no significant difference. I fully agree that the hosting source may prove the best location for converting/porting over content (3D model conversion, format adaptation, etc.) instead of the client itself, as this is consistent with my own professional experience with mobile content hosting and converting. But it still makes sense too that objects tied to one grid remain on it and are provided from there, cross-grid. It saves a lot of trouble on having to maintain multiple VMs in multiple versions, save bandwidth on the transfer of data between grids (though this is little a problem for large, possibly colocated grids, it's no such simple thing for individual, private grids / grid nodes of P2P VWs) and save load on all the duplicated processing required otherwise. On Sat, Feb 21, 2009 at 9:15 AM, William George wrote: > Jon wrote: > >> - Simulation and script execution for a given object needs to be done on >> the "home" system for that object, because objects may be constructed >> assuming wildly disparate execution environments (X3D with JavaScript; >> Prims with SL Script, C++ with XML, Java with JSR 184, etc). > > This "home system" could be a complex, doesn't need to be just one machine. > > Waka > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From jesrad@gmail.com Mon Feb 23 01:17:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1990828C1F4 for ; Mon, 23 Feb 2009 01:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=-0.845, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oANvxCLZJKgm for ; Mon, 23 Feb 2009 01:17:47 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 5C28528C0EE for ; Mon, 23 Feb 2009 01:17:45 -0800 (PST) Received: by bwz5 with SMTP id 5so4498557bwz.13 for ; Mon, 23 Feb 2009 01:18:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=NPhPrdpdSvKlUQBnJSE37L1KsYQFdmGCm1fJYuM8J88=; b=C751SbUYrkXKlhfOLA5a3K38JEgP31mcpjg197ogFegRnFTUj+NJNH0cnCGc2M6keK 4H1CsKu49X+TFHUQHzONlYJVux0Zt1MkkCL3cwhukoWwtKe4YQ4SmrHPssIlZHKLY0I5 SLx6iF5yaDdq8ikJ/u4wmk598oVnopyzY48oU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=H7uUTiTqJCKYM7hVdB2yAq7JWQcmOrVSdBmATNeJX/FS6e4T2SYbKI4olrMaCawe/S mOojhH7LHFU98TKroFBbV1CvhrKSL/8XEgfMBoLo0G3KGwwgKd8MxKE3JV7in+akaXvY k5ZbZ9rf1fTkvVSU9l8pB9QNVx8Apo8VnvNSI= MIME-Version: 1.0 Received: by 10.181.48.4 with SMTP id a4mr1460520bkk.6.1235380682102; Mon, 23 Feb 2009 01:18:02 -0800 (PST) In-Reply-To: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> Date: Mon, 23 Feb 2009 10:18:02 +0100 Message-ID: <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> From: Jesrad To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 09:17:48 -0000 Imagine for a second that the cross-grid protocol mandate somehow that objects made on one grid be hosted and served to clients from this grid, and not transfered to other grid servers / simulators (though the owner may have the third-party possibility of exporting from one and importing to another so it is hosted multiple times and thus exists in multiple instances). >From there any specific policy of "DRM" would purely be a matter of specific grid implementation. I would say that a lot of headaches and flames would be averted, saving us the trouble of directly addressing these matters in the MMOX scope itself and leaving them for grid-caretakers and their own customers to discuss and decide policy about. Please, everyone, let me know what you think of this. On Mon, Feb 23, 2009 at 9:59 AM, Gareth Nelson wrote: > Just been talking to Adam about this and knocked out a very very rough > spec. It may be early in the game to discuss this issue, but it's one > that drives a lot of emotion in people on all sides of the debate. > > So, without further a-do, here's a rough spec for a DSL (Domain > Specific Language) for permissions to discuss (copied and pasted from > my vim session, excuse any formatting weirdness): > Original concept courtesy of Adam Frisby, see > http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/ > > Very very rough thinking out loud > > Each asset has a set of metadata fields: > Author > Creation timestamp > Last modified timestamp > Logs of modifications? (TBD) > > Possible actions: > Copy > Modify > Transfer > Transfer for cash > > Each action attached to a simple function that returns a boolean value > if action is allowed. > Data types: > Entity > Describes a user, organisation, system or network > Asset > Describes an asset ;) > Location > Describes a virtual location, rather than a physical system > Time > Date and time :) > > Entity has these fields: > Name > UUID > Class (person, organisation, system, network) > Optional fields for person entities: > Agent domain? (TBD) > System (what system is the user connecting from - may be withheld for > privacy reasons) > Location (where in the metaverse are they?) > Optional fields for organisation entities: > Organisation type (nonprofit/commercial/government etc) > Company type (for corporations: LLC/Ltd/PLC/whatever) > Address (i.e postal address) > Technical contact (a person entity!) > Optional fields for system entities: > Platform > System hash (hash of various bits of hardware, HD serial and ethernet MAC etc) > Network > Current IP address > Optional fields for network entity > Technical contact (heh, redundant) > CIDR prefix > > Asset > Name > MIME type > UUID > Creator > Creation time > Last modified time > Last modified by > > Location > TBD (Obviously not the SL style Region/x/y/z) > > Time > You need to ask? ok, > Day > Week > Month > Year > Hour > Minute > Second > All integers > > Simple comparision operators to match on what is passed to the functions > !=, ==, >, <, >=, <=, a few simple string functions, the usual suspects > > function prototypes: > copy(Entity src, Location location, Time time, Asset ass) > src == the user currently holding the asset who wishes to copy it > location == the location the requesting user is inhabiting at present > time == the time the request was made at (just in case there's > batch processing or serious latency) > ass == the asset being copied > modify(Entity modifier, Asset ass, Time time, Location loc) > modifier == the entity trying to modify > ass == the entity they're trying to modify > time == the current time > loc == where is our modifier while they're trying to modify? > transfer(Entity src, Entity dst, Location loc, Time time, Asset ass) > Same as copy essentially > sell() is just transfer, but invoked for transfers in exchange for compensation > > The modify() function could probably do with a description (if > possible) of the modification being requested, for example in my own > work i'd want to prohibit modifications to the permissions in order to > enforce the GPL, others may have different requirements. > > > DANGER! DANGER! READ: > Any system that can be proposed here can only be used to express > intent, it can express that intent very clearly using a DSL as i've > roughly > spec'ed out above, but it will never be possible to actually > enforce it on systems that do not want to enforce it. I'll note that > personally I > absolutely hate DRM for the most part, but if it's going to be a > reality it should be done right, and should allow any type of license > to be roughly > expressed in a way that can be handled by automated systems. If for > no other reason than mere practicality, a decent DSL for specifying > what > permissions an author of a copyrighted work has granted under > existing copyright law can be useful and saves having to pester the > author. > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From gareth@litesim.com Mon Feb 23 01:31:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7826E3A6A5A for ; Mon, 23 Feb 2009 01:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm-LWR7ROwui for ; Mon, 23 Feb 2009 01:31:00 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.157]) by core3.amsl.com (Postfix) with ESMTP id 28F9C3A68AF for ; Mon, 23 Feb 2009 01:31:00 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6430199poe.4 for ; Mon, 23 Feb 2009 01:31:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.2.18 with SMTP id e18mr1949990rvi.142.1235381476922; Mon, 23 Feb 2009 01:31:16 -0800 (PST) In-Reply-To: <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> Date: Mon, 23 Feb 2009 09:31:16 +0000 Message-ID: <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> From: Gareth Nelson To: Jesrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 09:31:01 -0000 Some people are going to insist on the DRM or not allow their content to be transferred at all, at least if there's a scheme in place like this it will reduce headaches (at least until hell freezes over and copyright law is overthrown). I am absolutely NOT advocating DRM as a good thing, what I am advocating is a system similar to DRM which simply tells you what you are legally allowed to do. If you choose to ignore the permissions and thus violate the copyright, that is between you and the courts, but you should at least be able to find out where you stand legally without pestering copyright holders every time, and it would help if automated systems can aid you. On Mon, Feb 23, 2009 at 9:18 AM, Jesrad wrote: > Imagine for a second that the cross-grid protocol mandate somehow that > objects made on one grid be hosted and served to clients from this > grid, and not transfered to other grid servers / simulators (though > the owner may have the third-party possibility of exporting from one > and importing to another so it is hosted multiple times and thus > exists in multiple instances). > > From there any specific policy of "DRM" would purely be a matter of > specific grid implementation. I would say that a lot of headaches and > flames would be averted, saving us the trouble of directly addressing > these matters in the MMOX scope itself and leaving them for > grid-caretakers and their own customers to discuss and decide policy > about. > > Please, everyone, let me know what you think of this. > > On Mon, Feb 23, 2009 at 9:59 AM, Gareth Nelson wrote: >> Just been talking to Adam about this and knocked out a very very rough >> spec. It may be early in the game to discuss this issue, but it's one >> that drives a lot of emotion in people on all sides of the debate. >> >> So, without further a-do, here's a rough spec for a DSL (Domain >> Specific Language) for permissions to discuss (copied and pasted from >> my vim session, excuse any formatting weirdness): >> Original concept courtesy of Adam Frisby, see >> http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/ >> >> Very very rough thinking out loud >> >> Each asset has a set of metadata fields: >> Author >> Creation timestamp >> Last modified timestamp >> Logs of modifications? (TBD) >> >> Possible actions: >> Copy >> Modify >> Transfer >> Transfer for cash >> >> Each action attached to a simple function that returns a boolean value >> if action is allowed. >> Data types: >> Entity >> Describes a user, organisation, system or network >> Asset >> Describes an asset ;) >> Location >> Describes a virtual location, rather than a physical system >> Time >> Date and time :) >> >> Entity has these fields: >> Name >> UUID >> Class (person, organisation, system, network) >> Optional fields for person entities: >> Agent domain? (TBD) >> System (what system is the user connecting from - may be withheld for >> privacy reasons) >> Location (where in the metaverse are they?) >> Optional fields for organisation entities: >> Organisation type (nonprofit/commercial/government etc) >> Company type (for corporations: LLC/Ltd/PLC/whatever) >> Address (i.e postal address) >> Technical contact (a person entity!) >> Optional fields for system entities: >> Platform >> System hash (hash of various bits of hardware, HD serial and ethernet MAC etc) >> Network >> Current IP address >> Optional fields for network entity >> Technical contact (heh, redundant) >> CIDR prefix >> >> Asset >> Name >> MIME type >> UUID >> Creator >> Creation time >> Last modified time >> Last modified by >> >> Location >> TBD (Obviously not the SL style Region/x/y/z) >> >> Time >> You need to ask? ok, >> Day >> Week >> Month >> Year >> Hour >> Minute >> Second >> All integers >> >> Simple comparision operators to match on what is passed to the functions >> !=, ==, >, <, >=, <=, a few simple string functions, the usual suspects >> >> function prototypes: >> copy(Entity src, Location location, Time time, Asset ass) >> src == the user currently holding the asset who wishes to copy it >> location == the location the requesting user is inhabiting at present >> time == the time the request was made at (just in case there's >> batch processing or serious latency) >> ass == the asset being copied >> modify(Entity modifier, Asset ass, Time time, Location loc) >> modifier == the entity trying to modify >> ass == the entity they're trying to modify >> time == the current time >> loc == where is our modifier while they're trying to modify? >> transfer(Entity src, Entity dst, Location loc, Time time, Asset ass) >> Same as copy essentially >> sell() is just transfer, but invoked for transfers in exchange for compensation >> >> The modify() function could probably do with a description (if >> possible) of the modification being requested, for example in my own >> work i'd want to prohibit modifications to the permissions in order to >> enforce the GPL, others may have different requirements. >> >> >> DANGER! DANGER! READ: >> Any system that can be proposed here can only be used to express >> intent, it can express that intent very clearly using a DSL as i've >> roughly >> spec'ed out above, but it will never be possible to actually >> enforce it on systems that do not want to enforce it. I'll note that >> personally I >> absolutely hate DRM for the most part, but if it's going to be a >> reality it should be done right, and should allow any type of license >> to be roughly >> expressed in a way that can be handled by automated systems. If for >> no other reason than mere practicality, a decent DSL for specifying >> what >> permissions an author of a copyrighted work has granted under >> existing copyright law can be useful and saves having to pester the >> author. >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From jesrad@gmail.com Mon Feb 23 01:46:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC6163A6AA5 for ; Mon, 23 Feb 2009 01:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Db2lO7n9O1X for ; Mon, 23 Feb 2009 01:46:38 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 624853A6A9D for ; Mon, 23 Feb 2009 01:46:38 -0800 (PST) Received: by fxm11 with SMTP id 11so1529651fxm.13 for ; Mon, 23 Feb 2009 01:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=TWEYcac9YwAhuDlZ4fqQSIMvoD8wbNNBD5Sm0Pz6Aas=; b=ifD2VsIry4fPhQZszDoEBmWduOcdaFjjx+UXkOlPcZ/rO2rgOQHac8E282RZIq/eFH s/GAXh2LbqRIAr0GNUMd0fnjUkii8/95sSGbVS+QDM5fv0IbPP847TFQD023Lii2JEBF 7cf/HIvi2a3vzqjX5q9V7S0nbNJHV6ASvY3Wo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=t0P6Wu55THeMMPUlbL3oId2/KW/BpZaSft5uKGEDeik/sWc1sV4ejU28trRDNCJNXQ 5xkk7560uMqFfUuMbMTl82fivZKUR+1kz6Q/JnaSkVIz9dg7vg8EaBlOK4ZThiOXeC8a 3aeHe1Fd94a7jJdLK/Elrfz2azlgVrgLerb8s= MIME-Version: 1.0 Received: by 10.181.145.6 with SMTP id x6mr1462643bkn.94.1235382414256; Mon, 23 Feb 2009 01:46:54 -0800 (PST) In-Reply-To: <20090221.022731.27043.2@webmail04.vgs.untd.com> References: <20090221.022731.27043.2@webmail04.vgs.untd.com> Date: Mon, 23 Feb 2009 10:46:54 +0100 Message-ID: <53cd6c2e0902230146x67de6a6fj4c4ee824570be75f@mail.gmail.com> From: Jesrad To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mmox] mmox Digest, Vol 1, Issue 69 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 09:46:39 -0000 I do object to a "real names only" policy, for personal security and privacy reasons. I can disclose my RL name to individual participants in the MMOX discussion group, but I absolutely do not want it publicized in any document, unless it is severed from my contributions and cannot be tied back to my SL identity by deduction. I am not subjected to any NDA, agreement, contract or law that would prevent me from contributing to the MMOX group, my objection is only grounded in domestic political and ideological context. On Sat, Feb 21, 2009 at 8:27 AM, dyerbrookme@juno.com wrote: >>Charles, > I would support a "real names only" policy. > I think the businesslike stage will happen if a determination of who actu= ally has a business interest in interoperability is made. I don't know what= the IETF rule on "observers" are -- parties who have an interest, but don'= t actually have a business directly involved in implementing the technology= under consideration. > > Jon, I see what you are doing with this effort to make up various exclusi= onary rules and shake loose categories of people, or perhaps just one perso= n. Let me see if I can make up a more workable rule for you that will do th= e trick: how about excluding females without degrees in computer science? B= ut...as I can see from the rules, the lists of IETF must be made open to th= e public. > > I'm startled to find that a discussion of the interoperability of virtual= worlds would require at the outset that only those companies with a "busin= ess interest" would be allowed to take part in the shaping of universal sta= ndards, or that only "business interest" is valid as a virtual world standa= rdizer. This seems to run contrary to many of the aspects and sentiments ar= ound not only the IETF, but the entire Internet, which has been a mixture o= f both proprietary and opensource code, business, education, non-profit, an= d amateur hobbyist. I fail to see why only profit-making technology vendors= would be empowered to decide matters of interoperability affecting us all = in virtual worlds, which are an immersive form of *social* media. > > I don't object to a demand for a real name and I supply it, but it strike= s me as an obstacle designed to exclude certain SL avatars who in fact alre= ady have established reputations and businesses under their avatar name, wh= ich is an accepted convention. The insistence on real-life names or "find m= e everywhere under the same name" shouldn't be welded into the interop stan= dards. > > ____________________________________________________________ > Find monitors and projectors here. Get serious about tech. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTJHlmLDd4SmOsLTxbvSUl23= TCqAh008gAy2Ivk7h1EikzcHHgHAv7/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From belxjander@gmail.com Mon Feb 23 02:00:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705013A6AF6 for ; Mon, 23 Feb 2009 02:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtmA-hGaYw03 for ; Mon, 23 Feb 2009 02:00:21 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 04C4B3A6AFA for ; Mon, 23 Feb 2009 02:00:20 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so998070wag.5 for ; Mon, 23 Feb 2009 02:00:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=nmK8Go8t8Ev1iuKQegSgPf6s8h0D+bttjgPDCOzbut0=; b=mAWevoBaO3JULlLWggw8gEaj7bfTBLZcDviWVvh36pO1BiEw8TzNEVr0++jyMIx2cK LUmml6F1dGFWmqbwnpHqSHCIMaMTRSRkXzzWJVGore92lRtGXfb1zsHoylmtKz2raiVI oMvFiEWatxfyuKAQGVdDHyYOb63MHamPj4BP0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=XenyMDV9XA6o6Fe8BHe6PF80YrXAbyXnkzxm/LjmQmTsi+Y6MRGnPVEYe2bc5UdMCq bdeghN6Oh+3HkHUIKAOXabyZ+JYyY0BG8vH8W9QlrcAr0Etp0iBF32ckSuuPu+9yD10e RMzOSVICiP92g3T25bRgWldG0I2rRIURwZ8Lg= Received: by 10.114.102.20 with SMTP id z20mr1608137wab.53.1235383237583; Mon, 23 Feb 2009 02:00:37 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g14sm6002108rvb.0.2009.02.23.02.00.35 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 02:00:36 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xflyd5Ng14+76UaU6hVZ" Date: Mon, 23 Feb 2009 18:55:18 +0900 Message-Id: <1235382918.6786.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:00:22 -0000 --=-xflyd5Ng14+76UaU6hVZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I had a very interesting chat about this with Gareth... and this is what I came up with... based off existing Email and FileFormat styles... Im going to tag this for style within this message... anything in <> is to be machine readable sections, anything encoded within a tagged item as "<...>encoded-data" is to be human OR machine readable (Im not defining that here). and I will be marking commentary below this point with the C++ comment prefix "//" // Object verification starts here My Custom AV Crossgrid Mohawk MIT // human readable ... 0000-0000-0000-0000-0001 ... ... // Object verifies to here // Processing concepts... any "object" as described above will have mixed attributes when export/imported across systems, it may *gain* attributes but transfer back to the originating system will include an "update-check" mechanism and notification of author when a tampered item is detected... Yes it breaks any "complex" down into bare primitive parts for various systems, and also translates into "asset+inventory" functions of SL being merged when out of that ecosystem along with trusted transfer mechanisms being used for adding attributes where the author permits or the author can be specific and use system permission markers on multiple systems where editing becomes available. This does have an enabling feature in that an incomplete object can be invalidated at point of transfer where limitation of connection makes enforcement occur in similar to a fashion of international travel. (you are crossing a great divide of some kind with the object)... The above is to be defined as an inflexible bottom layer (physical format) similar to the "layered transport" mechanisms already in use... recognition and use of any particular attributes by human or machine processes is to be done as a seperate layer on top of this "formatted" datastream... This allows for encoding to a file OR encoding for transfer across the network, either whole or not at all (the encoding needs to have a complete transfer)...=20 anyone who does make a "damaged" system will have it as a compromised server, not as client system for any particular server. also existing systems as example uses already exist under both MS and GPL licenses, so there is existing code-base re-usable to this context... I submit the above as potentially expanding on the MIME encoding transport of Email already in use and the way that is "multipart message boundary" marked for each piece of a message and loss of one part breaking the message and invalidating it. Sincerely, Jeremy On Mon, 2009-02-23 at 10:18 +0100, Jesrad wrote: > Imagine for a second that the cross-grid protocol mandate somehow that > objects made on one grid be hosted and served to clients from this > grid, and not transfered to other grid servers / simulators (though > the owner may have the third-party possibility of exporting from one > and importing to another so it is hosted multiple times and thus > exists in multiple instances). >=20 > >From there any specific policy of "DRM" would purely be a matter of > specific grid implementation. I would say that a lot of headaches and > flames would be averted, saving us the trouble of directly addressing > these matters in the MMOX scope itself and leaving them for > grid-caretakers and their own customers to discuss and decide policy > about. >=20 > Please, everyone, let me know what you think of this. >=20 > On Mon, Feb 23, 2009 at 9:59 AM, Gareth Nelson wrote= : > > Just been talking to Adam about this and knocked out a very very rough > > spec. It may be early in the game to discuss this issue, but it's one > > that drives a lot of emotion in people on all sides of the debate. > > > > So, without further a-do, here's a rough spec for a DSL (Domain > > Specific Language) for permissions to discuss (copied and pasted from > > my vim session, excuse any formatting weirdness): > > Original concept courtesy of Adam Frisby, see > > http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/ > > > > Very very rough thinking out loud > > > > Each asset has a set of metadata fields: > > Author > > Creation timestamp > > Last modified timestamp > > Logs of modifications? (TBD) > > > > Possible actions: > > Copy > > Modify > > Transfer > > Transfer for cash > > > > Each action attached to a simple function that returns a boolean value > > if action is allowed. > > Data types: > > Entity > > Describes a user, organisation, system or network > > Asset > > Describes an asset ;) > > Location > > Describes a virtual location, rather than a physical sys= tem > > Time > > Date and time :) > > > > Entity has these fields: > > Name > > UUID > > Class (person, organisation, system, network) > > Optional fields for person entities: > > Agent domain? (TBD) > > System (what system is the user connecting from - may be withhel= d for > > privacy reasons) > > Location (where in the metaverse are they?) > > Optional fields for organisation entities: > > Organisation type (nonprofit/commercial/government etc) > > Company type (for corporations: LLC/Ltd/PLC/whatever) > > Address (i.e postal address) > > Technical contact (a person entity!) > > Optional fields for system entities: > > Platform > > System hash (hash of various bits of hardware, HD serial and eth= ernet MAC etc) > > Network > > Current IP address > > Optional fields for network entity > > Technical contact (heh, redundant) > > CIDR prefix > > > > Asset > > Name > > MIME type > > UUID > > Creator > > Creation time > > Last modified time > > Last modified by > > > > Location > > TBD (Obviously not the SL style Region/x/y/z) > > > > Time > > You need to ask? ok, > > Day > > Week > > Month > > Year > > Hour > > Minute > > Second > > All integers > > > > Simple comparision operators to match on what is passed to the function= s > > !=3D, =3D=3D, >, <, >=3D, <=3D, a few simple string functions, the usua= l suspects > > > > function prototypes: > > copy(Entity src, Location location, Time time, Asset ass) > > src =3D=3D the user currently holding the asset who wishes = to copy it > > location =3D=3D the location the requesting user is inhabiting a= t present > > time =3D=3D the time the request was made at (just in case t= here's > > batch processing or serious latency) > > ass =3D=3D the asset being copied > > modify(Entity modifier, Asset ass, Time time, Location loc) > > modifier =3D=3D the entity trying to modify > > ass =3D=3D the entity they're trying to modify > > time =3D=3D the current time > > loc =3D=3D where is our modifier while they're trying to mo= dify? > > transfer(Entity src, Entity dst, Location loc, Time time, Asset ass) > > Same as copy essentially > > sell() is just transfer, but invoked for transfers in exchange for comp= ensation > > > > The modify() function could probably do with a description (if > > possible) of the modification being requested, for example in my own > > work i'd want to prohibit modifications to the permissions in order to > > enforce the GPL, others may have different requirements. > > > > > > DANGER! DANGER! READ: > > Any system that can be proposed here can only be used to express > > intent, it can express that intent very clearly using a DSL as i've > > roughly > > spec'ed out above, but it will never be possible to actually > > enforce it on systems that do not want to enforce it. I'll note that > > personally I > > absolutely hate DRM for the most part, but if it's going to be a > > reality it should be done right, and should allow any type of license > > to be roughly > > expressed in a way that can be handled by automated systems. If = for > > no other reason than mere practicality, a decent DSL for specifying > > what > > permissions an author of a copyrighted work has granted under > > existing copyright law can be useful and saves having to pester the > > author. > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-xflyd5Ng14+76UaU6hVZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJonKGAAoJECHrKutFYVwTHdYQAKp2QM5nZBuFaxTp7LHzgFpX mrwH4SABMwp0VgkG/f46Y5yCDZTPYTmkMUy3xqGbvRNY+uCigkV479kzV/5IhnQ9 sVvl3DOCTqvNsvSUouFxItiZAxnG+Ro/hw2Xr+5AxopVh2hokjlWM+6un2Qvd+HY pPtjjynLLlwgi6vRQDff+DzLAfnPRKVAi/esdI/D7AcMAEM/G/nxyG/XvbP7d/p7 eV1hdoD0HQgZzt6UP+GuKktDBBf0918QY3pUsR0wqGxdcYLhp9ZCqw1TeScIfuGG VugKPIYoV+v6xl1DSxYhgnJBOJqnzkotp6bZfZBB8Ib6KxE//F8qJu7vA1a5nEul FWH65jriO4oQouDYn3PgHxw8xdO4kgzi1kwt3HU93A/EnOCWnWgK0iNEwDnq9dpI p0XvaGc5Vn2+hp2PMknnqOqLOZfLcDZUND4GqtcO+ik6ynl/djJ0BRLTvjdaLghP 0pIo/XPjxW2ebesxrMM1A+sPHRXjNx5LOXRs/Yg5OELtriQ8zV7UXDMNOHtpTlGU euAfqynjJq4oKwCl/gP2DW1EtCJVIJFHS+YC4oxDPz18abPXmbXwDBLrEXoXqdtn OwGVOdyhczP8/4AJh4f+T3ES4V7XEwBRhvM9ZSnI2XyLq8RzSAUOB1JsrBec5CbU rL9tMz5WFEw+WIV91raE =kWYh -----END PGP SIGNATURE----- --=-xflyd5Ng14+76UaU6hVZ-- From jesrad@gmail.com Mon Feb 23 02:10:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CE383A6AC4 for ; Mon, 23 Feb 2009 02:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.584 X-Spam-Level: X-Spam-Status: No, score=-1.584 tagged_above=-999 required=5 tests=[AWL=-0.785, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rs7CX6LONfn for ; Mon, 23 Feb 2009 02:10:00 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id E7FEB3A67C1 for ; Mon, 23 Feb 2009 02:09:59 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so1448871fkf.5 for ; Mon, 23 Feb 2009 02:10:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=CUO/sH5rrPl+9zJgGIuLKdgcL7I49IRcU1kj+k4pmEE=; b=VDru4MJwVcEX4ubG0GVUoXt4ic3k1M6YqMqspne+XAP61/cQXNLCufuazGQQXncGbe ACMGXJ2pmzVLIbOOZ9b1ZUX901XlgQYtSz8oxfIyj8iiwyPjbuQHFXFSbVmlAtymNneQ xZgjarcaR/Ke+X049zBrg0yJW7wsrqiv5f2Sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=W/C5wK7lxgPhReM7v//92rO8Rx7RBsVqiYt5NbDT7LGmjZxusXeJncKexAcBSdupyJ gwEjbGTcIkPsCWwEKSw8CPB7Z5CTmsBR7yJqnjoPU4MRcEa5Y2JIdYKSATOioDO0AC4b V0yj54HOiRNLY4cqyy51gR3ExoCDoHqApYZkg= MIME-Version: 1.0 Received: by 10.180.214.15 with SMTP id m15mr1471846bkg.78.1235383815505; Mon, 23 Feb 2009 02:10:15 -0800 (PST) In-Reply-To: <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> Date: Mon, 23 Feb 2009 11:10:15 +0100 Message-ID: <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> From: Jesrad To: Gareth Nelson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:10:01 -0000 > Some people are going to insist on the DRM or not allow their content > to be transferred at all And some people like me will insist that there is a way to do it that cannot be prevented by third-party permissions system like this. > I am absolutely NOT advocating DRM as a good thing, what I am > advocating is a system similar to DRM which simply tells you what you > are legally allowed to do. If you choose to ignore the permissions and > thus violate the copyright, that is between you and the courts I disagree. There is a very obvious situation where it is not only legal to ignore permissions, but also illegal to have such restrictions in place, and that is precisely the situation I am in with regards to virtual world content. Where in your proposal do I have the possibility of restricting further owners from restricting further owners from copying, transferring, transferring for cash, etc. ? And even if you carve up more specs for this case, then what about the case where the creator wants to restrict further owner from restricting further owners from restricting further owners from copying/selling/giving etc. ? I hope you see where this is going. On Mon, Feb 23, 2009 at 10:31 AM, Gareth Nelson wrote: > Some people are going to insist on the DRM or not allow their content > to be transferred at all, at least if there's a scheme in place like > this it will reduce headaches (at least until hell freezes over and > copyright law is overthrown). > I am absolutely NOT advocating DRM as a good thing, what I am > advocating is a system similar to DRM which simply tells you what you > are legally allowed to do. If you choose to ignore the permissions and > thus violate the copyright, that is between you and the courts, but > you should at least be able to find out where you stand legally > without pestering copyright holders every time, and it would help if > automated systems can aid you. > > On Mon, Feb 23, 2009 at 9:18 AM, Jesrad wrote: >> Imagine for a second that the cross-grid protocol mandate somehow that >> objects made on one grid be hosted and served to clients from this >> grid, and not transfered to other grid servers / simulators (though >> the owner may have the third-party possibility of exporting from one >> and importing to another so it is hosted multiple times and thus >> exists in multiple instances). >> >> From there any specific policy of "DRM" would purely be a matter of >> specific grid implementation. I would say that a lot of headaches and >> flames would be averted, saving us the trouble of directly addressing >> these matters in the MMOX scope itself and leaving them for >> grid-caretakers and their own customers to discuss and decide policy >> about. >> >> Please, everyone, let me know what you think of this. >> >> On Mon, Feb 23, 2009 at 9:59 AM, Gareth Nelson wrote: >>> Just been talking to Adam about this and knocked out a very very rough >>> spec. It may be early in the game to discuss this issue, but it's one >>> that drives a lot of emotion in people on all sides of the debate. >>> >>> So, without further a-do, here's a rough spec for a DSL (Domain >>> Specific Language) for permissions to discuss (copied and pasted from >>> my vim session, excuse any formatting weirdness): >>> Original concept courtesy of Adam Frisby, see >>> http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/ >>> >>> Very very rough thinking out loud >>> >>> Each asset has a set of metadata fields: >>> Author >>> Creation timestamp >>> Last modified timestamp >>> Logs of modifications? (TBD) >>> >>> Possible actions: >>> Copy >>> Modify >>> Transfer >>> Transfer for cash >>> >>> Each action attached to a simple function that returns a boolean value >>> if action is allowed. >>> Data types: >>> Entity >>> Describes a user, organisation, system or network >>> Asset >>> Describes an asset ;) >>> Location >>> Describes a virtual location, rather than a physical system >>> Time >>> Date and time :) >>> >>> Entity has these fields: >>> Name >>> UUID >>> Class (person, organisation, system, network) >>> Optional fields for person entities: >>> Agent domain? (TBD) >>> System (what system is the user connecting from - may be withheld for >>> privacy reasons) >>> Location (where in the metaverse are they?) >>> Optional fields for organisation entities: >>> Organisation type (nonprofit/commercial/government etc) >>> Company type (for corporations: LLC/Ltd/PLC/whatever) >>> Address (i.e postal address) >>> Technical contact (a person entity!) >>> Optional fields for system entities: >>> Platform >>> System hash (hash of various bits of hardware, HD serial and ethernet MAC etc) >>> Network >>> Current IP address >>> Optional fields for network entity >>> Technical contact (heh, redundant) >>> CIDR prefix >>> >>> Asset >>> Name >>> MIME type >>> UUID >>> Creator >>> Creation time >>> Last modified time >>> Last modified by >>> >>> Location >>> TBD (Obviously not the SL style Region/x/y/z) >>> >>> Time >>> You need to ask? ok, >>> Day >>> Week >>> Month >>> Year >>> Hour >>> Minute >>> Second >>> All integers >>> >>> Simple comparision operators to match on what is passed to the functions >>> !=, ==, >, <, >=, <=, a few simple string functions, the usual suspects >>> >>> function prototypes: >>> copy(Entity src, Location location, Time time, Asset ass) >>> src == the user currently holding the asset who wishes to copy it >>> location == the location the requesting user is inhabiting at present >>> time == the time the request was made at (just in case there's >>> batch processing or serious latency) >>> ass == the asset being copied >>> modify(Entity modifier, Asset ass, Time time, Location loc) >>> modifier == the entity trying to modify >>> ass == the entity they're trying to modify >>> time == the current time >>> loc == where is our modifier while they're trying to modify? >>> transfer(Entity src, Entity dst, Location loc, Time time, Asset ass) >>> Same as copy essentially >>> sell() is just transfer, but invoked for transfers in exchange for compensation >>> >>> The modify() function could probably do with a description (if >>> possible) of the modification being requested, for example in my own >>> work i'd want to prohibit modifications to the permissions in order to >>> enforce the GPL, others may have different requirements. >>> >>> >>> DANGER! DANGER! READ: >>> Any system that can be proposed here can only be used to express >>> intent, it can express that intent very clearly using a DSL as i've >>> roughly >>> spec'ed out above, but it will never be possible to actually >>> enforce it on systems that do not want to enforce it. I'll note that >>> personally I >>> absolutely hate DRM for the most part, but if it's going to be a >>> reality it should be done right, and should allow any type of license >>> to be roughly >>> expressed in a way that can be handled by automated systems. If for >>> no other reason than mere practicality, a decent DSL for specifying >>> what >>> permissions an author of a copyrighted work has granted under >>> existing copyright law can be useful and saves having to pester the >>> author. >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > From gareth@litesim.com Mon Feb 23 02:17:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9BD13A6874 for ; Mon, 23 Feb 2009 02:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkIEX8IOlh6E for ; Mon, 23 Feb 2009 02:17:23 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.157]) by core3.amsl.com (Postfix) with ESMTP id 76EBF3A67C1 for ; Mon, 23 Feb 2009 02:17:23 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6465094poe.4 for ; Mon, 23 Feb 2009 02:17:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.151.18 with SMTP id d18mr1969919rvo.134.1235384260035; Mon, 23 Feb 2009 02:17:40 -0800 (PST) In-Reply-To: <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> Date: Mon, 23 Feb 2009 10:17:40 +0000 Message-ID: <61dbdd7d0902230217s4ec01b1y48eb5a55d536917b@mail.gmail.com> From: Gareth Nelson To: Jesrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:17:24 -0000 "Where in your proposal do I have the possibility of restricting further owners from restricting further owners from copying, transferring, transferring for cash, etc. ?" That is precisely one of my own reasons for wanting a more flexible system. I know if I release anything under the GPL on SL, people will go and modify it remove the permissions without a second thought. Basically, i'm trying to define the things restricted by copyright law, and then tie them to functions saying whether the author has said "you're allowed to do this" or "you're not allowed to do this". Basically, a way for automated systems to do what requires human intervention right now - humans have to pester copyright holders or interpret the license document. Whether or not you actually OBEY the license is up to you and the relevant legal authorities. On Mon, Feb 23, 2009 at 10:10 AM, Jesrad wrote: >> Some people are going to insist on the DRM or not allow their content >> to be transferred at all > > And some people like me will insist that there is a way to do it that > cannot be prevented by third-party permissions system like this. > >> I am absolutely NOT advocating DRM as a good thing, what I am >> advocating is a system similar to DRM which simply tells you what you >> are legally allowed to do. If you choose to ignore the permissions and >> thus violate the copyright, that is between you and the courts > > I disagree. There is a very obvious situation where it is not only > legal to ignore permissions, but also illegal to have such > restrictions in place, and that is precisely the situation I am in > with regards to virtual world content. Where in your proposal do I > have the possibility of restricting further owners from restricting > further owners from copying, transferring, transferring for cash, etc. > ? And even if you carve up more specs for this case, then what about > the case where the creator wants to restrict further owner from > restricting further owners from restricting further owners from > copying/selling/giving etc. ? > > I hope you see where this is going. > > On Mon, Feb 23, 2009 at 10:31 AM, Gareth Nelson wrote: >> Some people are going to insist on the DRM or not allow their content >> to be transferred at all, at least if there's a scheme in place like >> this it will reduce headaches (at least until hell freezes over and >> copyright law is overthrown). >> I am absolutely NOT advocating DRM as a good thing, what I am >> advocating is a system similar to DRM which simply tells you what you >> are legally allowed to do. If you choose to ignore the permissions and >> thus violate the copyright, that is between you and the courts, but >> you should at least be able to find out where you stand legally >> without pestering copyright holders every time, and it would help if >> automated systems can aid you. >> >> On Mon, Feb 23, 2009 at 9:18 AM, Jesrad wrote: >>> Imagine for a second that the cross-grid protocol mandate somehow that >>> objects made on one grid be hosted and served to clients from this >>> grid, and not transfered to other grid servers / simulators (though >>> the owner may have the third-party possibility of exporting from one >>> and importing to another so it is hosted multiple times and thus >>> exists in multiple instances). >>> >>> From there any specific policy of "DRM" would purely be a matter of >>> specific grid implementation. I would say that a lot of headaches and >>> flames would be averted, saving us the trouble of directly addressing >>> these matters in the MMOX scope itself and leaving them for >>> grid-caretakers and their own customers to discuss and decide policy >>> about. >>> >>> Please, everyone, let me know what you think of this. >>> >>> On Mon, Feb 23, 2009 at 9:59 AM, Gareth Nelson wrote: >>>> Just been talking to Adam about this and knocked out a very very rough >>>> spec. It may be early in the game to discuss this issue, but it's one >>>> that drives a lot of emotion in people on all sides of the debate. >>>> >>>> So, without further a-do, here's a rough spec for a DSL (Domain >>>> Specific Language) for permissions to discuss (copied and pasted from >>>> my vim session, excuse any formatting weirdness): >>>> Original concept courtesy of Adam Frisby, see >>>> http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/ >>>> >>>> Very very rough thinking out loud >>>> >>>> Each asset has a set of metadata fields: >>>> Author >>>> Creation timestamp >>>> Last modified timestamp >>>> Logs of modifications? (TBD) >>>> >>>> Possible actions: >>>> Copy >>>> Modify >>>> Transfer >>>> Transfer for cash >>>> >>>> Each action attached to a simple function that returns a boolean value >>>> if action is allowed. >>>> Data types: >>>> Entity >>>> Describes a user, organisation, system or network >>>> Asset >>>> Describes an asset ;) >>>> Location >>>> Describes a virtual location, rather than a physical system >>>> Time >>>> Date and time :) >>>> >>>> Entity has these fields: >>>> Name >>>> UUID >>>> Class (person, organisation, system, network) >>>> Optional fields for person entities: >>>> Agent domain? (TBD) >>>> System (what system is the user connecting from - may be withheld for >>>> privacy reasons) >>>> Location (where in the metaverse are they?) >>>> Optional fields for organisation entities: >>>> Organisation type (nonprofit/commercial/government etc) >>>> Company type (for corporations: LLC/Ltd/PLC/whatever) >>>> Address (i.e postal address) >>>> Technical contact (a person entity!) >>>> Optional fields for system entities: >>>> Platform >>>> System hash (hash of various bits of hardware, HD serial and ethernet MAC etc) >>>> Network >>>> Current IP address >>>> Optional fields for network entity >>>> Technical contact (heh, redundant) >>>> CIDR prefix >>>> >>>> Asset >>>> Name >>>> MIME type >>>> UUID >>>> Creator >>>> Creation time >>>> Last modified time >>>> Last modified by >>>> >>>> Location >>>> TBD (Obviously not the SL style Region/x/y/z) >>>> >>>> Time >>>> You need to ask? ok, >>>> Day >>>> Week >>>> Month >>>> Year >>>> Hour >>>> Minute >>>> Second >>>> All integers >>>> >>>> Simple comparision operators to match on what is passed to the functions >>>> !=, ==, >, <, >=, <=, a few simple string functions, the usual suspects >>>> >>>> function prototypes: >>>> copy(Entity src, Location location, Time time, Asset ass) >>>> src == the user currently holding the asset who wishes to copy it >>>> location == the location the requesting user is inhabiting at present >>>> time == the time the request was made at (just in case there's >>>> batch processing or serious latency) >>>> ass == the asset being copied >>>> modify(Entity modifier, Asset ass, Time time, Location loc) >>>> modifier == the entity trying to modify >>>> ass == the entity they're trying to modify >>>> time == the current time >>>> loc == where is our modifier while they're trying to modify? >>>> transfer(Entity src, Entity dst, Location loc, Time time, Asset ass) >>>> Same as copy essentially >>>> sell() is just transfer, but invoked for transfers in exchange for compensation >>>> >>>> The modify() function could probably do with a description (if >>>> possible) of the modification being requested, for example in my own >>>> work i'd want to prohibit modifications to the permissions in order to >>>> enforce the GPL, others may have different requirements. >>>> >>>> >>>> DANGER! DANGER! READ: >>>> Any system that can be proposed here can only be used to express >>>> intent, it can express that intent very clearly using a DSL as i've >>>> roughly >>>> spec'ed out above, but it will never be possible to actually >>>> enforce it on systems that do not want to enforce it. I'll note that >>>> personally I >>>> absolutely hate DRM for the most part, but if it's going to be a >>>> reality it should be done right, and should allow any type of license >>>> to be roughly >>>> expressed in a way that can be handled by automated systems. If for >>>> no other reason than mere practicality, a decent DSL for specifying >>>> what >>>> permissions an author of a copyrighted work has granted under >>>> existing copyright law can be useful and saves having to pester the >>>> author. >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >> > From gareth@litesim.com Mon Feb 23 02:21:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E1AE3A67C1 for ; Mon, 23 Feb 2009 02:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74JEComxAogb for ; Mon, 23 Feb 2009 02:21:02 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.226]) by core3.amsl.com (Postfix) with ESMTP id 843093A6874 for ; Mon, 23 Feb 2009 02:21:02 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id e34so1213718qbe.41 for ; Mon, 23 Feb 2009 02:21:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.18.15 with SMTP id v15mr1962403rvi.197.1235384478847; Mon, 23 Feb 2009 02:21:18 -0800 (PST) In-Reply-To: <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> Date: Mon, 23 Feb 2009 10:21:18 +0000 Message-ID: <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> From: Gareth Nelson To: Jesrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:21:03 -0000 On Mon, Feb 23, 2009 at 10:10 AM, Jesrad wrote: >> Some people are going to insist on the DRM or not allow their content >> to be transferred at all > > And some people like me will insist that there is a way to do it that > cannot be prevented by third-party permissions system like this. But that's besides the point, since doing so isn't going to convince people to allow the content to move AND this system does not in fact prevent anything, it's a machine-readable version of the license - the only force comes from compliant systems and users or the courts. From jesrad@gmail.com Mon Feb 23 02:26:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB48628C117 for ; Mon, 23 Feb 2009 02:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdFr0Pk+ALpy for ; Mon, 23 Feb 2009 02:26:56 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 896263A6874 for ; Mon, 23 Feb 2009 02:26:55 -0800 (PST) Received: by fxm11 with SMTP id 11so1567397fxm.13 for ; Mon, 23 Feb 2009 02:27:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ayvpKFggIlIAbAEHy84e+ld3nBpoRHkUq8VFPrnvI50=; b=s/syYrV/1aYE2g/+I0umWt4k3uvchyXgf8oYdmYhAQV67Ra3txuzeMoNT2pr7fUxVV ZIi4TYy3PtGwXDktXEPVy45T2KNqw5lkXtPZP8vXX2MBjaL8p5WAxT/c3uHrSJcX3O4A /alrqcwgFCfdg5hkcj8AkiDLjzHe66fC2wXNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=jYd+cT6Q4Aag6xeezBesoxOxl1aQeZm400Ox7FBioWmT3rB6onc2RTKhNu5FeXGf+6 nftrg/mqbBxqKqQAMXn5NX6xV7ZnKP3zD+tl6Zp7GV8g4WVxNbZnDSoizjjNmEQ62ZGv VgMhTU5pYWhoW0Nh4EBWiPL2wDW5NKkf8mRjo= MIME-Version: 1.0 Received: by 10.181.202.8 with SMTP id e8mr1479054bkq.25.1235384831602; Mon, 23 Feb 2009 02:27:11 -0800 (PST) In-Reply-To: <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> Date: Mon, 23 Feb 2009 11:27:11 +0100 Message-ID: <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> From: Jesrad To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:26:56 -0000 Hmm, "it's not gonna enforce IP technically" was not the point I wanted to make. The actual point is: attempting to define a mechanism for signalling what categories of actions are permitted or not under a specific copyright law (which may or may not be applicable depending on national/sovereign context) is a non-starter because of infinite recursion. This is one of the main reasons I suggest curtaining the issue entirely by adopting a multiple-host approach, where content (but not necessarily the MMOX-layer object reference itself) remains hosted on the originating grid and is not replicated between different grids through the cross-grid protocol. The other reason for following such an approach, is that it's the only one compatible with existing P2P VWs like Solipsis. On Mon, Feb 23, 2009 at 11:21 AM, Gareth Nelson wrote: > On Mon, Feb 23, 2009 at 10:10 AM, Jesrad wrote: >>> Some people are going to insist on the DRM or not allow their content >>> to be transferred at all >> >> And some people like me will insist that there is a way to do it that >> cannot be prevented by third-party permissions system like this. > > But that's besides the point, since doing so isn't going to convince > people to allow the content to move AND this system does not in fact > prevent anything, it's a machine-readable version of the license - the > only force comes from compliant systems and users or the courts. > From cathypfeffer@gmail.com Mon Feb 23 02:38:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3602C3A698F for ; Mon, 23 Feb 2009 02:38:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71JwYvzgu23Z for ; Mon, 23 Feb 2009 02:38:51 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by core3.amsl.com (Postfix) with ESMTP id F09D13A6874 for ; Mon, 23 Feb 2009 02:38:50 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d3so364851nfc.39 for ; Mon, 23 Feb 2009 02:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=uDdbC7qboZ5XCGfN+OPlyi0nbNazWv4NgfOUpBJIY30=; b=cFhBu3BSF1V/usi8kAOdLpaOpDtGwtNE9C89CDD+zUvgJ0yw4wyhGAOY7ho4tiCHoa PCO8wYQYduunsbHoxY3pdQ3Wk2JeUytp0n6eWthxU4DHFno6tEjj1KSUVd2Es/8Od6Rk 6949pIxOByxhPsoQv1riE82j+Y9LPi3KY1X+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=LOE2GCxFaDv1v+iVgVTQg8Z/B3pNF3cF6N+3cCVrmzTSVrI0qkQObyte/+icIrNYD4 KEdJ+BAzaZTLChzDv271FkwY7G7HDQkPRcSvs6l3mdUehmLWU8lqnZQenIa7AfoxMhq5 q3NLsPzs2DEIIzv+EpUrlKYYEPGusjvGAr+q8= MIME-Version: 1.0 Received: by 10.210.134.5 with SMTP id h5mr288673ebd.146.1235385547796; Mon, 23 Feb 2009 02:39:07 -0800 (PST) Date: Mon, 23 Feb 2009 11:39:07 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c12e2bcb2110463939c45 Subject: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:38:52 -0000 --0015174c12e2bcb2110463939c45 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Jon Watte wrote: > > Meadhbh Hamrick (Infinity) wrote: > > > > > > success > > true > > something_i_like_to_eat_on_sundays > > bananas > > > > > > IMO, that's a terrible serialization, because it depends on ordering. > While XML is ordered, this particular serialization makes it hard to > write XPath that selects "the string that comes after key success but > before key something_i_like_to_eat_on_sundays". Yes, I have already made this very same remark to Infinity in private. The "classical way" to solve this is to add new wrapper tags: success true something_i_like_to_eat_on_sundays bananas but that would make the "angle bracket tax" even more expensive to pay... It's not *that* complicated in XPath (following-sibling axis is made for that). But it's just... well... unusual practice in the XML world. I have the strong feeling that depending on the order is calling for trouble, although I have not found yet examples where it would lead to real problems, other than ugly XPath constructions or unusual DTD fragments. -- Cathy --0015174c12e2bcb2110463939c45 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jon Watte wrote:
> > Meadhbh Hamrick (Infinity) wrote:
> >= ; <llsd>
> >   <map>
> >     &= lt;key>success</key>
> >     <boolean>tru= e</boolean>
> >     <key>something_i_like_to= _eat_on_sundays</key>
> >     <string>bananas</string>
> > &= nbsp; </map>
> > </llsd>
>
> IMO, that'= ;s a terrible serialization, because it depends on ordering.
> While= XML is ordered, this particular serialization makes it hard to
> write XPath that selects "the string that comes after key success= but
> before key something_i_like_to_eat_on_sundays".

Y= es, I have already made this very same remark to Infinity in private.

The "classical way" to solve this is to add new wrapper tags:=

<llsd>
   <map>
      <entry>         <key>success</key>
 &n= bsp;      <boolean>true</boolean>
 =      </entry>
      &= lt;entry>
        <key>something_i_lik= e_to_eat_on_sundays</key>
        <string&g= t;bananas</string>
       </entry>
   </ma= p>
</llsd>

but that would make the "angle bracket tax" even more expensi= ve to pay...

It's not *that* complicated in XPath (following-sib= ling axis is made for that). But it's just... well... unusual practice = in the XML world.

I have the strong feeling that depending on the order is calling for tr= ouble, although I have not found yet examples where it would lead to real p= roblems, other than ugly XPath constructions or unusual DTD fragments.

--
Cathy
--0015174c12e2bcb2110463939c45-- From morgaine.dinova@googlemail.com Mon Feb 23 02:57:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5108428C185 for ; Mon, 23 Feb 2009 02:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPVQK08qr+o7 for ; Mon, 23 Feb 2009 02:57:12 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id C218328C10B for ; Mon, 23 Feb 2009 02:57:11 -0800 (PST) Received: by bwz5 with SMTP id 5so4589463bwz.13 for ; Mon, 23 Feb 2009 02:57:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=M7GDecTJDSWIR/JxxQKbpg1e0MdACZ4Yem8B1L5x66I=; b=h116sKi0CMzhRk9Ei8fT8qK6UUWk7Ccbqa9f1dcxEpr1FaTbM0VEvU+fGNvQYzG8Nf NfrwQOQhWzmzQj8y3IMbKtJGpk9r6SOIM0ATzIePHt8rwJCB5Ea6rEJInise90m5peqv Dgtnu+JOGXQg/CRjp6zPNr2KOIqbmN5WPQTJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hh25B5vQeEUfatUc1/1Ie6woP0fXKLS48CDCW2SDQuEFCt29qp5G0u5bwwQpHjHGVZ z2qM5oAPnWH2s+52tvuNEOj88hUVMCyw7SLq2iegyHq3Z3lWyuQc06v/RT6LcB8+YJuS JO/I1QzMvUSfOu/m7YQZR1J9o8+81n+ZZ9ucY= MIME-Version: 1.0 Received: by 10.180.228.19 with SMTP id a19mr1485500bkh.93.1235386648970; Mon, 23 Feb 2009 02:57:28 -0800 (PST) In-Reply-To: <49A19C5C.10309@gmail.com> References: <639687.52284.qm@web82606.mail.mud.yahoo.com> <49A09825.2040808@gmail.com> <492298.73712.qm@web82607.mail.mud.yahoo.com> <49A19C5C.10309@gmail.com> Date: Mon, 23 Feb 2009 10:57:28 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=001636c9247c5f4589046393de73 Cc: "mmox@ietf.org" Subject: Re: [mmox] MMOX Group Charter X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:57:13 -0000 --001636c9247c5f4589046393de73 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Feb 22, 2009 at 6:41 PM, Jon Watte wrote: > Morgaine wrote: > >> Members of the AWG use this for group communication, as in the case of the >> aforementioned MMOX links page that I maintain at >> https://wiki.secondlife.com/wiki/MMOX. There is no Linden Lab >> involvement in this, although of course they are welcome to improve the page >> if they wish, as is everyone else. >> > > So you think that "becoming a Second Life resident" is not an unreasonable > requirement for someone participating in an open standards effort? > > I think someone's making a mountain out of a molehill. ;-) There is no "document" at that URL that anyone needs to reference. It's just a page of links, partly to make our scattered posts defining versions #2, #3 and #4 of the draft charter more accessible, and exactly the same information on that matter is available in my MMOX post here: http://www.ietf.org/mail-archive/web/mmox/current/msg00349.html But you know that already, since the wiki page is publicly accessible. If the complaint is about write access, then whichever wiki one uses would still require a login to be registered. What's the difference between getting a wiki login from Linden Lab or from any other provider? It doesn't force you to use Second Life, and it doesn't cost anything. And Lindens aren't evil, generally. ;-) A better complaint would be to ask why the IETF doesn't provide a wiki for IETF groups to use directly, other than (apparently) indirectly via chairs and ADs. Seriously, it's a molehill, and I think we have bigger fish to fry. Morgaine. --001636c9247c5f4589046393de73 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Feb 22, 2009 at 6:41 PM, Jon Wat= te <jwatte@gmail.com> wrote:
Morgaine wrote:
Members of the AWG use this for group communication, as in the case of the = aforementioned MMOX links page that I maintain at https://wiki.secondlife.com/wiki= /MMOX.  There is no Linden Lab involvement in this, although of co= urse they are welcome to improve the page if they wish, as is everyone else= .

So you think that "becoming a Second Life resident" is not an unr= easonable requirement for someone participating in an open standards effort= ?


I think someone's making a mountain out o= f a molehill. ;-)

There is no "document" at that URL that = anyone needs to reference.  It's just a page of links, partly to m= ake our scattered posts defining versions #2, #3 and #4 of the draft charte= r more accessible, and exactly the same information on that matter is avail= able in my MMOX post here:  http://www.ietf.org/mai= l-archive/web/mmox/current/msg00349.html

But you know that already, since the wiki page is publicly accessible.<= br>
If the complaint is about write access, then whichever wiki one uses= would still require a login to be registered.  What's the differe= nce between getting a wiki login from Linden Lab or from any other provider= ?  It doesn't force you to use Second Life, and it doesn't cos= t anything.  And Lindens aren't evil, generally. ;-)  A bette= r complaint would be to ask why the IETF doesn't provide a wiki for IET= F groups to use directly, other than (apparently) indirectly via chairs and= ADs.

Seriously, it's a molehill, and I think we have bigger fish to fry.=

Morgaine.
--001636c9247c5f4589046393de73-- From cathypfeffer@gmail.com Mon Feb 23 02:58:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AAD828C10B for ; Mon, 23 Feb 2009 02:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnYG9fplgFJY for ; Mon, 23 Feb 2009 02:58:23 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id D258E28C20A for ; Mon, 23 Feb 2009 02:58:22 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d3so366931nfc.39 for ; Mon, 23 Feb 2009 02:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=UquVtXsIxBFeahAEmT2ySKP50WJz0rFh84bX2S21YjE=; b=aGkX8+1FCVyhu9jTR6qr7hY9U4c9/N3YThImdlj/PV5NMBPfLFab25X8q1OT2VNmYD JZbOJfXg1br4U6a+g5eOY7yc5fbgMuPp7YgTN5rbSIVU/dJm2iwqINwqGNcaewdGpd+V dczeTahJRSTEYXIKWo+0EbMWeYQqeTWuLBW+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nAid2B0YXFufCa22HyaQNpVCbG073ho08HZMDaJvRzRbQI60xgD4SsPX0ESQNbUfX3 vQh4dn9pxtV30T1UNsM9zTidTSk11Qgphcgz5wtOjeu7I/CRMvqrUAznQwXkhueIrvVA NopXM3EhInSU9VBIFe59zVhLoD+9b4/2ICgy0= MIME-Version: 1.0 Received: by 10.210.87.19 with SMTP id k19mr3363732ebb.75.1235386719883; Mon, 23 Feb 2009 02:58:39 -0800 (PST) Date: Mon, 23 Feb 2009 11:58:39 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c3c6099533e046393e23a Subject: [mmox] Basic data description X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 10:58:24 -0000 --0015174c3c6099533e046393e23a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Jon Watte said: > At a minimum, I think that "publication of LLSD draft" should be changed > to something worded like "publication of a basic data description and > serialization formats RFC." Yes. That would allow an approach that is not biased towards LLSD, even though LLSD remains a very valid potential choice. I can see another reason for doing that. IETF, in my understanding, is a communication standards organism. That means that abstract data types is out of their mission, just like a programming language or an algorithm would be. But serialization formats definitely are within their mission. So putting the emphasis on the "serialization" part would, IMHO, help stick to their mission statement. -- Cathy --0015174c3c6099533e046393e23a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jon Watte said:
> At a minimum, I think that "publication of LLS= D draft" should be changed
> to something worded like "pub= lication of a basic data description and
> serialization formats RFC= ."

Yes. That would allow an approach that is not biased towa= rds LLSD, even though LLSD remains a very valid potential choice.

I = can see another reason for doing that. IETF, in my understanding, is a comm= unication standards organism. That means that abstract data types is out of= their mission, just like a programming language or an algorithm would be. = But serialization formats definitely are within their mission. So putting t= he emphasis on the "serialization" part would, IMHO, help stick t= o their mission statement.

--
Cathy
--0015174c3c6099533e046393e23a-- From jesrad@gmail.com Mon Feb 23 03:55:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4133A68AD for ; Mon, 23 Feb 2009 03:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4exp5UuXpSMs for ; Mon, 23 Feb 2009 03:55:33 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id CDE523A6801 for ; Mon, 23 Feb 2009 03:55:32 -0800 (PST) Received: by fxm11 with SMTP id 11so1648558fxm.13 for ; Mon, 23 Feb 2009 03:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=//KCus+wJlA7RBrMnEx6SsnNNh+hLzmfaDS1vV6kWg0=; b=xfbasc6ca+SjdoSjGIHcWc4qyArVsuaFQKH6AKTmM+NWs7gpCBH6ezSK8kKw5q/lZm 3vdly5NS318iJzjbGKncdHHg5Jc5qmpAimmvk0nIeHkKGrGt9nqY7VexYrkAT5gX81Kb N2RMuuHyTwiVMCF7UdPEd43kmAvUXQ0x8Zxuk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q1tV9R+ovye2Z3GlqG1wbtUxt85JWxEKwe0CRLJbtKYGh9U8uxPrFLG4gV9xAHqDd0 IM/J9PwEEHpwFEUQF4kbDfUlaBBuPQ7MeNpjsY35oTthEpFP4Lufg+2h+lsYgCSOtUhJ LkH5QIJPpBYVJ35cza2vZCv7zyxIIVgP75rgg= MIME-Version: 1.0 Received: by 10.180.253.10 with SMTP id a10mr1502193bki.65.1235390149386; Mon, 23 Feb 2009 03:55:49 -0800 (PST) In-Reply-To: <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> <49A1A22D.3080100@gmail.com> <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> Date: Mon, 23 Feb 2009 12:55:49 +0100 Message-ID: <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> From: Jesrad To: Gareth Nelson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 11:55:34 -0000 I tend to consider avatars as objects just like the others, except they are capable of a specific form of interaction that is similar (and should be identical) to vehicles. Given a uniform RPC avatars could be scripted objects indistinguishable from the rest of the VW environment. Compare this view with the existence of "bots" in SL, where a viewer is coded to run without user input, or the client-side scripts that grind your WoW character without supervision, or a few hundred other examples. That's why I see no reason to distinguish between the two categories at the level of the MMOX-layer. On Sun, Feb 22, 2009 at 8:09 PM, Gareth Nelson wrote: > Well, we need a description of the avatar itself, or what do we show > to other systems? > Note I didn't mention rezzing an avatar :) > > On Sun, Feb 22, 2009 at 7:06 PM, Jon Watte wrote: >> Gareth Nelson wrote: >>> >>> I propose HTTP for assets, with a standard base URL for each region >>> domain and agent domain, and a basic description of the avatar as >>> first step in defining the real "meat" of the 3D stuff. >>> >> >> Why is an avatar special? >> >> In fact, I find the idea of putting "rezzing" avatars into OGP very second >> life centric. Bringing an avatar to life is a function internal to the >> virtual world service provider, not something that needs to, itself, be >> interoperable. The question is: how and when does that avatar get presented >> to other systems? >> >> Btw: what does "rezzing" stand for? "Ressurecting"? In general object >> parlance, I think "instantiating" would be better, perhaps. >> >> Sincerely, >> >> jw >> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From gareth@litesim.com Mon Feb 23 03:59:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E213A69A7 for ; Mon, 23 Feb 2009 03:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.707 X-Spam-Level: X-Spam-Status: No, score=-1.707 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZGSxY7yAuE1 for ; Mon, 23 Feb 2009 03:59:13 -0800 (PST) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.230]) by core3.amsl.com (Postfix) with ESMTP id 714753A6861 for ; Mon, 23 Feb 2009 03:59:13 -0800 (PST) Received: by qb-out-0506.google.com with SMTP id e34so1235695qbe.41 for ; Mon, 23 Feb 2009 03:59:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.187.10 with SMTP id k10mr2011415rvf.81.1235390369984; Mon, 23 Feb 2009 03:59:29 -0800 (PST) In-Reply-To: <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> References: <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> <49A1A22D.3080100@gmail.com> <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> Date: Mon, 23 Feb 2009 11:59:29 +0000 Message-ID: <61dbdd7d0902230359t6b2756acw23079619bd2c2c1a@mail.gmail.com> From: Gareth Nelson To: Jesrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 11:59:14 -0000 Well, the "we need to describe it so we need to know how to display it in other worlds" applies to all objects really On Mon, Feb 23, 2009 at 11:55 AM, Jesrad wrote: > I tend to consider avatars as objects just like the others, except > they are capable of a specific form of interaction that is similar > (and should be identical) to vehicles. Given a uniform RPC avatars > could be scripted objects indistinguishable from the rest of the VW > environment. Compare this view with the existence of "bots" in SL, > where a viewer is coded to run without user input, or the client-side > scripts that grind your WoW character without supervision, or a few > hundred other examples. > > That's why I see no reason to distinguish between the two categories > at the level of the MMOX-layer. > > On Sun, Feb 22, 2009 at 8:09 PM, Gareth Nelson wrote: >> Well, we need a description of the avatar itself, or what do we show >> to other systems? >> Note I didn't mention rezzing an avatar :) >> >> On Sun, Feb 22, 2009 at 7:06 PM, Jon Watte wrote: >>> Gareth Nelson wrote: >>>> >>>> I propose HTTP for assets, with a standard base URL for each region >>>> domain and agent domain, and a basic description of the avatar as >>>> first step in defining the real "meat" of the 3D stuff. >>>> >>> >>> Why is an avatar special? >>> >>> In fact, I find the idea of putting "rezzing" avatars into OGP very second >>> life centric. Bringing an avatar to life is a function internal to the >>> virtual world service provider, not something that needs to, itself, be >>> interoperable. The question is: how and when does that avatar get presented >>> to other systems? >>> >>> Btw: what does "rezzing" stand for? "Ressurecting"? In general object >>> parlance, I think "instantiating" would be better, perhaps. >>> >>> Sincerely, >>> >>> jw >>> >>> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > From lenglish5@cox.net Mon Feb 23 04:01:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1B93A69B1 for ; Mon, 23 Feb 2009 04:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.45 X-Spam-Level: X-Spam-Status: No, score=-0.45 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVcG41Saozx4 for ; Mon, 23 Feb 2009 04:01:21 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 3D8543A6967 for ; Mon, 23 Feb 2009 04:01:21 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090223120139.SWME10385.fed1rmmtao107.cox.net@fed1rmimpo03.cox.net>; Mon, 23 Feb 2009 07:01:39 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id KQ1e1b0034N6T0Q04Q1eFz; Mon, 23 Feb 2009 07:01:39 -0500 X-Authority-Analysis: v=1.0 c=1 a=cLXfh73VNe8A:10 a=PQp3fo3PBBsA:10 a=Wajolswj7cQA:10 a=TeCk4q6oAAAA:8 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=ZH2SZ7wMQhP2TkGMOqMA:9 a=qw1pxTVqmEE4fXnMA1MA:7 a=X9sCwx2FVp-mA0y5vXVif6JXaycA:4 a=XF7b4UCPwd8A:10 a=UnpLKV8wDbIA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=306_2Wm7Z389MtEr:21 a=Nu036Ur26XZ5xp2p:21 X-CM-Score: 0.00 Message-ID: <49A29022.3070901@cox.net> Date: Mon, 23 Feb 2009 05:01:38 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jesrad References: <49A04DEB.4060301@gmail.com> <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> <49A1A22D.3080100@gmail.com> <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> In-Reply-To: <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 12:01:22 -0000 They're special because they encapsulate personal identity. One proposal for the Agent Domain is to allow a separate scripting server to feed commands to the simulator separately for avatar attachments, which would allow avatars to "take it with them" as far as scripted appearance goes (assuming the destination sim is compatible with the scripted attachments in the first place) without violating copyright on non-Creative Commons scripts. L Jesrad wrote: > I tend to consider avatars as objects just like the others, except > they are capable of a specific form of interaction that is similar > (and should be identical) to vehicles. Given a uniform RPC avatars > could be scripted objects indistinguishable from the rest of the VW > environment. Compare this view with the existence of "bots" in SL, > where a viewer is coded to run without user input, or the client-side > scripts that grind your WoW character without supervision, or a few > hundred other examples. > > That's why I see no reason to distinguish between the two categories > at the level of the MMOX-layer. > > On Sun, Feb 22, 2009 at 8:09 PM, Gareth Nelson wrote: > >> Well, we need a description of the avatar itself, or what do we show >> to other systems? >> Note I didn't mention rezzing an avatar :) >> >> On Sun, Feb 22, 2009 at 7:06 PM, Jon Watte wrote: >> >>> Gareth Nelson wrote: >>> >>>> I propose HTTP for assets, with a standard base URL for each region >>>> domain and agent domain, and a basic description of the avatar as >>>> first step in defining the real "meat" of the 3D stuff. >>>> >>>> >>> Why is an avatar special? >>> >>> In fact, I find the idea of putting "rezzing" avatars into OGP very second >>> life centric. Bringing an avatar to life is a function internal to the >>> virtual world service provider, not something that needs to, itself, be >>> interoperable. The question is: how and when does that avatar get presented >>> to other systems? >>> >>> Btw: what does "rezzing" stand for? "Ressurecting"? In general object >>> parlance, I think "instantiating" would be better, perhaps. >>> >>> Sincerely, >>> >>> jw >>> >>> >>> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From gareth@litesim.com Mon Feb 23 04:08:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1CA28C118 for ; Mon, 23 Feb 2009 04:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEWqNSEhiZIc for ; Mon, 23 Feb 2009 04:08:06 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.152]) by core3.amsl.com (Postfix) with ESMTP id 6DFC528C0F4 for ; Mon, 23 Feb 2009 04:08:06 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6537225poe.4 for ; Mon, 23 Feb 2009 04:08:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.29.11 with SMTP id g11mr2020215rvj.17.1235390903627; Mon, 23 Feb 2009 04:08:23 -0800 (PST) In-Reply-To: <49A29022.3070901@cox.net> References: <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> <49A1A22D.3080100@gmail.com> <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> <49A29022.3070901@cox.net> Date: Mon, 23 Feb 2009 12:08:23 +0000 Message-ID: <61dbdd7d0902230408o488353fbg67cabc797b938876@mail.gmail.com> From: Gareth Nelson To: lenglish5@cox.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 12:08:07 -0000 About the only relevance personal identity has is that people will get annoyed if it's altered too much when rendered elsewhere :) On Mon, Feb 23, 2009 at 12:01 PM, Lawson English wrote: > They're special because they encapsulate personal identity. One proposal > for the Agent Domain is to allow a separate scripting server to feed > commands to the simulator separately for avatar attachments, which would > allow avatars to "take it with them" as far as scripted appearance goes > (assuming the destination sim is compatible with the scripted attachments in > the first place) without violating copyright on non-Creative Commons > scripts. > > > L > > > Jesrad wrote: >> >> I tend to consider avatars as objects just like the others, except >> they are capable of a specific form of interaction that is similar >> (and should be identical) to vehicles. Given a uniform RPC avatars >> could be scripted objects indistinguishable from the rest of the VW >> environment. Compare this view with the existence of "bots" in SL, >> where a viewer is coded to run without user input, or the client-side >> scripts that grind your WoW character without supervision, or a few >> hundred other examples. >> >> That's why I see no reason to distinguish between the two categories >> at the level of the MMOX-layer. >> >> On Sun, Feb 22, 2009 at 8:09 PM, Gareth Nelson wrote: >> >>> >>> Well, we need a description of the avatar itself, or what do we show >>> to other systems? >>> Note I didn't mention rezzing an avatar :) >>> >>> On Sun, Feb 22, 2009 at 7:06 PM, Jon Watte wrote: >>> >>>> >>>> Gareth Nelson wrote: >>>> >>>>> >>>>> I propose HTTP for assets, with a standard base URL for each region >>>>> domain and agent domain, and a basic description of the avatar as >>>>> first step in defining the real "meat" of the 3D stuff. >>>>> >>>>> >>>> >>>> Why is an avatar special? >>>> >>>> In fact, I find the idea of putting "rezzing" avatars into OGP very >>>> second >>>> life centric. Bringing an avatar to life is a function internal to the >>>> virtual world service provider, not something that needs to, itself, be >>>> interoperable. The question is: how and when does that avatar get >>>> presented >>>> to other systems? >>>> >>>> Btw: what does "rezzing" stand for? "Ressurecting"? In general object >>>> parlance, I think "instantiating" would be better, perhaps. >>>> >>>> Sincerely, >>>> >>>> jw >>>> >>>> >>>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >>> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > > From lenglish5@cox.net Mon Feb 23 04:39:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C8603A6842 for ; Mon, 23 Feb 2009 04:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.81 X-Spam-Level: X-Spam-Status: No, score=0.81 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f-rAHMskqJ1 for ; Mon, 23 Feb 2009 04:39:11 -0800 (PST) Received: from fed1rmmtao102.cox.net (fed1rmmtao102.cox.net [68.230.241.44]) by core3.amsl.com (Postfix) with ESMTP id E1FD13A6874 for ; Mon, 23 Feb 2009 04:39:10 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao102.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090223123926.FALD13097.fed1rmmtao102.cox.net@fed1rmimpo02.cox.net>; Mon, 23 Feb 2009 07:39:26 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id KQfS1b0014N6T0Q04QfSaB; Mon, 23 Feb 2009 07:39:26 -0500 X-Authority-Analysis: v=1.0 c=1 a=cLXfh73VNe8A:10 a=PQp3fo3PBBsA:10 a=Wajolswj7cQA:10 a=kviXuzpPAAAA:8 a=JpVxa_F2IIOA4dSwamkA:9 a=8DLf9AV_VXvVP69xdCsA:7 a=JHX8jPomaWSw17glDI303NatLsoA:4 a=hpF-ijbX5cwA:10 a=4vB-4DCPJfMA:10 X-CM-Score: 0.00 Message-ID: <49A298FE.7050109@cox.net> Date: Mon, 23 Feb 2009 05:39:26 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Gareth Nelson References: <697430.23835.qm@web82605.mail.mud.yahoo.com> <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> <49A1A22D.3080100@gmail.com> <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> <49A29022.3070901@cox.net> <61dbdd7d0902230408o488353fbg67cabc797b938876@mail.gmail.com> In-Reply-To: <61dbdd7d0902230408o488353fbg67cabc797b938876@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 12:39:11 -0000 Which is why they might need to be treated differently. L Gareth Nelson wrote: > About the only relevance personal identity has is that people will get > annoyed if it's altered too much when rendered elsewhere :) > > > On Mon, Feb 23, 2009 at 12:01 PM, Lawson English wrote: > >> They're special because they encapsulate personal identity. One proposal >> for the Agent Domain is to allow a separate scripting server to feed >> commands to the simulator separately for avatar attachments, which would >> allow avatars to "take it with them" as far as scripted appearance goes >> (assuming the destination sim is compatible with the scripted attachments in >> the first place) without violating copyright on non-Creative Commons >> scripts. >> From gareth@litesim.com Mon Feb 23 04:43:47 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 273A33A6842 for ; Mon, 23 Feb 2009 04:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ElHjf56bD-Q for ; Mon, 23 Feb 2009 04:43:46 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.157]) by core3.amsl.com (Postfix) with ESMTP id 6D55D3A67F5 for ; Mon, 23 Feb 2009 04:43:46 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6561221poe.4 for ; Mon, 23 Feb 2009 04:44:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.53.4 with SMTP id f4mr2032349rvk.35.1235393043135; Mon, 23 Feb 2009 04:44:03 -0800 (PST) In-Reply-To: <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> Date: Mon, 23 Feb 2009 12:44:03 +0000 Message-ID: <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> From: Gareth Nelson To: Jesrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 12:43:47 -0000 Well, talking to a few others it seems the general consensus is "make a field on assets for all this stuff and make the scheme extensible". On Mon, Feb 23, 2009 at 10:27 AM, Jesrad wrote: > Hmm, "it's not gonna enforce IP technically" was not the point I > wanted to make. The actual point is: attempting to define a mechanism > for signalling what categories of actions are permitted or not under a > specific copyright law (which may or may not be applicable depending > on national/sovereign context) is a non-starter because of infinite > recursion. > > This is one of the main reasons I suggest curtaining the issue > entirely by adopting a multiple-host approach, where content (but not > necessarily the MMOX-layer object reference itself) remains hosted on > the originating grid and is not replicated between different grids > through the cross-grid protocol. The other reason for following such > an approach, is that it's the only one compatible with existing P2P > VWs like Solipsis. > > On Mon, Feb 23, 2009 at 11:21 AM, Gareth Nelson wrote: >> On Mon, Feb 23, 2009 at 10:10 AM, Jesrad wrote: >>>> Some people are going to insist on the DRM or not allow their content >>>> to be transferred at all >>> >>> And some people like me will insist that there is a way to do it that >>> cannot be prevented by third-party permissions system like this. >> >> But that's besides the point, since doing so isn't going to convince >> people to allow the content to move AND this system does not in fact >> prevent anything, it's a machine-readable version of the license - the >> only force comes from compliant systems and users or the courts. >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From jesrad@gmail.com Mon Feb 23 05:12:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EFED3A68AD for ; Mon, 23 Feb 2009 05:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Hl7F4x5wku8 for ; Mon, 23 Feb 2009 05:12:45 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 3771B3A6A05 for ; Mon, 23 Feb 2009 05:12:45 -0800 (PST) Received: by bwz5 with SMTP id 5so4713422bwz.13 for ; Mon, 23 Feb 2009 05:13:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LGniPwYN3518eZRkW5m45BujsW7EAA1phTkbhTfWNK4=; b=IQejsJv/BpfpzanEbtXxaebZimL+ArFEWjKCP3d/gGRQgpBLGL0+hBD+OFEcn0cbL0 N8P2f22l7HR1fS3MlKuW3KVcSVpcOEbpZzyufw9w6ucqQEzdTse+zmFlolQfA4o3mQ++ eU30h4D4cJmmoaBNdEZhWBJcQmt6OkOONax34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XZXektMRWhr9oIRflhNJTBFEev9OYnV4nMtuPaoRbekV9DFwbdI3vX5cGvx1AxyaBU D2ximHhWmveyTubf9fvyYthfwiosUl4Wr7rCDuuaJj1bp/+JFAE47/smWPIFYGTrocdD TYIFaL71ZG1wjVQTFG1wFRWo8WJe4saxi/ggw= MIME-Version: 1.0 Received: by 10.181.214.8 with SMTP id r8mr1512212bkq.206.1235394781105; Mon, 23 Feb 2009 05:13:01 -0800 (PST) In-Reply-To: <61dbdd7d0902230408o488353fbg67cabc797b938876@mail.gmail.com> References: <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> <49A1A22D.3080100@gmail.com> <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> <49A29022.3070901@cox.net> <61dbdd7d0902230408o488353fbg67cabc797b938876@mail.gmail.com> Date: Mon, 23 Feb 2009 14:13:00 +0100 Message-ID: <53cd6c2e0902230513t67368240kcf6a013b7faab18c@mail.gmail.com> From: Jesrad To: Gareth Nelson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:12:46 -0000 Actually, the capacity to encapsulate identity itself does not seem to mandate an entire different categorization, IMHO. Player/resident identity only requires to be tied to a specific inworld viewpoint and physical location, not a specific kind of objects, as is exemplified by all the vehicles/mounts in VWs, which take over those characteristics from the "avatar" object, dynamically. What I see is that an object may be made capable of holding those characteristics by being a vehicle (and in some cases, by also being capable of playing the default animations by having a standard skeleton). Just because some VWs restrict this dynamic capacity to a special class of objects in their implementation, does not mean all VWs should. MMOX protocol shouldn't be constrained by this sort of implementation decision. I think there's ground for a uniform access method here, seeing as how there are only so many user input diversity for avatar control across existing VWs. On Mon, Feb 23, 2009 at 1:08 PM, Gareth Nelson wrote: > About the only relevance personal identity has is that people will get > annoyed if it's altered too much when rendered elsewhere :) > > > On Mon, Feb 23, 2009 at 12:01 PM, Lawson English wrote: >> They're special because they encapsulate personal identity. One proposal >> for the Agent Domain is to allow a separate scripting server to feed >> commands to the simulator separately for avatar attachments, which would >> allow avatars to "take it with them" as far as scripted appearance goes >> (assuming the destination sim is compatible with the scripted attachments in >> the first place) without violating copyright on non-Creative Commons >> scripts. >> >> >> L >> >> >> Jesrad wrote: >>> >>> I tend to consider avatars as objects just like the others, except >>> they are capable of a specific form of interaction that is similar >>> (and should be identical) to vehicles. Given a uniform RPC avatars >>> could be scripted objects indistinguishable from the rest of the VW >>> environment. Compare this view with the existence of "bots" in SL, >>> where a viewer is coded to run without user input, or the client-side >>> scripts that grind your WoW character without supervision, or a few >>> hundred other examples. >>> >>> That's why I see no reason to distinguish between the two categories >>> at the level of the MMOX-layer. >>> >>> On Sun, Feb 22, 2009 at 8:09 PM, Gareth Nelson wrote: >>> >>>> >>>> Well, we need a description of the avatar itself, or what do we show >>>> to other systems? >>>> Note I didn't mention rezzing an avatar :) >>>> >>>> On Sun, Feb 22, 2009 at 7:06 PM, Jon Watte wrote: >>>> >>>>> >>>>> Gareth Nelson wrote: >>>>> >>>>>> >>>>>> I propose HTTP for assets, with a standard base URL for each region >>>>>> domain and agent domain, and a basic description of the avatar as >>>>>> first step in defining the real "meat" of the 3D stuff. >>>>>> >>>>>> >>>>> >>>>> Why is an avatar special? >>>>> >>>>> In fact, I find the idea of putting "rezzing" avatars into OGP very >>>>> second >>>>> life centric. Bringing an avatar to life is a function internal to the >>>>> virtual world service provider, not something that needs to, itself, be >>>>> interoperable. The question is: how and when does that avatar get >>>>> presented >>>>> to other systems? >>>>> >>>>> Btw: what does "rezzing" stand for? "Ressurecting"? In general object >>>>> parlance, I think "instantiating" would be better, perhaps. >>>>> >>>>> Sincerely, >>>>> >>>>> jw >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>>> >>>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >>> >> >> > From belxjander@gmail.com Mon Feb 23 05:23:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A26163A6ABE for ; Mon, 23 Feb 2009 05:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQNyUIaFKTlA for ; Mon, 23 Feb 2009 05:23:25 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 92AAC3A68C4 for ; Mon, 23 Feb 2009 05:23:25 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1811538rvb.49 for ; Mon, 23 Feb 2009 05:23:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=GaaBE4UIi3Nsjr4Ot8TpxoMJcPUl+5eyS7qKLi6oa2g=; b=W46lqqgClV26w22A9osnLSaZeFpUntzfOaLQPnAbMsrVi0Zz9g7FLZR7FIFXQ7ulio FYI++N8pFSw4XV9qgzEuTbxRm4wD6C4NyROjMicI9AhNJPSsoBZV44qUndJEgc+KsI3G hxd/8H+nR0dliG4VPikGfIJkMx4FZ28QdwLhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=wCcbVE18xxPIBgpC4qBVW+EPPA8mZh6jgG/lDwucfnHfxEMUbja9okAbXZJOFixaZd SG2TjxdDkLy+eTB30tbEuRVPqao34d4GdheC1GYiP3D0BgBm+6H5q1v72U6QT1ENippE NwZ+4z/mg7haB023iC24Yw6Too+N2fQ3Dl5i4= Received: by 10.141.162.5 with SMTP id p5mr2035979rvo.193.1235395422330; Mon, 23 Feb 2009 05:23:42 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id l31sm13657882rvb.5.2009.02.23.05.23.40 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 05:23:41 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <53cd6c2e0902230513t67368240kcf6a013b7faab18c@mail.gmail.com> References: <61dbdd7d0902220829r61a4212dm10ad85a192fa6ce7@mail.gmail.com> <193588.88005.qm@web82605.mail.mud.yahoo.com> <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> <49A1A22D.3080100@gmail.com> <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> <49A29022.3070901@cox.net> <61dbdd7d0902230408o488353fbg67cabc797b938876@mail.gmail.com> <53cd6c2e0902230513t67368240kcf6a013b7faab18c@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0b78wEAMF0epkIqxmQxb" Date: Mon, 23 Feb 2009 22:18:22 +0900 Message-Id: <1235395102.6608.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:23:26 -0000 --=-0b78wEAMF0epkIqxmQxb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Im inclined to agree with the "AV" itself not having any special case at all other than being a "focus" object selected by the user... My own "Virtual Worlds" vision would allow anything beyond the initial "viewpoint" to be an editable object that has "movement" emulation and triggers attached. that the GW client or SL client or client treats this as "special" because it is the 3D equivalent to a mouse point ? Give me a break, the only "special" property it has is being a "focus" object the same as the mouse you move for using Linux/Windows/Mac/...etc...all How is that special?, it is a focus, can you change the whole mouse image? yes can you animate it? again yes, does it respond to input? no, its a drawn item, which has its "location" data updated by user input. There is no need for anything "special" other than some means of updating an objects "motion" to allow simulation of changes... walking or other complex actions would need to be a set of update events. What is simpler than selecting an existing or making use of a "focus" object? Sincerely, Jeremy/Belxjander On Mon, 2009-02-23 at 14:13 +0100, Jesrad wrote: > Actually, the capacity to encapsulate identity itself does not seem to > mandate an entire different categorization, IMHO. Player/resident > identity only requires to be tied to a specific inworld viewpoint and > physical location, not a specific kind of objects, as is exemplified > by all the vehicles/mounts in VWs, which take over those > characteristics from the "avatar" object, dynamically. What I see is > that an object may be made capable of holding those characteristics by > being a vehicle (and in some cases, by also being capable of playing > the default animations by having a standard skeleton). Just because > some VWs restrict this dynamic capacity to a special class of objects > in their implementation, does not mean all VWs should. MMOX protocol > shouldn't be constrained by this sort of implementation decision. >=20 > I think there's ground for a uniform access method here, seeing as how > there are only so many user input diversity for avatar control across > existing VWs. >=20 > On Mon, Feb 23, 2009 at 1:08 PM, Gareth Nelson wrote= : > > About the only relevance personal identity has is that people will get > > annoyed if it's altered too much when rendered elsewhere :) > > > > > > On Mon, Feb 23, 2009 at 12:01 PM, Lawson English wr= ote: > >> They're special because they encapsulate personal identity. One propo= sal > >> for the Agent Domain is to allow a separate scripting server to feed > >> commands to the simulator separately for avatar attachments, which wou= ld > >> allow avatars to "take it with them" as far as scripted appearance goe= s > >> (assuming the destination sim is compatible with the scripted attachme= nts in > >> the first place) without violating copyright on non-Creative Commons > >> scripts. > >> > >> > >> L > >> > >> > >> Jesrad wrote: > >>> > >>> I tend to consider avatars as objects just like the others, except > >>> they are capable of a specific form of interaction that is similar > >>> (and should be identical) to vehicles. Given a uniform RPC avatars > >>> could be scripted objects indistinguishable from the rest of the VW > >>> environment. Compare this view with the existence of "bots" in SL, > >>> where a viewer is coded to run without user input, or the client-side > >>> scripts that grind your WoW character without supervision, or a few > >>> hundred other examples. > >>> > >>> That's why I see no reason to distinguish between the two categories > >>> at the level of the MMOX-layer. > >>> > >>> On Sun, Feb 22, 2009 at 8:09 PM, Gareth Nelson w= rote: > >>> > >>>> > >>>> Well, we need a description of the avatar itself, or what do we show > >>>> to other systems? > >>>> Note I didn't mention rezzing an avatar :) > >>>> > >>>> On Sun, Feb 22, 2009 at 7:06 PM, Jon Watte wrote: > >>>> > >>>>> > >>>>> Gareth Nelson wrote: > >>>>> > >>>>>> > >>>>>> I propose HTTP for assets, with a standard base URL for each regio= n > >>>>>> domain and agent domain, and a basic description of the avatar as > >>>>>> first step in defining the real "meat" of the 3D stuff. > >>>>>> > >>>>>> > >>>>> > >>>>> Why is an avatar special? > >>>>> > >>>>> In fact, I find the idea of putting "rezzing" avatars into OGP very > >>>>> second > >>>>> life centric. Bringing an avatar to life is a function internal to = the > >>>>> virtual world service provider, not something that needs to, itself= , be > >>>>> interoperable. The question is: how and when does that avatar get > >>>>> presented > >>>>> to other systems? > >>>>> > >>>>> Btw: what does "rezzing" stand for? "Ressurecting"? In general obje= ct > >>>>> parlance, I think "instantiating" would be better, perhaps. > >>>>> > >>>>> Sincerely, > >>>>> > >>>>> jw > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> mmox mailing list > >>>> mmox@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mmox > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> mmox mailing list > >>> mmox@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmox > >>> > >>> > >> > >> > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-0b78wEAMF0epkIqxmQxb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJoqIeAAoJECHrKutFYVwT43UQAJ5hBVfY3Ve9qEiiWg/uqzD7 Bi+mMmVam2C9XUWWw0l7JcQJfDeo8r5A5flihvHltHfX4DVyB5pCS8WzMJQnFeMN taafAsTjNB3KC1Ho2PvgreyUDfejegTHm9h+h5vDADQvL74jOaMfdhFKkk+gGAF5 /Ftxp9VOahevCE6PI6V+QTvEMFbDVj3UxRZjGXPSkgIwvFM2VnPEKlCLxlnLvISM sTf3Y0XtnpLcrQWPwU5T9kAnQfleY7dJg9/TN9JOxcQgAypL+RnjgyF2D7lkmico Dgt8b8UxaXCr567D6lwg5SR2WV0aqMX2FA9mJGA6sdMpz5W4XAzGDSouaHqbyZ+c YsjEgIAu45TE18K6FC72lZhL6CgKXW/6bKOLUriP2BGaVwoT8hVDSpXgAPC0WKFd 1gurfH+Eu7iLldu60P5Ka+ttDtm5z7Pm7dt76wouZM6i4Elcpe4hkhyQVkt9gpW5 fp8dua2npcm/bGyCH7dKGiRu20pYfOzywCBo2EGH0PVZe7LoUm0bAaNT0RoedE7G X0373UnymATeZzGU0Si90TAcN6D1mA4G8DQjlCkPMiWNMaNKclEREHFo0phBhs80 kDljAK1THS32PA8QM5jkbes641FAJy5A3tOanKc3yc/y/Utk72gI4IWrhtHjY1aj qwlx/nsOAxVaLClIr7HW =kuuB -----END PGP SIGNATURE----- --=-0b78wEAMF0epkIqxmQxb-- From jesrad@gmail.com Mon Feb 23 05:33:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E6A3A68E7 for ; Mon, 23 Feb 2009 05:33:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDvx0WndC6Y5 for ; Mon, 23 Feb 2009 05:33:01 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 07F143A6864 for ; Mon, 23 Feb 2009 05:32:08 -0800 (PST) Received: by bwz5 with SMTP id 5so4731960bwz.13 for ; Mon, 23 Feb 2009 05:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Oe6xQCfYrhIAaX1pF0p870FDdlLNwyn3Ok/oM3MN+Ok=; b=O8Sd/PHBuPvhDRbjXV/yyv2AWdAo21RWjWxvmD6wqZZ/TExXf1buZIe13oMtvuAyid cQDllhg/p7E2TOzIJc2WXL88NUJch2WFxFAsq2/CJM9ZXiFUXnekKRHWJPxo/G+nvKX3 wQNqIBzSQh0U+O2xGKFU3dFPOKL7Fjvx14nIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AknnPM9KLecxexTe2hNxY2o+3BfAoonkA4RPTJ2yTOfGldnHLvzVF1khEmMHuW3Lga msttouagGoszyaC0fqvu1mp2xpjtfVHl3g7dwr0rGD2sm6V6QDlpF4uHKoB3eNAwQjt6 48TOTjTXpJUCI6OX9zeYEr1XXv4T8sRfxul8Q= MIME-Version: 1.0 Received: by 10.181.209.1 with SMTP id l1mr1528138bkq.113.1235395944709; Mon, 23 Feb 2009 05:32:24 -0800 (PST) In-Reply-To: <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> Date: Mon, 23 Feb 2009 14:32:24 +0100 Message-ID: <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> From: Jesrad To: Gareth Nelson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:33:02 -0000 OK, but doesn't that just make this "stuff" a form of content, or at most metadata ? In this case, it might fall off scope anyway. Even if it is recognized by consensus as a valid form of data to be exchanged between grids, which is reasonable when presented in this way, the twin problems of relevance WRT the domestic legal context and of relevance WRT the actual implementation of any DRM in the target grid make this sort of data irrelevant when it can be entirely superseded by any other form of user content associated to the object (like, say, a CC license notecard as in SL, or a simple copyright notice). To put it differently: if we do not mandate any implementation of DRM per protocol specifications, then this sort of data is purely "client-side" and is better left to the resident/player-creator to make and include in the concerned object. And if we do mandate DRM implementation, then this implementation ifalls short of the diversity of legal contexts (for example fair-use cases, which vary widely between jurisdictions), breaks some models (like mine), and reduces greatly the possibility of interoperability with a number of existing VWs like the OpenGrid or (AFAIK) Solipsis. If you insist that there is space for this sort of metadata and the protocol does not mandate DRM implementation for the server-side to enforce, then I can live with it. But I'll still think it a waste of resources. ...well, maybe it can be later hijacked for a better end user-worthy purpose, I guess. On Mon, Feb 23, 2009 at 1:44 PM, Gareth Nelson wrote: > Well, talking to a few others it seems the general consensus is "make > a field on assets for all this stuff and make the scheme extensible". > > On Mon, Feb 23, 2009 at 10:27 AM, Jesrad wrote: >> Hmm, "it's not gonna enforce IP technically" was not the point I >> wanted to make. The actual point is: attempting to define a mechanism >> for signalling what categories of actions are permitted or not under a >> specific copyright law (which may or may not be applicable depending >> on national/sovereign context) is a non-starter because of infinite >> recursion. >> >> This is one of the main reasons I suggest curtaining the issue >> entirely by adopting a multiple-host approach, where content (but not >> necessarily the MMOX-layer object reference itself) remains hosted on >> the originating grid and is not replicated between different grids >> through the cross-grid protocol. The other reason for following such >> an approach, is that it's the only one compatible with existing P2P >> VWs like Solipsis. >> >> On Mon, Feb 23, 2009 at 11:21 AM, Gareth Nelson wrote: >>> On Mon, Feb 23, 2009 at 10:10 AM, Jesrad wrote: >>>>> Some people are going to insist on the DRM or not allow their content >>>>> to be transferred at all >>>> >>>> And some people like me will insist that there is a way to do it that >>>> cannot be prevented by third-party permissions system like this. >>> >>> But that's besides the point, since doing so isn't going to convince >>> people to allow the content to move AND this system does not in fact >>> prevent anything, it's a machine-readable version of the license - the >>> only force comes from compliant systems and users or the courts. >>> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > From gareth@litesim.com Mon Feb 23 05:37:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204183A6861 for ; Mon, 23 Feb 2009 05:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQYdzSBQ5lN4 for ; Mon, 23 Feb 2009 05:37:31 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.158]) by core3.amsl.com (Postfix) with ESMTP id 3C5B63A6838 for ; Mon, 23 Feb 2009 05:37:31 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6597674poe.4 for ; Mon, 23 Feb 2009 05:37:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.85.13 with SMTP id n13mr2048111rvl.69.1235396267985; Mon, 23 Feb 2009 05:37:47 -0800 (PST) In-Reply-To: <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> Date: Mon, 23 Feb 2009 13:37:47 +0000 Message-ID: <61dbdd7d0902230537n20f86856i8b392a80b1740bc0@mail.gmail.com> From: Gareth Nelson To: Jesrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:37:32 -0000 Well, the "stuff" was generally recogonised by others as being much more complex than my naive ideas on the subject would make it appear for multiple reasons which i'll point you at today's mmox@jabber.ietf.org logs for. I would be quite opposed to actually *mandating* any implementation of DRM, as i've said multiple times the idea is to let automated systems know what is allowed - it's up to the implementers of those systems whether they obey the license restrictions or not. The problem i'm trying to solve here is one where you need to manually ask the copyright holder every time you want to move their work to another grid. Making it machine-readable makes it possible to automate things, while a human-readable license does not. On Mon, Feb 23, 2009 at 1:32 PM, Jesrad wrote: > OK, but doesn't that just make this "stuff" a form of content, or at > most metadata ? In this case, it might fall off scope anyway. > > Even if it is recognized by consensus as a valid form of data to be > exchanged between grids, which is reasonable when presented in this > way, the twin problems of relevance WRT the domestic legal context and > of relevance WRT the actual implementation of any DRM in the target > grid make this sort of data irrelevant when it can be entirely > superseded by any other form of user content associated to the object > (like, say, a CC license notecard as in SL, or a simple copyright > notice). > > To put it differently: if we do not mandate any implementation of DRM > per protocol specifications, then this sort of data is purely > "client-side" and is better left to the resident/player-creator to > make and include in the concerned object. And if we do mandate DRM > implementation, then this implementation ifalls short of the diversity > of legal contexts (for example fair-use cases, which vary widely > between jurisdictions), breaks some models (like mine), and reduces > greatly the possibility of interoperability with a number of existing > VWs like the OpenGrid or (AFAIK) Solipsis. > > If you insist that there is space for this sort of metadata and the > protocol does not mandate DRM implementation for the server-side to > enforce, then I can live with it. But I'll still think it a waste of > resources. > > ...well, maybe it can be later hijacked for a better end user-worthy > purpose, I guess. > > On Mon, Feb 23, 2009 at 1:44 PM, Gareth Nelson wrote: >> Well, talking to a few others it seems the general consensus is "make >> a field on assets for all this stuff and make the scheme extensible". >> >> On Mon, Feb 23, 2009 at 10:27 AM, Jesrad wrote: >>> Hmm, "it's not gonna enforce IP technically" was not the point I >>> wanted to make. The actual point is: attempting to define a mechanism >>> for signalling what categories of actions are permitted or not under a >>> specific copyright law (which may or may not be applicable depending >>> on national/sovereign context) is a non-starter because of infinite >>> recursion. >>> >>> This is one of the main reasons I suggest curtaining the issue >>> entirely by adopting a multiple-host approach, where content (but not >>> necessarily the MMOX-layer object reference itself) remains hosted on >>> the originating grid and is not replicated between different grids >>> through the cross-grid protocol. The other reason for following such >>> an approach, is that it's the only one compatible with existing P2P >>> VWs like Solipsis. >>> >>> On Mon, Feb 23, 2009 at 11:21 AM, Gareth Nelson wrote: >>>> On Mon, Feb 23, 2009 at 10:10 AM, Jesrad wrote: >>>>>> Some people are going to insist on the DRM or not allow their content >>>>>> to be transferred at all >>>>> >>>>> And some people like me will insist that there is a way to do it that >>>>> cannot be prevented by third-party permissions system like this. >>>> >>>> But that's besides the point, since doing so isn't going to convince >>>> people to allow the content to move AND this system does not in fact >>>> prevent anything, it's a machine-readable version of the license - the >>>> only force comes from compliant systems and users or the courts. >>>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >> > From jesrad@gmail.com Mon Feb 23 05:43:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 623EB3A67F5 for ; Mon, 23 Feb 2009 05:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtoCfBUAKwrS for ; Mon, 23 Feb 2009 05:43:11 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id A5B373A68BF for ; Mon, 23 Feb 2009 05:43:10 -0800 (PST) Received: by bwz5 with SMTP id 5so4742688bwz.13 for ; Mon, 23 Feb 2009 05:43:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6RBW5wjctJt5U8j0ZTde6c71ay/9SyIHvaieiOY5zsY=; b=tq5JACBKK6gOlRPzzY9R7drwpfz+cjBpPwRVi7DUPvozwFlIK7Vdm8x5J3kmdOrD+e 2+8j+QNPercyXUM1gCcEqoUI6vhZxAj23lUMBusNbRmI489LQoWpYNFAKM183snrvKl1 yzKols8mlPFiF+11UUHsGxuTLmrEIoRTJNLKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ecb/DYNSeeFXwcVHHJEeMftU0Aof1Yb7XsHXMHKWlUJuegS+TQD04g90wfY9+0CqhH mQGKJCsy54q2ET/q+gKOqAGaBqI+KQiH7rvh/3xn1EFcLvu1POHL1W7ZCBkhB1z3pQPL g1YHxsc7iHl50v0zxILeGOGqAGClFLGloa8+o= MIME-Version: 1.0 Received: by 10.181.145.7 with SMTP id x7mr1523637bkn.177.1235396602885; Mon, 23 Feb 2009 05:43:22 -0800 (PST) In-Reply-To: <1235395102.6608.6.camel@localhost> References: <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> <49A1A22D.3080100@gmail.com> <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> <49A29022.3070901@cox.net> <61dbdd7d0902230408o488353fbg67cabc797b938876@mail.gmail.com> <53cd6c2e0902230513t67368240kcf6a013b7faab18c@mail.gmail.com> <1235395102.6608.6.camel@localhost> Date: Mon, 23 Feb 2009 14:43:22 +0100 Message-ID: <53cd6c2e0902230543p3659f56dt57f4fd3516865cbd@mail.gmail.com> From: Jesrad To: Kajikawa Jeremy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] I hate to be a kill joy here and, put the horse before the cart X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:43:12 -0000 > My own "Virtual Worlds" vision would allow anything beyond the initial > "viewpoint" > to be an editable object that has "movement" emulation and triggers > attached. I have the same reason to suggest this... which makes it a case where being knowledgeable of "The Second Life Way" pushes people to NOT bless it into a standard ;) > There is no need for anything "special" other than some means of updating an objects > "motion" to allow simulation of changes... walking or other complex actions would > need to be a set of update events. Well, I can think of one thing special with this focus, it's that it determines the visibility volume for the client/endpoint, and therefore determines a number of things like the breadth of content it has to fetch in order to build the renderview. But this is probably better tuck into the Agent domain than built into a special kind of object class. On Mon, Feb 23, 2009 at 2:18 PM, Kajikawa Jeremy wrote: > Im inclined to agree with the "AV" itself not having any special case at > all > other than being a "focus" object selected by the user... > > My own "Virtual Worlds" vision would allow anything beyond the initial > "viewpoint" > to be an editable object that has "movement" emulation and triggers > attached. > > that the GW client or SL client or client treats this as > "special" > because it is the 3D equivalent to a mouse point ? > > Give me a break, the only "special" property it has is being a "focus" > object > the same as the mouse you move for using > Linux/Windows/Mac/...etc...all > > How is that special?, it is a focus, can you change the whole mouse > image? yes > can you animate it? again yes, does it respond to input? no, its a > drawn item, > which has its "location" data updated by user input. > > There is no need for anything "special" other than some means of > updating an > objects "motion" to allow simulation of changes... walking or other > complex > actions would need to be a set of update events. > > What is simpler than selecting an existing or making use of a "focus" > object? > > Sincerely, > Jeremy/Belxjander > > On Mon, 2009-02-23 at 14:13 +0100, Jesrad wrote: >> Actually, the capacity to encapsulate identity itself does not seem to >> mandate an entire different categorization, IMHO. Player/resident >> identity only requires to be tied to a specific inworld viewpoint and >> physical location, not a specific kind of objects, as is exemplified >> by all the vehicles/mounts in VWs, which take over those >> characteristics from the "avatar" object, dynamically. What I see is >> that an object may be made capable of holding those characteristics by >> being a vehicle (and in some cases, by also being capable of playing >> the default animations by having a standard skeleton). Just because >> some VWs restrict this dynamic capacity to a special class of objects >> in their implementation, does not mean all VWs should. MMOX protocol >> shouldn't be constrained by this sort of implementation decision. >> >> I think there's ground for a uniform access method here, seeing as how >> there are only so many user input diversity for avatar control across >> existing VWs. >> >> On Mon, Feb 23, 2009 at 1:08 PM, Gareth Nelson wrote: >> > About the only relevance personal identity has is that people will get >> > annoyed if it's altered too much when rendered elsewhere :) >> > >> > >> > On Mon, Feb 23, 2009 at 12:01 PM, Lawson English wrote: >> >> They're special because they encapsulate personal identity. One proposal >> >> for the Agent Domain is to allow a separate scripting server to feed >> >> commands to the simulator separately for avatar attachments, which would >> >> allow avatars to "take it with them" as far as scripted appearance goes >> >> (assuming the destination sim is compatible with the scripted attachments in >> >> the first place) without violating copyright on non-Creative Commons >> >> scripts. >> >> >> >> >> >> L >> >> >> >> >> >> Jesrad wrote: >> >>> >> >>> I tend to consider avatars as objects just like the others, except >> >>> they are capable of a specific form of interaction that is similar >> >>> (and should be identical) to vehicles. Given a uniform RPC avatars >> >>> could be scripted objects indistinguishable from the rest of the VW >> >>> environment. Compare this view with the existence of "bots" in SL, >> >>> where a viewer is coded to run without user input, or the client-side >> >>> scripts that grind your WoW character without supervision, or a few >> >>> hundred other examples. >> >>> >> >>> That's why I see no reason to distinguish between the two categories >> >>> at the level of the MMOX-layer. >> >>> >> >>> On Sun, Feb 22, 2009 at 8:09 PM, Gareth Nelson wrote: >> >>> >> >>>> >> >>>> Well, we need a description of the avatar itself, or what do we show >> >>>> to other systems? >> >>>> Note I didn't mention rezzing an avatar :) >> >>>> >> >>>> On Sun, Feb 22, 2009 at 7:06 PM, Jon Watte wrote: >> >>>> >> >>>>> >> >>>>> Gareth Nelson wrote: >> >>>>> >> >>>>>> >> >>>>>> I propose HTTP for assets, with a standard base URL for each region >> >>>>>> domain and agent domain, and a basic description of the avatar as >> >>>>>> first step in defining the real "meat" of the 3D stuff. >> >>>>>> >> >>>>>> >> >>>>> >> >>>>> Why is an avatar special? >> >>>>> >> >>>>> In fact, I find the idea of putting "rezzing" avatars into OGP very >> >>>>> second >> >>>>> life centric. Bringing an avatar to life is a function internal to the >> >>>>> virtual world service provider, not something that needs to, itself, be >> >>>>> interoperable. The question is: how and when does that avatar get >> >>>>> presented >> >>>>> to other systems? >> >>>>> >> >>>>> Btw: what does "rezzing" stand for? "Ressurecting"? In general object >> >>>>> parlance, I think "instantiating" would be better, perhaps. >> >>>>> >> >>>>> Sincerely, >> >>>>> >> >>>>> jw >> >>>>> >> >>>>> >> >>>>> >> >>>> >> >>>> _______________________________________________ >> >>>> mmox mailing list >> >>>> mmox@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/mmox >> >>>> >> >>>> >> >>> >> >>> _______________________________________________ >> >>> mmox mailing list >> >>> mmox@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/mmox >> >>> >> >>> >> >> >> >> >> > >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > From dyerbrookme@juno.com Mon Feb 23 05:45:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87DB23A68F4 for ; Mon, 23 Feb 2009 05:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgkyxplTRvQD for ; Mon, 23 Feb 2009 05:45:04 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 993B13A67F5 for ; Mon, 23 Feb 2009 05:45:04 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail09.vgs.untd.com [10.181.12.149]) by smtpout02.vgs.untd.com with SMTP id AABE4FLDNAKR5JTA for (sender ); Mon, 23 Feb 2009 05:45:16 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNBVRNT6FMVtOWfDIfPS61uQ== Received: (from dyerbrookme@juno.com) by webmail09.vgs.untd.com (jqueuemail) id N94C6XM6; Mon, 23 Feb 2009 05:45:08 PST Received: from [68.161.198.3] by webmail09.vgs.untd.com with HTTP: Mon, 23 Feb 2009 13:44:54 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 13:44:54 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090223.084454.24252.0@webmail09.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 10:5:2505509007 X-UNTD-Peer-Info: 10.181.12.149|webmail09.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:45:05 -0000 >Even if it is recognized by consensus as a valid form of data to be exchanged between grids, which is reasonable when presented in this way, the twin problems of relevance WRT the domestic legal context and of relevance WRT the actual implementation of any DRM in the target grid make this sort of data irrelevant when it can be entirely superseded by any other form of user content associated to the object (like, say, a CC license notecard as in SL, or a simple copyright notice). Extraordinary reluctance to transmit information given the usual value o= f opensource to want information to be free and to move unhindered acros= s frontiers! Putting a CC license notecard *is not sufficient*. CC is not an economy = and not commerce; it's a browbeating to give your content away for free = in exchange for name credit only. It is not the foundation for a micropa= yments scheme. Notecards can also get lost or removed. = If the permissions information is transmitted, and the TOS of the sendin= g platform includes within the concept of trustworthiness that such perm= issions information must be implemented, then you have a very good ready= -made regime for proving trustworthiness. >To put it differently: if we do not mandate any implementation of DRM per protocol specifications, then this sort of data is purely "client-side" and is better left to the resident/player-creator to make and include in the concerned object. And if we do mandate DRM implementation, then this implementation ifalls short of the diversity of legal contexts (for example fair-use cases, which vary widely between jurisdictions), breaks some models (like mine), and reduces greatly the possibility of interoperability with a number of existing VWs like the OpenGrid or (AFAIK) Solipsis. Transmitting metadata about permissions doesn't "fall short" of diversit= y. It creates the bedrock of diversity for an economy that is based on c= apitalist commerce and not only on collectivist "sharing" and *that* is = what enables diversity. I'm glad to hear you confirm, however, what others in OpenSim keep denyi= ng, mainly that to transmit metadata about permissions in fact "reduces = greatly the possibility of interoperability with OpenGrid. Now why is th= at? Interoperability should give choices of systems, not take them away.= "Fair use" might need some updating or contextual examination and should= n't be invoked casually merely to defeat commerce. In a virtual world, j= ust because the platform providers already stream all the content, you a= lready have your fair use, and so does everybody else who would like to = see an object "for reference"! If you buy a skin or table, it renders fo= r you -- what more "fair use" would you need when the entire thing rende= rs for you always and everywhere, in your copy? If you've rezzed it out = or are wearing it, everybody sees the full copy already lol. No, invocat= ion of "fair use" here, as if stopping copyright theft in a VW would hob= ble fair use seems out of place and out of date. >If you insist that there is space for this sort of metadata and the protocol does not mandate DRM implementation for the server-side to enforce, then I can live with it. But I'll still think it a waste of resources. Well, why can't it mandate DRM implementation as a condition of trustwor= thiness? And...why does the mere passage of information "waste resources= "? Tons of data is transmitted, what, you can't spare a few bytes for c/= m/t? ____________________________________________________________ Click for online loan, fast & no lender fee, approval today http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIpd4J1s4V5InglOtuqIfd= BHGtUTsTbf6ji5kG7PYZqO10VzCMgHu/ From jesrad@gmail.com Mon Feb 23 05:58:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335C928C0FA for ; Mon, 23 Feb 2009 05:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCy3q+MJLSym for ; Mon, 23 Feb 2009 05:58:57 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 9A13F3A6968 for ; Mon, 23 Feb 2009 05:58:56 -0800 (PST) Received: by bwz5 with SMTP id 5so4757876bwz.13 for ; Mon, 23 Feb 2009 05:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nIPsqEiMgouXCNdv9bVRkgw9KBbanNLHQrbi7DQwr0Y=; b=OAdoW5+JkFbSCsrQcA32NAzOIPsgQBnMeYpK4TvMiuxQ18lWHlCYPQMwqbw1bKRnNy IHvDqGtGa/oSF4DLgm1lmibR+nNElI2OXjtAX0Q/8qVQ0mmSxzBcI87DikE1SQdkTJuZ mXdymri13visJjFw96rQF7vlM0/Fjj5Jgo6bc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=WoY0oVbJkr4DFJnOzTz4NNMHv5NtAPcYj3P5Bm1MxCUCZ88SQIWABzYO5T1oxquFHv 2vmtC3ii8d8NwmKknyUgpgNNfRuvQkaAouZp980+C/vYqZoWqSFDtsC6FRfQUbATOYRI Mds1TgbInunrUHqvjCnaL70uXGHKPB4jURouA= MIME-Version: 1.0 Received: by 10.181.205.3 with SMTP id h3mr1535551bkq.91.1235397553188; Mon, 23 Feb 2009 05:59:13 -0800 (PST) In-Reply-To: <61dbdd7d0902230537n20f86856i8b392a80b1740bc0@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> <61dbdd7d0902230537n20f86856i8b392a80b1740bc0@mail.gmail.com> Date: Mon, 23 Feb 2009 14:59:13 +0100 Message-ID: <53cd6c2e0902230559g73aa66e3u4026f34b95ec215@mail.gmail.com> From: Jesrad To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 13:58:58 -0000 This amounts to an implementation of some DRM, if I understand it correctly. Would it be part of the protocol that grids are to machine-read it and enforce it ? I would guess so if there is also a section of the protocol addressing asset exchange. In this case the problem is still more complex than anticipated (how do I restrict next owner or next grid from restricting next owner or grid from grid-exchanging the asset, etc.) Nevertheless, the entire issue is avoided by keeping content hosted in its original grid, and the renderview being supplied by multiple sources (according to the endpoint identity's credentials, if required by the source grid implementation). Isn't it ? On Mon, Feb 23, 2009 at 2:37 PM, Gareth Nelson wrote: > Well, the "stuff" was generally recogonised by others as being much > more complex than my naive ideas on the subject would make it appear > for multiple reasons which i'll point you at today's > mmox@jabber.ietf.org logs for. > I would be quite opposed to actually *mandating* any implementation of > DRM, as i've said multiple times the idea is to let automated systems > know what is allowed - it's up to the implementers of those systems > whether they obey the license restrictions or not. > The problem i'm trying to solve here is one where you need to manually > ask the copyright holder every time you want to move their work to > another grid. Making it machine-readable makes it possible to automate > things, while a human-readable license does not. > > On Mon, Feb 23, 2009 at 1:32 PM, Jesrad wrote: >> OK, but doesn't that just make this "stuff" a form of content, or at >> most metadata ? In this case, it might fall off scope anyway. >> >> Even if it is recognized by consensus as a valid form of data to be >> exchanged between grids, which is reasonable when presented in this >> way, the twin problems of relevance WRT the domestic legal context and >> of relevance WRT the actual implementation of any DRM in the target >> grid make this sort of data irrelevant when it can be entirely >> superseded by any other form of user content associated to the object >> (like, say, a CC license notecard as in SL, or a simple copyright >> notice). >> >> To put it differently: if we do not mandate any implementation of DRM >> per protocol specifications, then this sort of data is purely >> "client-side" and is better left to the resident/player-creator to >> make and include in the concerned object. And if we do mandate DRM >> implementation, then this implementation ifalls short of the diversity >> of legal contexts (for example fair-use cases, which vary widely >> between jurisdictions), breaks some models (like mine), and reduces >> greatly the possibility of interoperability with a number of existing >> VWs like the OpenGrid or (AFAIK) Solipsis. >> >> If you insist that there is space for this sort of metadata and the >> protocol does not mandate DRM implementation for the server-side to >> enforce, then I can live with it. But I'll still think it a waste of >> resources. >> >> ...well, maybe it can be later hijacked for a better end user-worthy >> purpose, I guess. >> >> On Mon, Feb 23, 2009 at 1:44 PM, Gareth Nelson wrote: >>> Well, talking to a few others it seems the general consensus is "make >>> a field on assets for all this stuff and make the scheme extensible". >>> >>> On Mon, Feb 23, 2009 at 10:27 AM, Jesrad wrote: >>>> Hmm, "it's not gonna enforce IP technically" was not the point I >>>> wanted to make. The actual point is: attempting to define a mechanism >>>> for signalling what categories of actions are permitted or not under a >>>> specific copyright law (which may or may not be applicable depending >>>> on national/sovereign context) is a non-starter because of infinite >>>> recursion. >>>> >>>> This is one of the main reasons I suggest curtaining the issue >>>> entirely by adopting a multiple-host approach, where content (but not >>>> necessarily the MMOX-layer object reference itself) remains hosted on >>>> the originating grid and is not replicated between different grids >>>> through the cross-grid protocol. The other reason for following such >>>> an approach, is that it's the only one compatible with existing P2P >>>> VWs like Solipsis. >>>> >>>> On Mon, Feb 23, 2009 at 11:21 AM, Gareth Nelson wrote: >>>>> On Mon, Feb 23, 2009 at 10:10 AM, Jesrad wrote: >>>>>>> Some people are going to insist on the DRM or not allow their content >>>>>>> to be transferred at all >>>>>> >>>>>> And some people like me will insist that there is a way to do it that >>>>>> cannot be prevented by third-party permissions system like this. >>>>> >>>>> But that's besides the point, since doing so isn't going to convince >>>>> people to allow the content to move AND this system does not in fact >>>>> prevent anything, it's a machine-readable version of the license - the >>>>> only force comes from compliant systems and users or the courts. >>>>> >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>>> >>> >> > From jesrad@gmail.com Mon Feb 23 06:12:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89F53A684D for ; Mon, 23 Feb 2009 06:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkCo4XthEL1a for ; Mon, 23 Feb 2009 06:12:53 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id CECCE3A67EC for ; Mon, 23 Feb 2009 06:12:52 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so1498170fkf.5 for ; Mon, 23 Feb 2009 06:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/JVeafez99ekzCqiR4bqOoRcNXRx2l4ytv1VckiN+mE=; b=ZCWxlLhrZyoNQQ6j1u0Fm7dO0fdK8hCnQoAmKYA2xTPPvrHxmGjiiUPOZ33fg/D/wV 2DlU0ZRXPf7kTRjDKY2fUn5/ciRRqwbqqwpAHCVgsAecOMvJoDdZYX6WLDyXJhYEFlVA W7nrpobfhLzzA3rY3FHG65BKTbcqLKlkdxfz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YJY/R+uzAC4wnPLyiC4Q1Uai7wXi/XSwLS/tj1tK/rCOkxRvQ2RkM32VMLnW8gx00z vLD8h90JBiPXrzIKnUMci/B0WgM/7Cgx9T57VGr/WDMmBqYieBXz1ToUbWElxxN00L2F LB77lI1m+yeRtWnY1Q+ndUgprKtvpuURkh4wk= MIME-Version: 1.0 Received: by 10.181.58.9 with SMTP id l9mr1531961bkk.214.1235398389097; Mon, 23 Feb 2009 06:13:09 -0800 (PST) In-Reply-To: <20090223.084454.24252.0@webmail09.vgs.untd.com> References: <20090223.084454.24252.0@webmail09.vgs.untd.com> Date: Mon, 23 Feb 2009 15:13:09 +0100 Message-ID: <53cd6c2e0902230613y6e86f16fyaa841a08db4b86d1@mail.gmail.com> From: Jesrad To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 14:12:58 -0000 Trustworthiness of a given grid is better left to the full appreciation of the grid caretaker because there is no way to make an automatic validation of the DRM implementation in some distant machine (but that's really the most basic reason of all), so the entire debate about what constitutes a trusted grid or not WRT copyright is out of scope. > I'm glad to hear you confirm, however, what others in OpenSim keep denyin= g, mainly that to transmit metadata about permissions in fact "reduces grea= tly the possibility of interoperability with OpenGrid. This is not what I wrote. I actually wrote that mandating the implementation of DRM on top of any permission/copyright metadata transmission mechanism would severly reduce the number of grid systems that comply with the protocol. > CC is not an economy and not commerce; it's a browbeating to give your co= ntent away for free in exchange for name credit only. It is not the foundat= ion for a micropayments scheme. I earn significant money from making full-perm content in Second Life, so these assertions sound empty to me. I'm also a fiercely individualistic capitalist (of the jusnaturalist kind), but you do not have to believe me. On Mon, Feb 23, 2009 at 2:44 PM, dyerbrookme@juno.com wrote: >>Even if it is recognized by consensus as a valid form of data to be > exchanged between grids, which is reasonable when presented in this > way, the twin problems of relevance WRT the domestic legal context and > of relevance WRT the actual implementation of any DRM in the target > grid make this sort of data irrelevant when it can be entirely > superseded by any other form of user content associated to the object > (like, say, a CC license notecard as in SL, or a simple copyright > notice). > > Extraordinary reluctance to transmit information given the usual value of= opensource to want information to be free and to move unhindered across fr= ontiers! > > Putting a CC license notecard *is not sufficient*. CC is not an economy a= nd not commerce; it's a browbeating to give your content away for free in e= xchange for name credit only. It is not the foundation for a micropayments = scheme. Notecards can also get lost or removed. > > If the permissions information is transmitted, and the TOS of the sending= platform includes within the concept of trustworthiness that such permissi= ons information must be implemented, then you have a very good ready-made r= egime for proving trustworthiness. > >>To put it differently: if we do not mandate any implementation of DRM > per protocol specifications, then this sort of data is purely > "client-side" and is better left to the resident/player-creator to > make and include in the concerned object. And if we do mandate DRM > implementation, then this implementation ifalls short of the diversity > of legal contexts (for example fair-use cases, which vary widely > between jurisdictions), breaks some models (like mine), and reduces > greatly the possibility of interoperability with a number of existing > VWs like the OpenGrid or (AFAIK) Solipsis. > > Transmitting metadata about permissions doesn't "fall short" of diversity= . It creates the bedrock of diversity for an economy that is based on capit= alist commerce and not only on collectivist "sharing" and *that* is what en= ables diversity. > > I'm glad to hear you confirm, however, what others in OpenSim keep denyin= g, mainly that to transmit metadata about permissions in fact "reduces grea= tly the possibility of interoperability with OpenGrid. Now why is that? Int= eroperability should give choices of systems, not take them away. > > "Fair use" might need some updating or contextual examination and shouldn= 't be invoked casually merely to defeat commerce. In a virtual world, just = because the platform providers already stream all the content, you already = have your fair use, and so does everybody else who would like to see an obj= ect "for reference"! If you buy a skin or table, it renders for you -- what= more "fair use" would you need when the entire thing renders for you alway= s and everywhere, in your copy? If you've rezzed it out or are wearing it, = everybody sees the full copy already lol. No, invocation of "fair use" here= , as if stopping copyright theft in a VW would hobble fair use seems out of= place and out of date. > >>If you insist that there is space for this sort of metadata and the > protocol does not mandate DRM implementation for the server-side to > enforce, then I can live with it. But I'll still think it a waste of > resources. > > Well, why can't it mandate DRM implementation as a condition of trustwort= hiness? And...why does the mere passage of information "waste resources"? T= ons of data is transmitted, what, you can't spare a few bytes for c/m/t? > > ____________________________________________________________ > Click for online loan, fast & no lender fee, approval today > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIpd4J1s4V5InglOtuqIfdB= HGtUTsTbf6ji5kG7PYZqO10VzCMgHu/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From belxjander@gmail.com Mon Feb 23 06:13:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025BA3A68F4 for ; Mon, 23 Feb 2009 06:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UKsgDl5F5Tq for ; Mon, 23 Feb 2009 06:13:18 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 3384B3A67EC for ; Mon, 23 Feb 2009 06:13:18 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1826354rvb.49 for ; Mon, 23 Feb 2009 06:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=RGiKeOKk0PHkQ2WWetwkkKpE44s9ZDvSXdfV6Qew1kQ=; b=SMHKzcRUlVwffP31i5Uew0lN8ohCLz5hGaGACxXNuIYlOQGezTbHPrITkaFQGSAlOF 17COrMXbD3BPEIx6R3/78mTUoocZI5JWTcET9XssUnzPIkWvvj2A34wy/HcavlgoY1Gp dbzvIsqNvc429+zTSKISnw9+LrIoiTii6rjKo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=sRLROq6stK2jCbWVf7aqmf17kPsoz4YzURxTMyjIYoG85XtF4/N3ngnsDq1Y/NK/L5 9zEchTbfIMMhHwvzkojz0/y5d0H2j/KcK4tktHpaUqvUbJRjBtOO0UlSv30mGFhdUbKv dq+bOX9gERsFGA5bF2Lan0GmP9ZeAqEU92O/Y= Received: by 10.141.122.1 with SMTP id z1mr2066573rvm.49.1235398415112; Mon, 23 Feb 2009 06:13:35 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g31sm13765465rvb.7.2009.02.23.06.13.33 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 06:13:34 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <53cd6c2e0902230543p3659f56dt57f4fd3516865cbd@mail.gmail.com> References: <49A191BB.40106@comlounge.net> <61dbdd7d0902221004o4cde38bat7265ab27640918ea@mail.gmail.com> <49A1A22D.3080100@gmail.com> <61dbdd7d0902221109i10379cbcw8265c10cff342b34@mail.gmail.com> <53cd6c2e0902230355w4a1b147fn685999078fcd2579@mail.gmail.com> <49A29022.3070901@cox.net> <61dbdd7d0902230408o488353fbg67cabc797b938876@mail.gmail.com> <53cd6c2e0902230513t67368240kcf6a013b7faab18c@mail.gmail.com> <1235395102.6608.6.camel@localhost> <53cd6c2e0902230543p3659f56dt57f4fd3516865cbd@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0j6bX0ksOse6IuIEQavx" Date: Mon, 23 Feb 2009 14:08:15 +0000 Message-Id: <1235398095.6608.27.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: [mmox] Identity and Objectivity X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 14:13:19 -0000 --=-0j6bX0ksOse6IuIEQavx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable What is an Object? What is an AV? (focus object?) What part of the system produces the displayable render? does each user get a choice for render quality? are we defining a generic 3D system or a mechanism of standardizing agreements using existing data-formats? some kind of serialization mechanism to allow for a "focus object" to be transferred or otherwise re-created specific to a new system? does anyone have a document listing any of the agreements going forward? does anyone have a document listing the *disagreements* and concepts people have put forward? Why do people see Identity and the Avatar as the same thing? the "Avatar" or Focus Object is entirely a representation or "face" to the Identity, where the Identity is not the AV from my understanding... additionally I will be typing up a draft document for peer review here and hope to see less squabbling dragged in from other MLs to this group... Sincerely, Jeremy --=-0j6bX0ksOse6IuIEQavx Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJoq3PAAoJECHrKutFYVwTU84P/2O5qpBliQwTwm9Ws7xdZSYm PiHH8ge6cdIkxtvdHS1oMTJ4YH2rY/kd+5LgMj4sjKDv63MhOWVREHEOAZ5RySln CgNxPDHW5vIuKyRyoG6NN4uyPWQmgOo3NDy6lglFHd+E2gxmQUDBRA+K1r89xXLw Te87XgJ3f85Qhnv4uzoa4Zs4TTBV5E3I4rXr18UTgMyYaLOmn00UrSmDgdNJlRY0 kLUT1mZ0Tn9CHqVixrI2GU/soevd1bcy53s0SptammylOqgMNLS1lvUjoWa1EdjL z2M7alE8BA+yDL2oolXRMt4P+01CPSy3mlpG7a6cKdtI4qpzYTVgQQcJK2cn9KjA PoOaG9tskTDdLxHf/b0Wn4KMkBmlpO+00fTV8eLq/xWc09SmgOdqR+N+GvqaqBSB zAtMkY+kU0MpfK88R7IkUJ9IPZFBN588Dam7Qt7NGcbptdHw5iSGibIiEJzIPZgL VAxo/B36ESWSUcRs+Kgr7rryx1/aveOkWER+l1l0XBioikSEsVkhF4z82qj6Yp7/ m+B3mt9VcnO5bajdyvXvvB8ebDbpBoQNbT/IxKQewLyBWDgh2U4H9dMEQQtG741u OG+dghHSB4hyiVza/3t9ws60y81e+O8L306+4O+Ov7QLCMHBscoi3QVLZgJXDKR/ 4YR+yESiXHsUC4VfrOGh =rHgC -----END PGP SIGNATURE----- --=-0j6bX0ksOse6IuIEQavx-- From dyerbrookme@juno.com Mon Feb 23 06:38:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 114283A69B1 for ; Mon, 23 Feb 2009 06:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIKnoE3GKu1a for ; Mon, 23 Feb 2009 06:38:35 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 2762D3A6802 for ; Mon, 23 Feb 2009 06:38:35 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail05.vgs.untd.com [10.181.12.145]) by smtpout04.vgs.untd.com with SMTP id AABE4FPHGABF84A2 for (sender ); Mon, 23 Feb 2009 06:38:30 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNytwfAH1WVBr7CyLcWfT7/w== Received: (from dyerbrookme@juno.com) by webmail05.vgs.untd.com (jqueuemail) id N94F673M; Mon, 23 Feb 2009 06:37:43 PST Received: from [68.161.198.3] by webmail05.vgs.untd.com with HTTP: Mon, 23 Feb 2009 14:36:58 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 14:36:58 GMT To: jesrad@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.093658.9303.0@webmail05.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 6:3:3586795210 X-UNTD-Peer-Info: 10.181.12.145|webmail05.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 14:38:36 -0000 >Trustworthiness of a given grid is better left to the full appreciation of the grid caretaker because there is no way to make an automatic validation of the DRM implementation in some distant machine (but that's really the most basic reason of all), so the entire debate about what constitutes a trusted grid or not WRT copyright is out of scope. Well, there's lots of things you can't reach out and confirm on a remote= machine, but hey, interoperability isn't an extension of the Wild West,= is it? It should be a regime of standards, not un-standards. If there w= asn't the allergy to DRM in advance as something evil music companies im= pose on people who want to rip music for a variety of their gadgets or f= riends, then there might be more breadth of perception about this matter= and the need for *diversity and choice*. DRM implementation may well be the basis for a system to determine trust= worthyness. Why not? Nothing but ideology to stop you there. >I actually wrote that mandating the implementation of DRM on top of any permission/copyright metadata transmission mechanism would severly reduce the number of grid systems that comply with the protocol. No, you said not to stream the permission at all, that it would take up = resources, that it shouldn't be streamed if you can't mandate DRM within= the streaming process. Why not let that be up to the participating grid= s that want to mandate DRM? Why preclude that option from them at the da= wn of interoperability among virtual worlds? Again, no reason, but an id= eological one. >I earn significant money from making full-perm content in Second Life, so these assertions sound empty to me. I'm also a fiercely individualistic capitalist (of the jusnaturalist kind), but you do not have to believe me. Again, this is an *ideology* and a belief about *a* type of commerce but= isn't a scientific fact for all types of commerce just because they are= e-commerce. E-commerce doesn't become opensource e-collectivism just be= cause you say so. The e-commerce in interoperable virtuals worlds should= n't be hobbled in advance because of some ardent ideological belief in K= evin Kelly's "8 Generatives" as the only option for digital content. Som= eone "making their living off full-perm items" is a) making a living off= "obfuscation," i.e. the script or code or item is so complex, that it n= eeds to have consulting services sold on top of it, even if it is "free = and open source" or b) making a living from customization which is very = much of a niche market and cannot be conceived as a solution for all com= merce or c) putting out a tip jar. CC is basically the putting out of a = tip jar at best, and a collectivist induced share at worst. It's not a r= obust permissions regime with copyright enabled for commerce on the basi= s of original continent, which should definitely be a choice in advance = for the metaverse, not precluded, and not merely added on as a module. ____________________________________________________________ Need cash? Click to get a cash advance. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTFRKCJy0PLklxCTx1v0QHf= 147OxPFPhZM7jLy0Btr8dokukPABky8/ From belxjander@gmail.com Mon Feb 23 07:16:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD4F3A6A92 for ; Mon, 23 Feb 2009 07:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE1YPnWYzQPc for ; Mon, 23 Feb 2009 07:16:08 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 7D43C3A6864 for ; Mon, 23 Feb 2009 07:16:08 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so1044489wag.5 for ; Mon, 23 Feb 2009 07:16:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=HJyOTZfSNFLw6agJLXWY6dOW1stxGIbF4T2yQhf2tog=; b=mJd08gNmps9Sv/BQ8bVrpm2F6c7SkDpeen6zwsZiv2LgNBSygTl1twS/9EhTAG5MMG sht81zmGbct49Uvi/Q54AK2qCK6ugCJpLkX6Pz3qKLtg5Vu+5kfrfiDdxDu/gWVIqgj/ V3X+RWx0mAPLJun3lS5KERmL91f/akL0+pWXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=LqtTOP73FkfPGcrwvcQvd3K/5+3XGUhXDrQ/pq6PCCp8z0m9GcB8jtAEMJKpi/PEhg OlhfEyLV3nYGP1vsj3roqg7hepB3pv/ul74n5Hrjc7+y2YBCxRoFDiOR08mYk0rsWX+o Cm0iPYKpSQMc0iXPPQCK4YVvaDFYz5arWdU5g= Received: by 10.114.131.11 with SMTP id e11mr1713069wad.75.1235402185334; Mon, 23 Feb 2009 07:16:25 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g14sm6261997rvb.0.2009.02.23.07.16.23 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 07:16:24 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <20090223.084454.24252.0@webmail09.vgs.untd.com> References: <20090223.084454.24252.0@webmail09.vgs.untd.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VFjujjC6Pv2K5kf8swlP" Date: Mon, 23 Feb 2009 15:11:04 +0000 Message-Id: <1235401864.6608.63.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] the arguments are sidelining people... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:16:09 -0000 --=-VFjujjC6Pv2K5kf8swlP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable currently I am seeing argument with regards the following Which virtual world system is more .... <<< CAN WE QUIT THE PISSING CONTEST? to DRM or not to DRM... allow encryption =3D=3D yes, mandate it, hell no... I will not mandate screwing over implimentation with damaged and suspicious black boxed code for my own implimentations and any form of DRM is easily subverted where a "trusted" party performs the subversion of its core function. reference =3D rc4 and other cipher algorythms having TLS support and NULL encryption, this is perfectly valid and provides a hole regardless of system. Either the content creators wake up and accept that each Virtual World IS different along with that eventually the web itself will become 3D and people are going to need their services a hell of a lot more for throwaway or personalized items. Each "system" may be as diverse as a "Star Trek" simulation and a "Battle of Troy" or become as diverse as the "Star Wars" and other Role-play systems backgrounds... Personally I can see people walking around various VWs as both Medievil and Technology-expanded variants... will they meet? yes... where? in any "open" or otherwise "public" virtual world with an interop agreement... My own personal view of virtual worlds has been affected by a LOT of my reading material and I dont expect anyone to actually believe how fast I read... since I can read somewhere in the order of 1-2 pages per minute without exaggeration at all... Ive also looked through a good dozen or more RPG systems and see something of a "Rifts" crossed with "Stargate" crossed with "contemporary now" occuring... a LOT of the VWs are *escapes* from the real world and need to keep that function, walking into a "Swords and Sorcery" simulation from a Tech sim would be a social no-no so I am asking about making options here... I may be coming across as harsh with the following but this is from the perspective of a potential developer on any of the VWs or a potential rival... 1: Identity - This is the User Account and what access is required? 2: Representation - This is the Avatar or focus object... 3: Connection - What form of connectivity occurs? 4: Transport - Is anything actually needing to be transferred cross-system? if so...what? 5: serialization of data - this needs to be agnostic and readily available... For the above I submit the following as usable... 1: Identity I submit use of OpenID and OAuth for current mechanisms and also recommend requiring some kind of SSL or TLS. 2: Representation I submit this to be *optional*... First access to any system - provision of a "TEMPORARY" account (garbage collect on expiry or mark "free" for re-use are choices here). 3: Connection I see this as actually bogus, only the Identity requires Connection and Transport of secure data, anything of the AV transferred would be usable for "common server" data, 4: Transport as a subsection of 3 and requiring 5: Serialization. llsd is a form of XML for my reading and it appears to conform to a file format more than XML does... make the tags for the angle brackets relevant. I submit the following to allow mixed human readable AND machine readable data content for use of mixed systems... 0000-0000-0000-0000-0010 0000-0000-0000-0000-1000 0000-0000-0000-0000-1001 0000-0000-0000-0000-1002 0000-0000-0000-0000-1003 0000-0000-0000-0000-1004 encoding:sha1:encodeddatastring encoding:sha1:encodeddatastring The above is submitted as an example for what I have in mind... extensible attributes. attributes may be added or edited by the original author or as technical limitations can permit legally. --=-VFjujjC6Pv2K5kf8swlP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJoryIAAoJECHrKutFYVwTLVEQAIe3HfB5TkOSeSB9M1fBrcxH NxGcuMrMQ/cZIvu78xKHY7Wusj4sXOzPlNNtXuvBnQAhdbRAe7+AgDGWhPku7I6J zS+1pL0QYMoLX6f1uOR1dTeJ2WwXCggCvv9rviCQvEF+fnsHllMIPnOCkYsqJJTO 1nCEoeps4Q4Jk7A3eH2BtoFnGKzjNqdWX8DLkOOVJ/GWtpYXHssSl1AjBo7eVepc N4JLQWbgv8a1D5/rRV+xzCVEQiqbFAMt7iF8mPW8Fy0r5QGDXxx1fbtJBvvQE051 XGa/qHq8vDUEUH9LRtHO4iGphJMtOt4buCYmaF4eAJMzg47xiVfGNVhILqVR9Rnn XgRGigD1CA/cSxFdUq1EuHmbnDIXG2Vj70VufG3PSaD2/PrIHXRWarhwYt0tQxoW OgxrVLxrSwS+NHRfZPoNF0jYjxD8mFa9Id4sywigUgGhG22HQeB3m+atA1Uro1H6 d9NzNJip2r8o0NxRYSPr49R/y+Vozva+h2F/CNGpH0RyTGkrgWRzWFoROug5K6Cv ic2m6yedBm/la3gYUobpkIrxJyJAixxbRkJbzJUWlJfgUveWr3v0PrFJ4X/u5Ebc x3AKaNJtvNpluD3HYtVuwsxr+ayubj0YsMLx+WUqzeYGGLCCCzQdEVIo73GVEd72 QqkgeIScLJZAXxpvIWwb =oaV/ -----END PGP SIGNATURE----- --=-VFjujjC6Pv2K5kf8swlP-- From gareth@litesim.com Mon Feb 23 07:33:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA87C3A6877 for ; Mon, 23 Feb 2009 07:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWPaDnhN2AaB for ; Mon, 23 Feb 2009 07:33:25 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.159]) by core3.amsl.com (Postfix) with ESMTP id C4AA53A6A80 for ; Mon, 23 Feb 2009 07:33:25 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6709333poe.4 for ; Mon, 23 Feb 2009 07:33:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.196.8 with SMTP id y8mr2086325rvp.101.1235403222553; Mon, 23 Feb 2009 07:33:42 -0800 (PST) In-Reply-To: <53cd6c2e0902230559g73aa66e3u4026f34b95ec215@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> <61dbdd7d0902230537n20f86856i8b392a80b1740bc0@mail.gmail.com> <53cd6c2e0902230559g73aa66e3u4026f34b95ec215@mail.gmail.com> Date: Mon, 23 Feb 2009 15:33:42 +0000 Message-ID: <61dbdd7d0902230733u41464ab9hfc9fd0f426a9aac0@mail.gmail.com> From: Gareth Nelson To: Jesrad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:33:26 -0000 You can't actually prevent the remote grid from doing anything once it has the data, if I accidentally claimed otherwise slap me with a hypocrite stick. The idea is that grids CAN enforce it, but the main point is just to make it possible to know what's allowed. However, since explained before this issue is much more complex than it at first appears and goes wildly out of scope, so consider my initial proposal withdrawn. On Mon, Feb 23, 2009 at 1:59 PM, Jesrad wrote: > This amounts to an implementation of some DRM, if I understand it > correctly. Would it be part of the protocol that grids are to > machine-read it and enforce it ? I would guess so if there is also a > section of the protocol addressing asset exchange. In this case the > problem is still more complex than anticipated (how do I restrict next > owner or next grid from restricting next owner or grid from > grid-exchanging the asset, etc.) > > Nevertheless, the entire issue is avoided by keeping content hosted in > its original grid, and the renderview being supplied by multiple > sources (according to the endpoint identity's credentials, if required > by the source grid implementation). Isn't it ? > > On Mon, Feb 23, 2009 at 2:37 PM, Gareth Nelson wrote: >> Well, the "stuff" was generally recogonised by others as being much >> more complex than my naive ideas on the subject would make it appear >> for multiple reasons which i'll point you at today's >> mmox@jabber.ietf.org logs for. >> I would be quite opposed to actually *mandating* any implementation of >> DRM, as i've said multiple times the idea is to let automated systems >> know what is allowed - it's up to the implementers of those systems >> whether they obey the license restrictions or not. >> The problem i'm trying to solve here is one where you need to manually >> ask the copyright holder every time you want to move their work to >> another grid. Making it machine-readable makes it possible to automate >> things, while a human-readable license does not. >> >> On Mon, Feb 23, 2009 at 1:32 PM, Jesrad wrote: >>> OK, but doesn't that just make this "stuff" a form of content, or at >>> most metadata ? In this case, it might fall off scope anyway. >>> >>> Even if it is recognized by consensus as a valid form of data to be >>> exchanged between grids, which is reasonable when presented in this >>> way, the twin problems of relevance WRT the domestic legal context and >>> of relevance WRT the actual implementation of any DRM in the target >>> grid make this sort of data irrelevant when it can be entirely >>> superseded by any other form of user content associated to the object >>> (like, say, a CC license notecard as in SL, or a simple copyright >>> notice). >>> >>> To put it differently: if we do not mandate any implementation of DRM >>> per protocol specifications, then this sort of data is purely >>> "client-side" and is better left to the resident/player-creator to >>> make and include in the concerned object. And if we do mandate DRM >>> implementation, then this implementation ifalls short of the diversity >>> of legal contexts (for example fair-use cases, which vary widely >>> between jurisdictions), breaks some models (like mine), and reduces >>> greatly the possibility of interoperability with a number of existing >>> VWs like the OpenGrid or (AFAIK) Solipsis. >>> >>> If you insist that there is space for this sort of metadata and the >>> protocol does not mandate DRM implementation for the server-side to >>> enforce, then I can live with it. But I'll still think it a waste of >>> resources. >>> >>> ...well, maybe it can be later hijacked for a better end user-worthy >>> purpose, I guess. >>> >>> On Mon, Feb 23, 2009 at 1:44 PM, Gareth Nelson wrote: >>>> Well, talking to a few others it seems the general consensus is "make >>>> a field on assets for all this stuff and make the scheme extensible". >>>> >>>> On Mon, Feb 23, 2009 at 10:27 AM, Jesrad wrote: >>>>> Hmm, "it's not gonna enforce IP technically" was not the point I >>>>> wanted to make. The actual point is: attempting to define a mechanism >>>>> for signalling what categories of actions are permitted or not under a >>>>> specific copyright law (which may or may not be applicable depending >>>>> on national/sovereign context) is a non-starter because of infinite >>>>> recursion. >>>>> >>>>> This is one of the main reasons I suggest curtaining the issue >>>>> entirely by adopting a multiple-host approach, where content (but not >>>>> necessarily the MMOX-layer object reference itself) remains hosted on >>>>> the originating grid and is not replicated between different grids >>>>> through the cross-grid protocol. The other reason for following such >>>>> an approach, is that it's the only one compatible with existing P2P >>>>> VWs like Solipsis. >>>>> >>>>> On Mon, Feb 23, 2009 at 11:21 AM, Gareth Nelson wrote: >>>>>> On Mon, Feb 23, 2009 at 10:10 AM, Jesrad wrote: >>>>>>>> Some people are going to insist on the DRM or not allow their content >>>>>>>> to be transferred at all >>>>>>> >>>>>>> And some people like me will insist that there is a way to do it that >>>>>>> cannot be prevented by third-party permissions system like this. >>>>>> >>>>>> But that's besides the point, since doing so isn't going to convince >>>>>> people to allow the content to move AND this system does not in fact >>>>>> prevent anything, it's a machine-readable version of the license - the >>>>>> only force comes from compliant systems and users or the courts. >>>>>> >>>>> _______________________________________________ >>>>> mmox mailing list >>>>> mmox@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mmox >>>>> >>>> >>> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From gareth@litesim.com Mon Feb 23 07:58:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985773A6932 for ; Mon, 23 Feb 2009 07:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.797 X-Spam-Level: X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TireFYgACCUR for ; Mon, 23 Feb 2009 07:58:51 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.154]) by core3.amsl.com (Postfix) with ESMTP id AC7983A67CC for ; Mon, 23 Feb 2009 07:58:51 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6733073poe.4 for ; Mon, 23 Feb 2009 07:59:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.28.2 with SMTP id f2mr2090724rvj.217.1235404748255; Mon, 23 Feb 2009 07:59:08 -0800 (PST) In-Reply-To: <20090223.093658.9303.0@webmail05.vgs.untd.com> References: <20090223.093658.9303.0@webmail05.vgs.untd.com> Date: Mon, 23 Feb 2009 15:59:08 +0000 Message-ID: <61dbdd7d0902230759p304526deq8af398e10ea9c4b0@mail.gmail.com> From: Gareth Nelson To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 15:58:52 -0000 For someone talking about choice so much you seem very preconcerned with mandating what choices VW providers make. Nothing wrong with putting a field in the asset metadata for permissions stuff, but it definitely should NOT be a mandatory part of the standard. On Mon, Feb 23, 2009 at 2:36 PM, dyerbrookme@juno.com wrote: >>Trustworthiness of a given grid is better left to the full > appreciation of the grid caretaker because there is no way to make an > automatic validation of the DRM implementation in some distant machine > (but that's really the most basic reason of all), so the entire debate > about what constitutes a trusted grid or not WRT copyright is out of > scope. > > Well, there's lots of things you can't reach out and confirm on a remote = machine, but hey, interoperability isn't an extension of the Wild West, is = it? It should be a regime of standards, not un-standards. If there wasn't t= he allergy to DRM in advance as something evil music companies impose on pe= ople who want to rip music for a variety of their gadgets or friends, then = there might be more breadth of perception about this matter and the need fo= r *diversity and choice*. > > DRM implementation may well be the basis for a system to determine trustw= orthyness. Why not? Nothing but ideology to stop you there. > >>I actually wrote that mandating the implementation of DRM on top of > any permission/copyright metadata transmission mechanism would severly > reduce the number of grid systems that comply with the protocol. > > No, you said not to stream the permission at all, that it would take up r= esources, that it shouldn't be streamed if you can't mandate DRM within the= streaming process. Why not let that be up to the participating grids that = want to mandate DRM? Why preclude that option from them at the dawn of inte= roperability among virtual worlds? Again, no reason, but an ideological one= . > >>I earn significant money from making full-perm content in Second Life, > so these assertions sound empty to me. I'm also a fiercely > individualistic capitalist (of the jusnaturalist kind), but you do not > have to believe me. > > Again, this is an *ideology* and a belief about *a* type of commerce but = isn't a scientific fact for all types of commerce just because they are e-c= ommerce. E-commerce doesn't become opensource e-collectivism just because y= ou say so. The e-commerce in interoperable virtuals worlds shouldn't be hob= bled in advance because of some ardent ideological belief in Kevin Kelly's = "8 Generatives" as the only option for digital content. Someone "making the= ir living off full-perm items" is a) making a living off "obfuscation," i.e= . the script or code or item is so complex, that it needs to have consultin= g services sold on top of it, even if it is "free and open source" or b) ma= king a living from customization which is very much of a niche market and c= annot be conceived as a solution for all commerce or c) putting out a tip j= ar. CC is basically the putting out of a tip jar at best, and a collectivis= t induced share at worst. It's not a robust permissions regime with copyrig= ht enabled for co > mmerce on the basis of original continent, which should definitely be a = choice in advance for the metaverse, not precluded, and not merely added on= as a module. > > > ____________________________________________________________ > Need cash? Click to get a cash advance. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTFRKCJy0PLklxCTx1v0QHf1= 47OxPFPhZM7jLy0Btr8dokukPABky8/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From morgaine.dinova@googlemail.com Mon Feb 23 08:31:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F187528C15A for ; Mon, 23 Feb 2009 08:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.01 X-Spam-Level: X-Spam-Status: No, score=-1.01 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Upw+PybzhTHc for ; Mon, 23 Feb 2009 08:31:13 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 32A2528C142 for ; Mon, 23 Feb 2009 08:31:12 -0800 (PST) Received: by bwz5 with SMTP id 5so4923057bwz.13 for ; Mon, 23 Feb 2009 08:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Vnt8CuPAzuWwNGoznGg0ImpR84EPmUNabvmQF4G7Nr8=; b=NLUvkvR9x3FlMyUrOT2gLHnteNjb4lOVVTN34Bv1TRp/LwsEJj8Ijv9+WCrwuUsLTV aPWe46d1KrtTHPNAFZYCzh5ogKtUsi/ccpxkS1gKGTomDvt8Y7G1cO6chO2zJqbXOgjH bto8cUSSs7aV5vyjeZwTS74DO1207nzI3NIjY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gyZ46BTG0EKOYO948910bSG4pn/LlNwWZSNt7z2bV3FGAcRUsf8ZVrs45w0zLPjcO/ LVtH+9/9ci6NYbJD/4fbda47Awef6eqcTk8abQ8W8tJ5xtXKWzgH6E7PsyzeO05wa8Zf Ye8SN8U8X7wX+UcJ+WoYorSgYaYTQE8BOsiHY= MIME-Version: 1.0 Received: by 10.181.216.12 with SMTP id t12mr1574933bkq.122.1235406687380; Mon, 23 Feb 2009 08:31:27 -0800 (PST) In-Reply-To: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> Date: Mon, 23 Feb 2009 16:31:27 +0000 Message-ID: From: Morgaine To: Gareth Nelson Content-Type: multipart/alternative; boundary=001636c59860c12803046398885c Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:31:15 -0000 --001636c59860c12803046398885c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is not an area where a bit of quick brainstorming will yield useful fruit. It's an immensely complex area that handles the expression of rights, permissions, licenses, covenants, patent grants, EULAs, and many other items that are only partly analytic, and then intertwines them all with real-life semantics to yield an explosion of complexity beyond anything we can plan to handle, or even imagine. And before anyone mentions the phrase "machine parseable", please note that authors have the legal right in most jurisdictions to apply multiple * incompatible* licenses to a work of authorship ... good luck resolving that mechanically. Also, rights/restrictions are not all of the common static type ("no rights change"), but can also increase or decrease downstream. Authors need the semantic of "decreasing rights allowed" to allow customization of generic assets by intermediaries such as rebranders, as well as that of "increasing rights allowed" to allow incorporation of their works into mashups and remixes while retaining visibility as authors, a growing interest. As if that weren't hard enough already, the diversity of VWs will add complication because many will have incompatible access domains: for example, group access is a common form of rights/restriction, but groups may be disjoint or overlapping or hierarchical in different VWs, so the semantic of group access is not immediately portable. Plus, the non-hierarchical objects of SL do not allow creators to make higher-level objects by composition and thus ride on the shoulders of giants, so we can expect them to become a subset of normal interop objects; as a result, rights handling will need to tackle hierarchical object composition as well. Not easy. And then on top of that, it all gets even hairier when attempting to apply the law of the land in different jurisdictions. For example, some jurisdictions allow Fair Use or Fair Dealing, so denial of access for such use is inappropriate. Other jurisdictions provide strong support for accessibility, so media needs to be format-shiftable to suit a handicap which can be in conflict with claimed authors rights, and so on. This area is so hard that the best we can do is to express *intent*. To express *intent *satisfactorily in the presence of what I hope is clearly a very complex domain, you have to be not only flexible but *extensible*, because the rights/restrictions needs of VWs cannot be forseen. One way of doing this that is interop-friendly is to endow objects with a *property list*, onto which authors can place an arbitrary number of arbitrarily tagged metadata items, for example: - *GPLv3->{LICENSE-UUID}* - *LindenRights->{version,perms}* - *CC->{3.0,by-nc-sa}* - *MPEG21->{REL_XML_schema} * - *ccREL->{RDFa_expression_or_URL}* - *DoD->{crypto-signed-perms-block} * Some of the above tags you'll all recognize, and some you may not, which is precisely the benefit --- the set that you recognize in your world may be a completely different set to that recognized in a second virtual world, and yet the properties can still be processed. This remains true even if an object passes through multiple worlds. Such a property list is easy to handle on interop: just look up the tags until you find some that you recognize (this may require external lookup if none are cached, and possible ordering), and if required then extract and parse the tagged metadata. Some tags express everything you need to know in the tag name, such *GPLv3*, so passage through interop is trivial. Other tags require metadata parsing and checking of field values, such as * LindenRights*. The definition of tags and metadata that do not use published standards would of course be up to the worlds that use them, but use of published standards would be highly recommended. The scheme is not tied to top-level OR alternatives either, but can be extended to arbitrary logical expressions within the metadata. The above is not proposed as a specific solution, but only to illustrate the general concept of using property lists as the mechanism for extensibility of metadata properties such as permissions and licenses. Without such extensibility you cannot pretend to be addressing the needs of diverse future worlds, yet it is also highly practical because it allows existing worlds with established rights/permissions structures to enter the world of interop gracefully. And it is future proof. PS. Don't invent your own rights languages unless nothing else is suitable --- at the very least inform yourselves about the standards that already exist first, otherwise you are bound to get it wrong if you handwave a new solution. A good start might be to examine the *MPEG21* and *ccREL*standards (used as tags above): *MPEG21 - http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.htm ccREL - http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/ * Morgaine. On Mon, Feb 23, 2009 at 8:59 AM, Gareth Nelson wrote: > Just been talking to Adam about this and knocked out a very very rough > spec. It may be early in the game to discuss this issue, but it's one > that drives a lot of emotion in people on all sides of the debate. > > So, without further a-do, here's a rough spec for a DSL (Domain > Specific Language) for permissions to discuss (copied and pasted from > my vim session, excuse any formatting weirdness): > Original concept courtesy of Adam Frisby, see > http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/ > > Very very rough thinking out loud > > Each asset has a set of metadata fields: > Author > Creation timestamp > Last modified timestamp > Logs of modifications? (TBD) > > Possible actions: > Copy > Modify > Transfer > Transfer for cash > > Each action attached to a simple function that returns a boolean value > if action is allowed. > Data types: > Entity > Describes a user, organisation, system or network > Asset > Describes an asset ;) > Location > Describes a virtual location, rather than a physical system > Time > Date and time :) > > Entity has these fields: > Name > UUID > Class (person, organisation, system, network) > Optional fields for person entities: > Agent domain? (TBD) > System (what system is the user connecting from - may be withheld > for > privacy reasons) > Location (where in the metaverse are they?) > Optional fields for organisation entities: > Organisation type (nonprofit/commercial/government etc) > Company type (for corporations: LLC/Ltd/PLC/whatever) > Address (i.e postal address) > Technical contact (a person entity!) > Optional fields for system entities: > Platform > System hash (hash of various bits of hardware, HD serial and > ethernet MAC etc) > Network > Current IP address > Optional fields for network entity > Technical contact (heh, redundant) > CIDR prefix > > Asset > Name > MIME type > UUID > Creator > Creation time > Last modified time > Last modified by > > Location > TBD (Obviously not the SL style Region/x/y/z) > > Time > You need to ask? ok, > Day > Week > Month > Year > Hour > Minute > Second > All integers > > Simple comparision operators to match on what is passed to the functions > !=, ==, >, <, >=, <=, a few simple string functions, the usual suspects > > function prototypes: > copy(Entity src, Location location, Time time, Asset ass) > src == the user currently holding the asset who wishes to copy > it > location == the location the requesting user is inhabiting at > present > time == the time the request was made at (just in case there's > batch processing or serious latency) > ass == the asset being copied > modify(Entity modifier, Asset ass, Time time, Location loc) > modifier == the entity trying to modify > ass == the entity they're trying to modify > time == the current time > loc == where is our modifier while they're trying to modify? > transfer(Entity src, Entity dst, Location loc, Time time, Asset ass) > Same as copy essentially > sell() is just transfer, but invoked for transfers in exchange for > compensation > > The modify() function could probably do with a description (if > possible) of the modification being requested, for example in my own > work i'd want to prohibit modifications to the permissions in order to > enforce the GPL, others may have different requirements. > > > DANGER! DANGER! READ: > Any system that can be proposed here can only be used to express > intent, it can express that intent very clearly using a DSL as i've > roughly > spec'ed out above, but it will never be possible to actually > enforce it on systems that do not want to enforce it. I'll note that > personally I > absolutely hate DRM for the most part, but if it's going to be a > reality it should be done right, and should allow any type of license > to be roughly > expressed in a way that can be handled by automated systems. If for > no other reason than mere practicality, a decent DSL for specifying > what > permissions an author of a copyrighted work has granted under > existing copyright law can be useful and saves having to pester the > author. > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --001636c59860c12803046398885c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is not an area where a bit of quick brainstorming will yield usefu= l fruit.

It's an immensely complex area that handles the express= ion of rights, permissions, licenses, covenants, patent grants, EULAs, and = many other items that are only partly analytic, and then intertwines them a= ll with real-life semantics to yield an explosion of complexity beyond anyt= hing we can plan to handle, or even imagine.

And before anyone mentions the phrase "machine parseable", pl= ease note that authors have the legal right in most jurisdictions to apply = multiple incompatible licenses to a work of authorship ... good luck= resolving that mechanically.

Also, rights/restrictions are not all of the common static type ("= no rights change"), but can also increase or decrease downstream. = ; Authors need the semantic of "decreasing rights allowed" to all= ow customization of generic assets by intermediaries such as rebranders, as= well as that of "increasing rights allowed" to allow incorporati= on of their works into mashups and remixes while retaining visibility as au= thors, a growing interest.

As if that weren't hard enough already, the diversity of VWs will a= dd complication because many will have incompatible access domains:  f= or example, group access is a common form of rights/restriction, but groups= may be disjoint or overlapping or hierarchical in different VWs, so the se= mantic of group access is not immediately portable.  Plus, the non-hie= rarchical objects of SL do not allow creators to make higher-level objects = by composition and thus ride on the shoulders of giants, so we can expect t= hem to become a subset of normal interop objects;  as a result, rights= handling will need to tackle hierarchical object composition as well. = ; Not easy.

And then on top of that, it all gets even hairier when attempting to ap= ply the law of the land in different jurisdictions.  For example, some= jurisdictions allow Fair Use or Fair Dealing, so denial of access for such= use is inappropriate.  Other jurisdictions provide strong support for= accessibility, so media needs to be format-shiftable to suit a handicap wh= ich can be in conflict with claimed authors rights, and so on.  This a= rea is so hard that the best we can do is to express intent.

To express intent satisfactorily in the presence of what I hope = is clearly a very complex domain, you have to be not only flexible but e= xtensible, because the rights/restrictions needs of VWs cannot be forse= en.  One way of doing this that is interop-friendly is to endow object= s with a property list, onto which authors can place an arbitrary nu= mber of arbitrarily tagged metadata items, for example:
  • GPLv3->{LICENSE-UUID}
  • LindenRights->{ve= rsion,perms}
  • CC->{3.0,by-nc-sa}
  • MPEG21= ->{REL_XML_schema}
  • ccREL->{RDFa_expression_or_URL}=
  • DoD->{crypto-signed-perms-block}
Some of the abo= ve tags you'll all recognize, and some you may not, which is precisely = the benefit --- the set that you recognize in your world may be a completel= y different set to that recognized in a second virtual world, and yet the p= roperties can still be processed.  This remains true even if an object= passes through multiple worlds.

Such a property list is easy to handle on interop:  just look up t= he tags until you find some that you recognize (this may require external look= up if none are cached, and possible ordering), and if required then extract an= d parse the tagged metadata.  Some tags express everything you need to know in the tag name, such GPLv3, so passage through interop is trivial.  Other= tags require metadata parsing and checking of field values, such as Lin= denRights.  The definition of tags and metadata that do not use pu= blished standards would of course be up to the worlds that use them, but us= e of published standards would be highly recommended.

The scheme is not tied to top-level OR alternatives either, but can be = extended to arbitrary logical expressions within the metadata.

The a= bove is not proposed as a specific solution, but only to illustrate the gen= eral concept of using property lists as the mechanism for extensibility of = metadata properties such as permissions and licenses.  Without such ex= tensibility you cannot pretend to be addressing the needs of diverse future= worlds, yet it is also highly practical because it allows existing worlds = with established rights/permissions structures to enter the world of intero= p gracefully.  And it is future proof.

PS.  Don't invent your own rights languages unless nothing els= e is suitable --- at the very least inform yourselves about the standards t= hat already exist first, otherwise you are bound to get it wrong if you han= dwave a new solution.  A good start might be to examine the MPEG21<= /b> and ccREL standards (used as tags above):

MPEG21 - http://www.chiariglione.org/mpeg/standards/mpeg-21/mpeg-21.= htm
ccREL - http://www.w3.org/Submission/2008/SUBM-ccREL-20080501/


Morgaine.





On = Mon, Feb 23, 2009 at 8:59 AM, Gareth Nelson <gareth@litesim.com> wrote:
=
Just been talking to Adam about this and knocked out a very very rough
spec. It may be early in the game to discuss this issue, but it's one that drives a lot of emotion in people on all sides of the debate.

So, without further a-do, here's a rough spec for a DSL (Domain
Specific Language) for permissions to discuss (copied and pasted from
my vim session, excuse any formatting weirdness):
Original concept courtesy of Adam Frisby, see
http://www.adamfrisby.com/blog/2008/08/hypothetical-per= missions/

Very very rough thinking out loud

Each asset has a set of metadata fields:
       Author
       Creation timestamp
       Last modified timestamp
       Logs of modifications? (TBD)

Possible actions:
       Copy
       Modify
       Transfer
       Transfer for cash

Each action attached to a simple function that returns a boolean value
if action is allowed.
Data types:
       Entity
               Describes a user, o= rganisation, system or network
       Asset
               Describes an asset = ;)
       Location
               Describes a virtual= location, rather than a physical system
       Time
               Date and time :)
Entity has these fields:
       Name
       UUID
       Class (person, organisation, system, network) Optional fields for person entities:
       Agent domain? (TBD)
       System (what system is the user connecting from= - may be withheld for
privacy reasons)
       Location (where in the metaverse are they?)
Optional fields for organisation entities:
       Organisation type (nonprofit/commercial/governm= ent etc)
       Company type (for corporations: LLC/Ltd/PLC/wha= tever)
       Address (i.e postal address)
       Technical contact (a person entity!)
Optional fields for system entities:
       Platform
       System hash (hash of various bits of hardware, = HD serial and ethernet MAC etc)
       Network
       Current IP address
Optional fields for network entity
       Technical contact (heh, redundant)
       CIDR prefix

Asset
       Name
       MIME type
       UUID
       Creator
       Creation time
       Last modified time
       Last modified by

Location
       TBD (Obviously not the SL style Region/x/y/z)
Time
       You need to ask? ok,
       Day
       Week
       Month
       Year
       Hour
       Minute
       Second
       All integers

Simple comparision operators to match on what is passed to the functions !=3D, =3D=3D, >, <, >=3D, <=3D, a few simple string functions, = the usual suspects

function prototypes:
copy(Entity src, Location location, Time time, Asset ass)
       src      =3D=3D the user current= ly holding the asset who wishes to copy it
       location =3D=3D the location the requesting use= r is inhabiting at present
       time     =3D=3D the time the request = was made at (just in case there's
batch processing or serious latency)
       ass      =3D=3D the asset being = copied
modify(Entity modifier, Asset ass, Time time, Location loc)
       modifier =3D=3D the entity trying to modify
       ass      =3D=3D the entity they&= #39;re trying to modify
       time     =3D=3D the current time
       loc      =3D=3D where is our mod= ifier while they're trying to modify?
transfer(Entity src, Entity dst, Location loc, Time time, Asset ass)
       Same as copy essentially
sell() is just transfer, but invoked for transfers in exchange for compensa= tion

The modify() function could probably do with a description (if
possible) of the modification being requested, for example in my own
work i'd want to prohibit modifications to the permissions in order to<= br> enforce the GPL, others may have different requirements.


DANGER! DANGER! READ:
       Any system that can be proposed here can only b= e used to express
intent, it can express that intent very clearly using a DSL as i've
roughly
       spec'ed out above, but it will never be pos= sible to actually
enforce it on systems that do not want to enforce it. I'll note that personally I
       absolutely hate DRM for the most part, but if i= t's going to be a
reality it should be done right, and should allow any type of license
to be roughly
       expressed in a way that can be handled by autom= ated systems. If for
no other reason than mere practicality, a decent DSL for specifying
what
       permissions an author of a copyrighted work has= granted under
existing copyright law can be useful and saves having to pester the
author.
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--001636c59860c12803046398885c-- From jesrad@gmail.com Mon Feb 23 08:31:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9604F3A6802 for ; Mon, 23 Feb 2009 08:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEeUbxP7-Ypx for ; Mon, 23 Feb 2009 08:31:33 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 3457F3A6A6E for ; Mon, 23 Feb 2009 08:31:33 -0800 (PST) Received: by mail-bw0-f161.google.com with SMTP id 5so4923057bwz.13 for ; Mon, 23 Feb 2009 08:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IeWWuFKovXpHE4e1HZHjjnZ8mTVhsVy2DD2M9apwEGI=; b=xar2lwNB+DVRmFdc0VaF+7fEFkdhqe0i58b07/nYF3Dh+2DXFNhg74kLhxpDn2gVv8 +Qt55oU2SWLEJUpoV1dsjTg1mR2Vf6mNy6qAZwCF8YyjpzaV/L1n7xhEhUaChCvR7+qF a5bkjrAMEHgrDKj4muF2awVVlyx+yGutfYvgg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SLReNmh5ztDweJ3xNreyM7o+T/pHkwbeYuN2Vjd6oAszV4bJ8sFaYNoUZXH3xvDQZ2 OzIptox5RTB1HyLLZoKI4wQJ9gHIkGfU5JEs5NSv/vFV0ss/LKdyk+1ediWQIGKuQaCe Z7CUIpIzfeyuhPCD5fvelXOuN0JmbC/MsNU4A= MIME-Version: 1.0 Received: by 10.181.155.9 with SMTP id h9mr1573128bko.176.1235406711358; Mon, 23 Feb 2009 08:31:51 -0800 (PST) In-Reply-To: <20090223.093658.9303.0@webmail05.vgs.untd.com> References: <20090223.093658.9303.0@webmail05.vgs.untd.com> Date: Mon, 23 Feb 2009 17:31:51 +0100 Message-ID: <53cd6c2e0902230831i17978c04i34aaacb12e881032@mail.gmail.com> From: Jesrad To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:31:34 -0000 > DRM implementation may well be the basis for a system to determine trustw= orthyness. Why not? Because so far the only successful examples of such a trust scheme require that the software designer also designs and distributes the hardware to run it on. To my knowledge there is but one thing you can consistently and reliably check about a remote machine, it is that of intelligent behaviour. That's called a Turing test. > Again, this is an *ideology* and a belief about *a* type of commerce but = isn't a scientific fact for all types of commerce just because they are e-c= ommerce. I run my business on sound economics, not ideology. I've personnally expanded Austrian Economics to the field of intellectual property then made an experiment to test this theoretical advance, found positive results, then made it a successful business (which does not fall into any of your three caricatural categories). But that's completely irrelevant debate anyway, since I'm not advocating the suppression of copyright for people who want to have it. My model can coexist with copyright-based models, provided I can opt my content out of any DRM system. One of the reasons I am participating in this group is to ensure my business model will not be hindered by the design of the protocol. I believe this is the same motive as yours. > No, you said not to stream the permission at all, that it would take up r= esources, that it shouldn't be streamed if you can't mandate DRM within the= streaming process. No. Read again: I have said that streaming this data as a specific data type seperate from others is a waste of resources if any DRM mechanism is outside of the protocol anyway. That's different. Without a DRM system for treating this data, it is purely client-side and as such it's simple content, so it does not merit a specific data type/stream for itself, just like we do not have two different TCP implementations for transporting webpages and emails. This is a technical reason, and I'm growing tired of having to answer empty accusations of "ideology", especially so when I've been advocating exactly the same thing as you have initially: that the MMOX group and the IETF abstain from including this issue at all in the scope of the protocol and that it be left entirely to the grid hosts to decide policy on the subject. > Why not let that be up to the participating grids that want to mandate DR= M? Why preclude that option from them at the dawn of interoperability among= virtual worlds? I have not said that the data should not be transmitted. I have said that reserving a special data type and/or strem for it seems like a waste to me because it will not have any relevance to the protocol mechanism (it will be treated outside of the MMOX-layer). Then, I got told that it might have a use at the MMOX-layer after all, for the purpose of automatic filtering of content for cross-grid asset exchange. And as I have said then, this is a reasonable enough justification that I won't mind if MMOX includes it. On Mon, Feb 23, 2009 at 3:36 PM, dyerbrookme@juno.com wrote: >>Trustworthiness of a given grid is better left to the full > appreciation of the grid caretaker because there is no way to make an > automatic validation of the DRM implementation in some distant machine > (but that's really the most basic reason of all), so the entire debate > about what constitutes a trusted grid or not WRT copyright is out of > scope. > > Well, there's lots of things you can't reach out and confirm on a remote = machine, but hey, interoperability isn't an extension of the Wild West, is = it? It should be a regime of standards, not un-standards. If there wasn't t= he allergy to DRM in advance as something evil music companies impose on pe= ople who want to rip music for a variety of their gadgets or friends, then = there might be more breadth of perception about this matter and the need fo= r *diversity and choice*. > > DRM implementation may well be the basis for a system to determine trustw= orthyness. Why not? Nothing but ideology to stop you there. > >>I actually wrote that mandating the implementation of DRM on top of > any permission/copyright metadata transmission mechanism would severly > reduce the number of grid systems that comply with the protocol. > > No, you said not to stream the permission at all, that it would take up r= esources, that it shouldn't be streamed if you can't mandate DRM within the= streaming process. Why not let that be up to the participating grids that = want to mandate DRM? Why preclude that option from them at the dawn of inte= roperability among virtual worlds? Again, no reason, but an ideological one= . > >>I earn significant money from making full-perm content in Second Life, > so these assertions sound empty to me. I'm also a fiercely > individualistic capitalist (of the jusnaturalist kind), but you do not > have to believe me. > > Again, this is an *ideology* and a belief about *a* type of commerce but = isn't a scientific fact for all types of commerce just because they are e-c= ommerce. E-commerce doesn't become opensource e-collectivism just because y= ou say so. The e-commerce in interoperable virtuals worlds shouldn't be hob= bled in advance because of some ardent ideological belief in Kevin Kelly's = "8 Generatives" as the only option for digital content. Someone "making the= ir living off full-perm items" is a) making a living off "obfuscation," i.e= . the script or code or item is so complex, that it needs to have consultin= g services sold on top of it, even if it is "free and open source" or b) ma= king a living from customization which is very much of a niche market and c= annot be conceived as a solution for all commerce or c) putting out a tip j= ar. CC is basically the putting out of a tip jar at best, and a collectivis= t induced share at worst. It's not a robust permissions regime with copyrig= ht enabled for commerce on the basis of original continent, which should de= finitely be a choice in advance for the metaverse, not precluded, and not m= erely added on as a module. > > > ____________________________________________________________ > Click for online loan, fast & no lender fee, approval today > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIpd6J6MwHjlxeSewC9y1UQ= en8TcPpE1mMoHgbrVwXpT9LkppWCC8/ > From dyerbrookme@juno.com Mon Feb 23 08:32:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79CDA28C166 for ; Mon, 23 Feb 2009 08:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOqARJ6HoHnE for ; Mon, 23 Feb 2009 08:32:31 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id B101028C142 for ; Mon, 23 Feb 2009 08:32:31 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail09.vgs.untd.com [10.181.12.149]) by smtpout06.vgs.untd.com with SMTP id AABE4FV6GAYNXRDA for (sender ); Mon, 23 Feb 2009 08:32:06 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkN1+4us47t58LoPPNz0X9M1w== Received: (from dyerbrookme@juno.com) by webmail09.vgs.untd.com (jqueuemail) id N94NN3E2; Mon, 23 Feb 2009 08:31:14 PST Received: from [68.161.198.3] by webmail09.vgs.untd.com with HTTP: Mon, 23 Feb 2009 16:30:41 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 16:30:41 GMT To: gareth@litesim.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.113041.5499.0@webmail09.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:3164220495 X-UNTD-Peer-Info: 10.181.12.149|webmail09.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:32:32 -0000 X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7C093A6AEF for ; Mon, 23 Feb 2009 08:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAPdE6MhMLAe for ; Mon, 23 Feb 2009 08:40:01 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 287A23A6AEE for ; Mon, 23 Feb 2009 08:40:01 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail09.vgs.untd.com [10.181.12.149]) by smtpout04.vgs.untd.com with SMTP id AABE4FWMRARDQB92 for (sender ); Mon, 23 Feb 2009 08:40:15 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNZm6sVeeHZ4T0fGHY33XwkQ== Received: (from dyerbrookme@juno.com) by webmail09.vgs.untd.com (jqueuemail) id N94N7JZF; Mon, 23 Feb 2009 08:40:14 PST Received: from [68.161.198.3] by webmail09.vgs.untd.com with HTTP: Mon, 23 Feb 2009 16:39:37 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 16:39:37 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090223.113937.5499.1@webmail09.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:3294948160 X-UNTD-Peer-Info: 10.181.12.149|webmail09.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:40:02 -0000 >Either the content creators wake up and accept that each Virtual World IS different along with that eventually the web itself will become 3D an= d people are going to need their services a hell of a lot more for thro= waway or personalized items. Well, actually, uh, it's not the content creators that have to "wake up"= these days, ostensibly banged over the head by the "see if copy it" pro= blem. No, it's the platform providers waking up (Facebook TOS) to the ne= ed to ensure the permissions dimentions of commerce or fail. And while t= he web itself will become 3-D, there is nothing inherently scientificall= y required that Web 2.0 or 3.0 lock-step follow the iteration of Web 1.0= where forcibly interoperability and forcible de-walling of gardens was = somehow the privileged norm. = There's also, again, an ideological imperative here coming from the copy= leftist Kevin Kelly "8 generatives" with the "customization will make yo= u a living" shill and the shill of "just keep making new items faster pe= ople throw them away anyway, stay one step ahead of the hackers". Again,= this isn't scientifically or even journalistically proven, that people = don't have the support of government or corporate funding already actual= ly make livings this way. The virtual worlds that actually make money both for their providers and= their users, and not just special customers behind government or corpor= ate firewalls don't have the luxury of imposing stone soup on everyone. = Somebody has to grow the turnip and get paid for it, you don't make an e= conomy by everybody bringing a carrot they swiped from another's garden.= ____________________________________________________________ Compete with the big boys. Click here to find products to benefit your = business. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTI97yZY6YGTQ5qP83PheaJ= QmvPZXCHdwXmoqlSwC2vddxB97lHl9u/ From gareth@litesim.com Mon Feb 23 08:44:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCA13A6AC6 for ; Mon, 23 Feb 2009 08:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDytq0iWm5ai for ; Mon, 23 Feb 2009 08:44:07 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.156]) by core3.amsl.com (Postfix) with ESMTP id 976353A6A39 for ; Mon, 23 Feb 2009 08:44:07 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6771035poe.4 for ; Mon, 23 Feb 2009 08:44:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.85.13 with SMTP id n13mr2113010rvl.102.1235407464501; Mon, 23 Feb 2009 08:44:24 -0800 (PST) In-Reply-To: <20090223.113937.5499.1@webmail09.vgs.untd.com> References: <20090223.113937.5499.1@webmail09.vgs.untd.com> Date: Mon, 23 Feb 2009 16:44:24 +0000 Message-ID: <61dbdd7d0902230844r6322e663h12970f87ca5b368d@mail.gmail.com> From: Gareth Nelson To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:44:08 -0000 I'm just going to make 2 comments: 1 - This is getting way way out of scope 2 - My current favourite author makes a living through creative commons licensed sci-fi novels, so yes - you can make a living without a copyright monopoly, but that brings me back to point 1 On Mon, Feb 23, 2009 at 4:39 PM, dyerbrookme@juno.com wrote: >>Either the content creators wake up and accept that each Virtual World > IS different along with that eventually the web itself will become 3D and= people are going to need their services a hell of a lot more for throwawa= y or personalized items. > > Well, actually, uh, it's not the content creators that have to "wake up" = these days, ostensibly banged over the head by the "see if copy it" problem= . No, it's the platform providers waking up (Facebook TOS) to the need to e= nsure the permissions dimentions of commerce or fail. And while the web its= elf will become 3-D, there is nothing inherently scientifically required th= at Web 2.0 or 3.0 lock-step follow the iteration of Web 1.0 where forcibly = interoperability and forcible de-walling of gardens was somehow the privile= ged norm. > > There's also, again, an ideological imperative here coming from the copyl= eftist Kevin Kelly "8 generatives" with the "customization will make you a = living" shill and the shill of "just keep making new items faster people th= row them away anyway, stay one step ahead of the hackers". Again, this isn'= t scientifically or even journalistically proven, that people don't have th= e support of government or corporate funding already actually make livings = this way. > > The virtual worlds that actually make money both for their providers and = their users, and not just special customers behind government or corporate = firewalls don't have the luxury of imposing stone soup on everyone. Somebod= y has to grow the turnip and get paid for it, you don't make an economy by = everybody bringing a carrot they swiped from another's garden. > > ____________________________________________________________ > Compete with the big boys. Click here to find products to benefit your b= usiness. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTI97yZY6YGTQ5qP83PheaJQ= mvPZXCHdwXmoqlSwC2vddxB97lHl9u/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From dyerbrookme@juno.com Mon Feb 23 08:46:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A371028C16A for ; Mon, 23 Feb 2009 08:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW40JukVokRz for ; Mon, 23 Feb 2009 08:46:29 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 83FB63A698F for ; Mon, 23 Feb 2009 08:46:29 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail09.vgs.untd.com [10.181.12.149]) by smtpout03.vgs.untd.com with SMTP id AABE4FWY7ALDGV52 for (sender ); Mon, 23 Feb 2009 08:46:21 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNpBySk9wLlpInLWdNSHlzIQ== Received: (from dyerbrookme@juno.com) by webmail09.vgs.untd.com (jqueuemail) id N94PHK4E; Mon, 23 Feb 2009 08:45:43 PST Received: from [68.161.198.3] by webmail09.vgs.untd.com with HTTP: Mon, 23 Feb 2009 16:44:23 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 16:44:23 GMT To: jesrad@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.114423.5499.2@webmail09.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:1:711688090 X-UNTD-Peer-Info: 10.181.12.149|webmail09.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 16:46:30 -0000 >My model can coexist with copyright-based models, provided I can opt my content out of any DRM system. With a DRM system like c/m/t being conveyed, you check off c/m/t if you = want full perms to be distributed *shrugs*. That's all. Transporting the= metadata of c/m/t -- or no c/m/t and demanding a regime to implement it= does not preclude you from "opting out" by...checking off c/m/t. Why wo= uld you think that the act of having to check off c/m/t to get full perm= s, so that others who *do not* want to check them off and wish to make a= living not through consulting but by object sales would somehow preclud= e your full-perms distribution? Makes no sense, again, except as an ideo= logical demand. There has been no scientific, peer-reviewed study of whether the 8 gener= atives really made a living for anyone already funded; it's one of those= anecdotal things that a few people spread the memes, and it becomes an = urban legend. ____________________________________________________________ All is not lost! Click now for professional data recovery. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLygKNVW1HREvNOugCwPyN= MUs5PLdtGtWcrNSmwzGnPBZITpGTbdm/ From dcolivares@gmail.com Mon Feb 23 09:09:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432F83A698F for ; Mon, 23 Feb 2009 09:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.766 X-Spam-Level: X-Spam-Status: No, score=-3.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jigSrKfhc+V for ; Mon, 23 Feb 2009 09:09:32 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id D65173A6874 for ; Mon, 23 Feb 2009 09:09:31 -0800 (PST) Received: by fxm11 with SMTP id 11so1972966fxm.13 for ; Mon, 23 Feb 2009 09:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8hfz/LqX1+uWecKo5y6GFg8zuZ+kQB2pD5+/vr37oSI=; b=bQhirNkx3dEOv3XQXrb90tT18tBmY97OfU9Wr8h3d6OL8+R/bemztT63699qGX2iTi q91baU+gu7+3XljXVttSMAnfoQ9zws+I119hbZmgCYdw7Nv3DzVbJdlrSq0AI1Gn5teQ usNhGMcIjTv+niRc/1w5nqqUR/AKgAfh/lI3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jp2AV1nFVKQCYZpBKELqBqiNtumec7M5Etl82YwuC9cRArNfOakg8e3AsRa9xnekNL 0M+ynJZWRykyYI1GTNxorxgK4sVenTotJ5jpLiNe2cQSjg0wJCvLw5KrN1xmqLcGLWy+ 6yfAAOl1UdhY+Z3yanuMwrIL1sJ/735plMSBs= MIME-Version: 1.0 Received: by 10.103.214.8 with SMTP id r8mr3495221muq.6.1235408988958; Mon, 23 Feb 2009 09:09:48 -0800 (PST) In-Reply-To: <20090223.113041.5499.0@webmail09.vgs.untd.com> References: <20090223.113041.5499.0@webmail09.vgs.untd.com> Date: Mon, 23 Feb 2009 12:09:48 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:09:33 -0000 This letter is an example of a False Dilemma logical fallacy.(http://www.nizkor.org/features/fallacies/false-dilemma.html) "Either there must be a mandate to protect content, or nobody will protect content", when in fact, people will protect content based on their business model, not by some arbitrary mandate. Some will require contracts for interoperability that state that content protection metadata must be honored. Bringing up OpenSim with regards to this is also purely a 'Poisioning of the Well' logical fallacy. "OpenSimulator is Lennist, therefore it's wrong" (http://www.nizkor.org/features/fallacies/poisoning-the-well.ht= ml) Best Regards Dan On Mon, Feb 23, 2009 at 11:30 AM, dyerbrookme@juno.com wrote: > with mandating what choices VW providers make. Nothing wrong with > putting a field in the asset metadata for permissions stuff, but it > definitely should NOT be a mandatory part of the standard. > > It's absolutely about choice. Stripping DRM out as a mandate and removing= the mandate is not choice, but a forced march, under the guise that the ma= ndate would remove choice. In fact, the receiving grid has the choice not t= o hook up to such grids that have these requirements and it can also defeat= them, and then signal to those who care that it is not trustworthy; that s= hould be at the heart of what trustworthy means. Why is the onus only on th= e sending grid? Collective security isn't about one wild grid getting to de= feat the business requirements of all the others under the false flag of ch= oice, it's about collective security; the wild grid can keep its wild DRM-l= ess regime on its own server with its own sandboxers. OpenSim says the oppo= site, make a silo of permissions on one server as a module, thereby negatin= g commerce as a premise to the architecture. > > ____________________________________________________________ > Switch to the thrill of high speed internet for $19.95/mo with AT&T > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEs5PjpChbas9zvDZy3dlMm= vxUDX7C8QybUtHYlw74vEVquQpBJcP/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From dyerbrookme@juno.com Mon Feb 23 09:43:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119213A6AFD for ; Mon, 23 Feb 2009 09:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKmdBY0Qv98E for ; Mon, 23 Feb 2009 09:43:22 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 47C0B3A67DD for ; Mon, 23 Feb 2009 09:43:22 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail16.vgs.untd.com [10.181.12.156]) by smtpout03.vgs.untd.com with SMTP id AABE4F2BWAAJ2H22 for (sender ); Mon, 23 Feb 2009 09:43:16 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNcuwRU7BexcFIk0/5VgLx5g== Received: (from dyerbrookme@juno.com) by webmail16.vgs.untd.com (jqueuemail) id N94SSTEK; Mon, 23 Feb 2009 09:43:11 PST Received: from [68.161.198.3] by webmail16.vgs.untd.com with HTTP: Mon, 23 Feb 2009 17:42:15 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 17:42:15 GMT To: dcolivares@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.124215.6321.0@webmail16.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:1:411459876 X-UNTD-Peer-Info: 10.181.12.156|webmail16.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:43:23 -0000 Fisking and Nizkorisms may be tactics used on MMORPG forums and the IRC = channel, but in the real world when somebody poisons the well, it's poi= soned, whether or not the logical positivists believe it to be true, and= alerting a group project of the "poison" is beneficial, not rhetoricall= y fallacious. Yes, there must be a mandate to protect content, or the fa= lse hypothesis that everyone then has choice when it isn't mandated will= hold true -- speaking of false hypotheses. Those who don't want c/m/t c= an either not connect, or check off c/m/t on full perms. I'm glad we've established that OpenSim is Leninist, though, that's prog= ress : ) Prokofy Neva ____________________________________________________________ 30 Seconds can save a lifetime. Get it done. Its never been easier. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTQcxKVpPVsInGwV4kaJM21= nNhUM1Ho63hKvtROqoeuXuyQpNFBW8Y/ From dcolivares@gmail.com Mon Feb 23 09:44:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379453A6AFA for ; Mon, 23 Feb 2009 09:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThfZ6YXZ+qf4 for ; Mon, 23 Feb 2009 09:44:34 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id B8CFF3A67DD for ; Mon, 23 Feb 2009 09:44:33 -0800 (PST) Received: by fxm11 with SMTP id 11so2010513fxm.13 for ; Mon, 23 Feb 2009 09:44:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eO+0OGXfCvEW3TA4+PkD866E428CTlnqxDO9wS5RqKQ=; b=RxHlkTFErtX/PKqlGHIwNYHxbFN3/Wk+thTOwOCzt03xboC+nUQlIXwxe6iOVKtVpc 3YFO6TbWQZfyDaY1Kcjl0fM6sJZpRo1T3LVmKMIcZs0n2pDvlYO6p3BzR7rKj5Di7JRy Oym7y0iFdWYg+KYOMovLeJ81nfdmj3iyTdyKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MJ6JTvoM9LUjchyx4hxAwVdnw6CLXo8zpflo5asNu9nMnI8yADhZIRfItubomaPbk6 6ZldVpeStVDicL2AK0dMWEROfOnC/J4Bm9C75kzHM+9uuKslYDqTBDFE38akR9Kl+5SZ zEO+0yYaqzcUaW0GpQw/dF0gKpbe/NMUSb6ok= MIME-Version: 1.0 Received: by 10.103.137.12 with SMTP id p12mr1576843mun.94.1235411090099; Mon, 23 Feb 2009 09:44:50 -0800 (PST) In-Reply-To: <20090223.114423.5499.2@webmail09.vgs.untd.com> References: <20090223.114423.5499.2@webmail09.vgs.untd.com> Date: Mon, 23 Feb 2009 12:44:49 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:44:35 -0000 Theres another datapoint to add to this. As far as I know, the only other effort within the IETF with regards to content protection was a working group called ietf-idrm which was chartered to come up with a universally acceptable DRM scheme. It had some big names including: Eberhard Becker, University of Dortmund Dan Boneh, Stanford University Karlheinz Brandenburg, Fraunhofer Institute for Integrated Circuits Leonardo Chiariglione, CSELT Drew Dean, Xerox PARC Joan Feigenbaum, Yale University Edward Felten, Princeton University Yair Frankel, eCash Technologies Markus Jakobsson, Bell Labs Paul Kocher, Cryptography Research John Manferdelli, Microsoft Research Kevin McCurley, IBM Research Moni Naor, Weizmann Institute Fabien Petitcolas, Microsoft Research Pamela Samuelson, University of California, Berkeley Hal Varian, University of California, Berkeley Moti Yung, CertCo Unfortunately, it was shut down in 2003 because nobody could agree(http://www.pairlist.net/pipermail/ietf-idrm/2003-February.txt ) and eventually it became dormant. From a cursory glance, the archives seem to say that DRM means different things to different people, and seems to be one of those topics where 'you can't please everyone'. It also seems to state that usually, today, DRM schemes are 'licensed' technology and not 'standardized' because this allows them to be a 'black box'. In any case, it might be useful to look at the arguments from that RG( Archive: http://www.pairlist.net/pipermail/ietf-idrm/ ) and see how we can avoid a similar fate. Best Regards Dan On Mon, Feb 23, 2009 at 11:44 AM, dyerbrookme@juno.com wrote: >>My model can coexist with copyright-based models, provided I can > opt my content out of any DRM system. > > With a DRM system like c/m/t being conveyed, you check off c/m/t if you w= ant full perms to be distributed *shrugs*. That's all. Transporting the met= adata of c/m/t -- or no c/m/t and demanding a regime to implement it does n= ot preclude you from "opting out" by...checking off c/m/t. Why would you th= ink that the act of having to check off c/m/t to get full perms, so that ot= hers who *do not* want to check them off and wish to make a living not thro= ugh consulting but by object sales would somehow preclude your full-perms d= istribution? Makes no sense, again, except as an ideological demand. > > There has been no scientific, peer-reviewed study of whether the 8 genera= tives really made a living for anyone already funded; it's one of those ane= cdotal things that a few people spread the memes, and it becomes an urban l= egend. > > ____________________________________________________________ > All is not lost! Click now for professional data recovery. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLygKNVW1HREvNOugCwPyNM= Us5PLdtGtWcrNSmwzGnPBZITpGTbdm/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From dyerbrookme@juno.com Mon Feb 23 09:45:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA6E3A6B16 for ; Mon, 23 Feb 2009 09:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfxTF9Knv9tj for ; Mon, 23 Feb 2009 09:45:55 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 4F6BF3A6AFA for ; Mon, 23 Feb 2009 09:45:55 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail16.vgs.untd.com [10.181.12.156]) by smtpout03.vgs.untd.com with SMTP id AABE4F2FPARGSVLA for (sender ); Mon, 23 Feb 2009 09:45:17 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNfB9/taeupQWrsRkx7xQqtQ== Received: (from dyerbrookme@juno.com) by webmail16.vgs.untd.com (jqueuemail) id N94SUSYQ; Mon, 23 Feb 2009 09:44:16 PST Received: from [68.161.198.3] by webmail16.vgs.untd.com with HTTP: Mon, 23 Feb 2009 17:43:22 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 17:43:22 GMT To: gareth@litesim.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.124322.6321.1@webmail16.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:3004294952 X-UNTD-Peer-Info: 10.181.12.156|webmail16.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:45:56 -0000 >2 - My current favourite author makes a living through creative commons licensed sci-fi novels, so yes - you can make a living without a copyright monopoly, but that brings me back to point 1 Anecdotes and urban legends have no place in a scientific project. There is no peer-reviewed scientific study proving that using the CC reg= ime or offering everything full perms everywhere helps you make a living= if you are not already subsidized by the state or private sector. ____________________________________________________________ Get the word out. Click here for professional brochure production! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTMQB83rtK9qCxy3deU5HJV= Bw4Zb4ShApzHbIu54U497WrtC2P53Xq/ From dcolivares@gmail.com Mon Feb 23 09:49:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4483A6A76 for ; Mon, 23 Feb 2009 09:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AL8op-CGGJXc for ; Mon, 23 Feb 2009 09:49:11 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by core3.amsl.com (Postfix) with ESMTP id 51F7F3A6818 for ; Mon, 23 Feb 2009 09:49:11 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so1548692fkf.5 for ; Mon, 23 Feb 2009 09:49:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+49QAvIjNwXGhofcyBXUjlBrllnkrhe+781hjkE41Zw=; b=UKoSmROb03U1A0ZKMANHmxx2LixNyYee14864FqansfQAZg2NxtgQABPM3ji83xC6s d/imd+NQy7bBxwPffwqpzQ2FPyBw1FwEdHG9yLZwXf6EfadL1opbTp7ekknrx8Bp8DYk btBMIugzb5D0o0+9AtoqUF8we3Qpf83X0oiyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jf8bPkHyYdcXCoG+uIyNq//rbzINIEyTsQHtCrNl2hO7XJVmflBBMIY2CegnPO/uNg UzqBkremjmGuJu+F2qoAlf2HN/QMhUEc8DlPXjmEkHUBxSChed1reoc34LqNWeNeOLs9 mW8YzqlJcZxD5qFNUf/CI2FF9FK08UBSgxWB0= MIME-Version: 1.0 Received: by 10.103.223.2 with SMTP id a2mr3536974mur.4.1235411367433; Mon, 23 Feb 2009 09:49:27 -0800 (PST) In-Reply-To: <20090223.124215.6321.0@webmail16.vgs.untd.com> References: <20090223.124215.6321.0@webmail16.vgs.untd.com> Date: Mon, 23 Feb 2009 12:49:27 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 17:49:12 -0000 Actually, 'poisoning the well' is *ALWAYS* fallatious. You can't make the claim, "OpenSim believes this, so this must be bad". "I'm glad we've established that OpenSim is Lennist" is an example of an 'Ad Hominem Abusive' logical fallacy ( http://www.nizkor.org/features/fallacies/personal-attack.html ) Are you going to continue to debate using logical fallacies and debating the 'person' instead of the idea and then making personal attacks against them on your blog in an effort to bully them into being quiet? Best Regards Dan On Mon, Feb 23, 2009 at 12:42 PM, dyerbrookme@juno.com wrote: > Fisking and Nizkorisms may be tactics used on MMORPG forums and the IRC c= hannel, but in the real world when somebody poisons the well, it's poisone= d, whether or not the logical positivists believe it to be true, and alerti= ng a group project of the "poison" is beneficial, not rhetorically fallacio= us. Yes, there must be a mandate to protect content, or the false hypothesi= s that everyone then has choice when it isn't mandated will hold true -- sp= eaking of false hypotheses. Those who don't want c/m/t can either not conne= ct, or check off c/m/t on full perms. > > I'm glad we've established that OpenSim is Leninist, though, that's progr= ess : ) > > Prokofy Neva > > > ____________________________________________________________ > 30 Seconds can save a lifetime. Get it done. Its never been easier. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTQcxKVpOGoB1o1RAtOTItCB= A6o2R7XJQNyJDBPA6ld3hxrMAnHGEY/ > From dcolivares@gmail.com Mon Feb 23 10:04:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77C6F3A6818 for ; Mon, 23 Feb 2009 10:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.807 X-Spam-Level: X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUUr-vF3lagF for ; Mon, 23 Feb 2009 10:04:13 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 468FB3A6359 for ; Mon, 23 Feb 2009 10:04:13 -0800 (PST) Received: by fxm11 with SMTP id 11so2032264fxm.13 for ; Mon, 23 Feb 2009 10:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rAyngsruexf9SN8qvP4pLadwr0ZQVJ8ii0eyInJDUno=; b=bm7kqEWDZIfSzRi0QfQOmgFWeJaItfme4LJnzlVRb9YvJcFDc7Y6QWVpAkkKcKxAC/ OUsWzlcW1fkBJQleVxf8wvpHlnOn1zffwJXM/YN51S/meAADF/vOCrEQrX4tFCqgJCLj DIAV1GeGwgXRf8213WsxWbqnNzUiTb6etBl2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=njHIA6OWKQHXkwHoZyTS7hhARFwKncffq2+hzXPcnbeFdbvusC1hus0vlbEoBfSQFn uyBpI1BcHWXcGp8iB0jrgIwELtPjkNQoB/0AyiPlsoEbn4D2JKs9e33vMmQJ1Y50ZQDi 6jJzlXyJxZgA9EEQkJida7UV7iflpXNCCFDvQ= MIME-Version: 1.0 Received: by 10.103.171.20 with SMTP id y20mr3539840muo.19.1235412269838; Mon, 23 Feb 2009 10:04:29 -0800 (PST) In-Reply-To: <20090223.124322.6321.1@webmail16.vgs.untd.com> References: <20090223.124322.6321.1@webmail16.vgs.untd.com> Date: Mon, 23 Feb 2009 13:04:29 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:04:14 -0000 Gareth, Can you post relevant links and the author's name and book title to demonstrate (to Prokofy) that there is at least one case where someone had made a living based on a Creative Commons License? When making claims, it's important to reference the evidence so that other people cannot refute it without making logical fallacies that can be pointed out. Best Regards Dan On Mon, Feb 23, 2009 at 12:43 PM, dyerbrookme@juno.com wrote: >>2 - My current favourite author makes a living through creative > commons licensed sci-fi novels, so yes - you can make a living without > a copyright monopoly, but that brings me back to point 1 > > Anecdotes and urban legends have no place in a scientific project. > > There is no peer-reviewed scientific study proving that using the CC regime or offering everything full perms everywhere helps you make a living if you are not already subsidized by the state or private sector. > > ____________________________________________________________ > Get the word out. Click here for professional brochure production! > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTMQB83rtK9qCxy3deU5HJVBw4Zb4ShApzHbIu54U497WrtC2P53Xq/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From gareth@litesim.com Mon Feb 23 10:41:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7DE3A68B8 for ; Mon, 23 Feb 2009 10:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzTDbAZkEOWb for ; Mon, 23 Feb 2009 10:41:31 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.153]) by core3.amsl.com (Postfix) with ESMTP id 0E1F83A6872 for ; Mon, 23 Feb 2009 10:41:31 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6885418poe.4 for ; Mon, 23 Feb 2009 10:41:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.139.3 with SMTP id m3mr2153870rvd.77.1235414508323; Mon, 23 Feb 2009 10:41:48 -0800 (PST) In-Reply-To: References: <20090223.124322.6321.1@webmail16.vgs.untd.com> Date: Mon, 23 Feb 2009 18:41:48 +0000 Message-ID: <61dbdd7d0902231041y5676364dp706d6e342eedb5c1@mail.gmail.com> From: Gareth Nelson To: Dan Olivares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:41:32 -0000 Sure, Cory Doctrow His site is craphound.com and you can get all his work there for free online or order a printed copy. On Mon, Feb 23, 2009 at 6:04 PM, Dan Olivares wrote: > Gareth, > > Can you post relevant links and the author's name and book title to > demonstrate (to Prokofy) that there is at least one case where someone > had made a living based on a Creative Commons License? When making > claims, it's important to reference the evidence so that other people > cannot refute it without making logical fallacies that can be pointed > out. > > Best Regards > > Dan > > On Mon, Feb 23, 2009 at 12:43 PM, dyerbrookme@juno.com > wrote: >>>2 - My current favourite author makes a living through creative >> commons licensed sci-fi novels, so yes - you can make a living without >> a copyright monopoly, but that brings me back to point 1 >> >> Anecdotes and urban legends have no place in a scientific project. >> >> There is no peer-reviewed scientific study proving that using the CC regime or offering everything full perms everywhere helps you make a living if you are not already subsidized by the state or private sector. >> >> ____________________________________________________________ >> Get the word out. Click here for professional brochure production! >> http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTMQB83rtK9qCxy3deU5HJVBw4Zb4ShApzHbIu54U497WrtC2P53Xq/ >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > From dyerbrookme@juno.com Mon Feb 23 11:09:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CEF63A69DA for ; Mon, 23 Feb 2009 11:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSQITjYCxAWk for ; Mon, 23 Feb 2009 11:09:10 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 5B7F03A68B8 for ; Mon, 23 Feb 2009 11:09:10 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail03.vgs.untd.com [10.181.12.143]) by smtpout04.vgs.untd.com with SMTP id AABE4F7BYAY4ETBJ for (sender ); Mon, 23 Feb 2009 11:08:38 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNb94d+PCkmUaN1OSPwR4fzg== Received: (from dyerbrookme@juno.com) by webmail03.vgs.untd.com (jqueuemail) id N94XNC7H; Mon, 23 Feb 2009 11:08:08 PST Received: from [68.161.198.3] by webmail03.vgs.untd.com with HTTP: Mon, 23 Feb 2009 19:07:36 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 19:07:36 GMT To: dcolivares@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.140736.24438.0@webmail03.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:4148595917 X-UNTD-Peer-Info: 10.181.12.143|webmail03.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:09:11 -0000 Dear Dan, "Ad hominem" ("to the man") refers to people, not software programs or p= latforms. Criticism of software concepts or people's ideas isn't an "ad = hominem" attack; labelling perjoratively isn't even an "ad hominem" atta= ck. Even if this can somehow be construed as a "violation," there's been= any number of such acts already on this list, that met with your silenc= e. Ultimately *you're* the one the characterized OpenSim as "Leninist"; = I tend to agree, given the absence of protections of IP and the rigid co= nceptions about how the Metaverse must be organized with collectivizatio= n. = As for "logical fallicies," yes, there's always the risk of being kicked= off the Latin boys' school debate team for violations of these sorts of= arcane rhetoric rules. But, commonsense can prevail nevertheless and yo= u can have a normal conversation urging technologists not to sneak ideol= ogical prescriptions into the protocols. As for bullying, your effort to= invoke the boys' school rules would be characterized as just that. = It's important not to weld worldviews into the code and into the interop= erability in advance, whether Leninism, militarism, or any "ism". There = should be authentic diversity and choice, and not a forced march to tech= nocommunism. Virtual worlds need to be sustained by commerce, and commer= ce is sustained by property rights. Private property rights in general a= nd specifically intellectual property rights are ok; they are not wrong,= they enable people to make a living, including technology vendors. Copy= leftism and collectivism are only one ideology for the Internet, and can= 't be the only one. Since there are a number of "Dan Olivares" on the Internet, could you ex= plain which one you are? Prokofy Neva ____________________________________________________________ Click here to save cash and find low rates on auto loans. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLaW0FYMjWhFUjLaV0gAMu= avgDTXgbYSdN85xrhA3CrEcy6vcRaoQ/ From dyerbrookme@juno.com Mon Feb 23 11:16:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED723A6784 for ; Mon, 23 Feb 2009 11:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.402 X-Spam-Level: X-Spam-Status: No, score=-2.402 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hUO2xJi84UN for ; Mon, 23 Feb 2009 11:16:58 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 55F4C3A6872 for ; Mon, 23 Feb 2009 11:16:58 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail03.vgs.untd.com [10.181.12.143]) by smtpout03.vgs.untd.com with SMTP id AABE4F7S8AJ3YCGJ for (sender ); Mon, 23 Feb 2009 11:16:46 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNrempdTfUU/w0FqON3/I2dw== Received: (from dyerbrookme@juno.com) by webmail03.vgs.untd.com (jqueuemail) id N94X4KWX; Mon, 23 Feb 2009 11:15:54 PST Received: from [68.161.198.3] by webmail03.vgs.untd.com with HTTP: Mon, 23 Feb 2009 19:15:01 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 19:15:01 GMT To: dcolivares@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.141501.24438.1@webmail03.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 3:5:973034630 X-UNTD-Peer-Info: 10.181.12.143|webmail03.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:16:59 -0000 >Can you post relevant links and the author's name and book title to demonstrate (to Prokofy) that there is at least one case where someone had made a living based on a Creative Commons License? When making claims, it's important to reference the evidence so that other people cannot refute it without making logical fallacies that can be pointed out. Paging Nizkor! Sounds like arguing a generality from a specific with no = basis! As I've already noted, anecdotal stories about people selling consulting= services on top of their opensourced wares or giveaways on CC can be co= llected (a kind of obfuscation), like that case of that guy in Africa wh= o put his book up for free on the Internet and still sold it (tip jar) b= ut none of this is a peer-reviewed, exhaustive scientific study with a r= epresentative sample and real field testing. Posting "one case" or even = "20 cases of my close, personal friends" is not a scientific study. Ther= e is no rigorous study that says that CC licenses enable people not alre= ady subsidized by government or private grants or by corporate payrolls = actually "make a living". Most people who put up content for free with a= CC license get credit, but don't get cash. That's because CC doesn't ha= ve a c/m/t management system and micropayment system like a virtual worl= d can. Therefore, following the CC cashless name credit-only formula isn= 't one that can sustain an economy, it can only sustain a collective whe= re people are subsidized elsewhere. Raise your hands on this list if you are able to make your living entire= ly by putting up free digital content on the Internet, giving it away fo= r free, and selling your "customization" or "consulting" on top of that.= Meanwhile, we have the reality of SL, where the economic statistics of p= eople who can make a living from selling content and services with digit= al rights and intellectual property protection, number in the thousands.= So rather than chase after the chimera of the CC license, which is mere= ly a browbeating and a tip jar for most people, whatever it is for those= few cases, let's look at where we have hard field information. = Prokofy Neva ____________________________________________________________ Purify your water with professional water treatment. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTK8PIyWUL0MIpqjOEaMCOc= oqeQyRAOfiRm8KglFpMcZdsq0eWDeEI/ From dyerbrookme@juno.com Mon Feb 23 11:23:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39C2028C0FA for ; Mon, 23 Feb 2009 11:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSo3pSw0HnFf for ; Mon, 23 Feb 2009 11:23:14 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 2B57528C0FF for ; Mon, 23 Feb 2009 11:21:37 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail03.vgs.untd.com [10.181.12.143]) by smtpout02.vgs.untd.com with SMTP id AABE4F722AYNSBJS for (sender ); Mon, 23 Feb 2009 11:20:56 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkN+XWVyl6vCcbxZ5x5FDfOkQ== Received: (from dyerbrookme@juno.com) by webmail03.vgs.untd.com (jqueuemail) id N94YDEGQ; Mon, 23 Feb 2009 11:20:43 PST Received: from [68.161.198.3] by webmail03.vgs.untd.com with HTTP: Mon, 23 Feb 2009 19:19:33 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 19:19:33 GMT To: gareth@litesim.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.141933.24438.2@webmail03.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 1:1:1597145447 X-UNTD-Peer-Info: 10.181.12.143|webmail03.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:23:15 -0000 Cory Doctorow is a leading ideological proponent of copyleftism and the = CC shill. He does not make his living solely from giving away his books.= He has lecture fees and consulting fees. Furthermore, he sends his book= s off to be typed and keyed into digital form for slave-wages to India -= - that's part of the recipe. = The Cory Doctorow model is not one that can work for everyone in an econ= omy, nor can it work for everyone who creates digital content, nor shoul= d it have to be imposed. It is one choice, and those who make it should = be aware that a) they are in a tiny niche b) their theories are never te= sted by their actual making an entire sustainable living off the theory;= c) they cannot impose that on everybody in a digital economy in a virtu= al world. Copyleftist CC theorists, like Doctorow or Lessig, who bring i= n salaries as lecturers and consultants, are the last people who can rea= lly prove that they've made their living from giving away digital conten= t as they are paid in cash to talk in the atomic world. ____________________________________________________________ Make sure your shower gets you clean. Click now for a high quality showe= r filter! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTGczukxGxf0bv1xcbRa0Lk= C3eXbDedokFHadGyOufgxZRTD5q5FIE/ From gareth@litesim.com Mon Feb 23 11:27:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E623A694A for ; Mon, 23 Feb 2009 11:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzn++6EFsaUp for ; Mon, 23 Feb 2009 11:27:32 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.159]) by core3.amsl.com (Postfix) with ESMTP id 66AC83A68FE for ; Mon, 23 Feb 2009 11:27:32 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so6933150poe.4 for ; Mon, 23 Feb 2009 11:27:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.134.10 with SMTP id h10mr2151246rvd.287.1235417269452; Mon, 23 Feb 2009 11:27:49 -0800 (PST) In-Reply-To: <20090223.141933.24438.2@webmail03.vgs.untd.com> References: <20090223.141933.24438.2@webmail03.vgs.untd.com> Date: Mon, 23 Feb 2009 19:27:49 +0000 Message-ID: <61dbdd7d0902231127q3af0ef7ds436732d2f4953b15@mail.gmail.com> From: Gareth Nelson To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:27:33 -0000 My point was that he's living proof that you don't need a copyright monopoly to make money, but seriously - this is way out of scope for this list. I'd be happy to debate this in private email or on your blog, but it doesn't seem appropriate here. On Mon, Feb 23, 2009 at 7:19 PM, dyerbrookme@juno.com wrote: > Cory Doctorow is a leading ideological proponent of copyleftism and the C= C shill. He does not make his living solely from giving away his books. He = has lecture fees and consulting fees. Furthermore, he sends his books off t= o be typed and keyed into digital form for slave-wages to India -- that's p= art of the recipe. > > The Cory Doctorow model is not one that can work for everyone in an econo= my, nor can it work for everyone who creates digital content, nor should it= have to be imposed. It is one choice, and those who make it should be awar= e that a) they are in a tiny niche b) their theories are never tested by th= eir actual making an entire sustainable living off the theory; c) they cann= ot impose that on everybody in a digital economy in a virtual world. Copyle= ftist CC theorists, like Doctorow or Lessig, who bring in salaries as lectu= rers and consultants, are the last people who can really prove that they've= made their living from giving away digital content as they are paid in cas= h to talk in the atomic world. > > > ____________________________________________________________ > Make sure your shower gets you clean. Click now for a high quality shower= filter! > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTGczukpNeZJRzXkMERgo4AU= zfbygtre3OameS0rSCu27ydnCn5o0g/ > From dyerbrookme@juno.com Mon Feb 23 11:41:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81BB53A6A26 for ; Mon, 23 Feb 2009 11:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGuoohh0lRsB for ; Mon, 23 Feb 2009 11:41:49 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id A9EC73A69DF for ; Mon, 23 Feb 2009 11:41:49 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail03.vgs.untd.com [10.181.12.143]) by smtpout02.vgs.untd.com with SMTP id AABE4F88ZACPAETJ for (sender ); Mon, 23 Feb 2009 11:41:11 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNyFTuE/Jz1/SNdq7I6xByRg== Received: (from dyerbrookme@juno.com) by webmail03.vgs.untd.com (jqueuemail) id N94ZJHV5; Mon, 23 Feb 2009 11:40:59 PST Received: from [68.161.198.3] by webmail03.vgs.untd.com with HTTP: Mon, 23 Feb 2009 19:40:52 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 19:40:52 GMT To: gareth@litesim.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.144052.24438.3@webmail03.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:1827591717 X-MAIL-INFO: 5d83ba77ba877ecf87ef3377ef072a9f6e8ffeb3472ae31b2f1f43ab23a74bdb03fbba3ecf4a5abb5a87 X-UNTD-Peer-Info: 10.181.12.143|webmail03.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:41:50 -0000 Debating various economic systems and business models wouldn't fall into= the purview of this list if it weren't for the very pertinent fact tha= t interoperability precludes or allows forms of economic systems by affi= rming or denying intellectual property rights in the code. = Then the unspoken or espoused economic views of the coders matters a gre= at deal. If they all adhere to the copyleftist mode and claim that inser= ting c/m/t "breaks their business model" (although I don't see that it d= oes, as they can check off "yes" to c/m/t), and they impose that as they= only choice articulated in the tools that emerge from the code, then th= ey've foreclosed a Metaverse economy based on IP and micropayments. Or, not to limit ourselves to virtual worlds because interoperability co= nnects not only to VW platforms, let's take a story of how someone reall= y makes a living in the real world of real proprietary code who is not a= n anecdote, but typical of a software business: http://tech.yahoo.com/blogs/null/124073 Whatever the jailbreaks and rips, the i-phone is based on proprietary co= de. It admit various apps and those apps, too, are proprietary in many c= ases. This fellow gives away free games, but they are merely loss-leader= s to get customers to buy the closed-code game which is sold by the i-ph= one as closed close. So the interoperability that enabled all the widget= s or apps or whatever is still based on a proprietary code concept for b= oth the technology vendor and the user. If those who believed there shou= ld be no proprietary closed code prevailed on the production of the i-ph= one and its app economy for thousands of developers, there'd be no mobil= e app economy, now would there. That's because the option did not get fo= reclosed in development. If there's something I haven't understood about how i-phone and apps wor= k, enlighten me, but I think the analogy is sound. ____________________________________________________________ Click to compare and save on auto insurance. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTImHYq375zTIrqcaFxHEq6= W3NklESf7wPUL6Ue0CUnNJLMI3dUHvy/ From dcolivares@gmail.com Mon Feb 23 11:43:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B792B3A6A26 for ; Mon, 23 Feb 2009 11:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.791 X-Spam-Level: X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmNCPYJ0l7wb for ; Mon, 23 Feb 2009 11:43:48 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id A77D73A69DF for ; Mon, 23 Feb 2009 11:43:47 -0800 (PST) Received: by bwz5 with SMTP id 5so5121584bwz.13 for ; Mon, 23 Feb 2009 11:44:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=osfXwg+4hosIc0CN5AgMHtNgvejU3syKpqU151+p/Ow=; b=Uj8+f/ogKIBnQELSSltyNNWERYRxI/GKh3EdNkcEVRVjbKq0WvG9dhNcJghmQ9ghsX N5bgzxUUkqSTyu+cvRo2ylHvjfY0PFq9bypvSr3nIE+dwu9lrvSo6JY8CysqnZsyOhHr wziDoqMcx8tfJKb6o2HSrSvpDoy+mQL+hRCd0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Y9MO2rWFhnJRMGoaUel32Q2OufkWv2rTtSNrvfQHRXdLb3UfdHzVjkiw8Nodv5y3Ep VBDgmgD1o0W2LmdjJ8sddgaB2aosNSgYwaMCFIiRt3kYuCubSTTdITZHDHdRC7X9YZiB QeCHr1cDMmbrAEhRdcpyvrxvWQKdR+XK8KWMQ= MIME-Version: 1.0 Received: by 10.103.239.10 with SMTP id q10mr3663793mur.67.1235418243268; Mon, 23 Feb 2009 11:44:03 -0800 (PST) In-Reply-To: <20090223.140736.24438.0@webmail03.vgs.untd.com> References: <20090223.140736.24438.0@webmail03.vgs.untd.com> Date: Mon, 23 Feb 2009 14:44:03 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:43:49 -0000 logical fallicies are lapses in logic, they're not arcane rules in a debate team. If you will not argue logically, then your arguments are discredited by anyone who considers logical discussion to be important. Additionally, you commonly refer to OpenSim as being Lennist and communist. In this way you are referring to OpenSim as if it has beliefs and personifying it instead of simply being a group of developers with many different beleifs that have no real association to each other beyond 'making it better'. Therefore, it is logical to treat the arguments as Ad Hominem, or, perhaps an over generalization. "there's been any number of such acts already on this list, that met with your silence" Just because I didn't argue one specific comment doesn't make any other arguments wrong. That is also a logical fallacy. "As for bullying, your effort to invoke the boys' school rules would be characterized as just that.", once again, a logical fallacy. I'm disputing the logic of what you're saying, it has nothing to do with debate rules at all. To the contrary, there's significant evidence on this list and your blog that you are bullying the people on this list under the guise of journalistic integrity. Journalistic integrity requires *both* sides be presented as well as impartiality. You've made it expressly clear that you are not impartial. Therefore, it's not journalistic integrity. It's a personal blog and an opinion column. Additionally, you've made personal attacks in private e-mail that you've posted to your blog. "(Ref: Two Words: Facebook TOS, http://secondthoughts.typepad.com/second_thoughts/2009/02/mmox-moxie.html ). "There should be authentic diversity and choice, and not a forced march to technocommunism." Once again, a false dilemma logical fallacy( http://www.nizkor.org/features/fallacies/false-dilemma.html ). Business models will drive content protection, not an arbitrary 'forced' mandate that isn't applicable for worlds such as WoW that don't have user created content. (This was discussed in a previous e-mail in this series) "Virtual worlds need to be sustained by commerce, and commerce is sustained by property rights." In the Linden Lab user created content model. It is applicable in many cases but not, for example WoW (no user created content). "Private property rights in general and specifically intellectual property rights are ok; they are not wrong, they enable people to make a living, including technology vendors." Agreed, there is nothing wrong with property rights in general, and, I'm arguing that business models enable people to make a living. If those business models include IP protection, then the content will be protected. " Copyleftism and collectivism are only one ideology for the Internet, and can't be the only one." Agreed, I didn't say that there was only one, just that they should not be mandated because they do not apply everywhere. I'm arguing the use of the keyword MUST instead of MAY. "Since there are a number of "Dan Olivares" on the Internet, could you explain which one you are?" The only reason for this question is to try to argue 'me' instead of my ideas, try to discredit me based on my credentials instead of my arguments, or otherwise find a way to publically and vindictively attack me or my ability to work. Therefore, I once again, urge you to debate the idea, and not the person. Best Regards Dan Olivares On Mon, Feb 23, 2009 at 2:07 PM, dyerbrookme@juno.com wrote: > Dear Dan, > > "Ad hominem" ("to the man") refers to people, not software programs or pl= atforms. Criticism of software concepts or people's ideas isn't an "ad homi= nem" attack; labelling perjoratively isn't even an "ad hominem" attack. Eve= n if this can somehow be construed as a "violation," there's been any numbe= r of such acts already on this list, that met with your silence. Ultimately= *you're* the one the characterized OpenSim as "Leninist"; I tend to agree,= given the absence of protections of IP and the rigid conceptions about how= the Metaverse must be organized with collectivization. > > As for "logical fallicies," yes, there's always the risk of being kicked = off the Latin boys' school debate team for violations of these sorts of arc= ane rhetoric rules. But, commonsense can prevail nevertheless and you can h= ave a normal conversation urging technologists not to sneak ideological pre= scriptions into the protocols. As for bullying, your effort to invoke the b= oys' school rules would be characterized as just that. > > It's important not to weld worldviews into the code and into the interope= rability in advance, whether Leninism, militarism, or any "ism". There shou= ld be authentic diversity and choice, and not a forced march to technocommu= nism. Virtual worlds need to be sustained by commerce, and commerce is sust= ained by property rights. Private property rights in general and specifical= ly intellectual property rights are ok; they are not wrong, they enable peo= ple to make a living, including technology vendors. Copyleftism and collect= ivism are only one ideology for the Internet, and can't be the only one. > > Since there are a number of "Dan Olivares" on the Internet, could you exp= lain which one you are? > > Prokofy Neva > > > ____________________________________________________________ > Click here to save cash and find low rates on auto loans. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLaW0ItE7NIpRQMxMyaPEML= 2nrpxe8l8KdAGHmPnDwHSR7izk4R8U/ > From lenglish5@cox.net Mon Feb 23 11:48:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B84028C11B for ; Mon, 23 Feb 2009 11:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.822 X-Spam-Level: X-Spam-Status: No, score=0.822 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuOkxumrsXDM for ; Mon, 23 Feb 2009 11:48:54 -0800 (PST) Received: from fed1rmmtao105.cox.net (fed1rmmtao105.cox.net [68.230.241.41]) by core3.amsl.com (Postfix) with ESMTP id 6816F28C108 for ; Mon, 23 Feb 2009 11:48:54 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090223194912.CATJ15318.fed1rmmtao105.cox.net@fed1rmimpo03.cox.net>; Mon, 23 Feb 2009 14:49:12 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id KXpC1b0054N6T0Q04XpC90; Mon, 23 Feb 2009 14:49:12 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=usaWIZ2Y7unoK2YyCWwA:9 a=lcFPlNg3FBQCKDknd-UA:7 a=63be-goPFbLaP1xvPIvUH1hORFwA:4 a=QMgMR9M9BAsA:10 X-CM-Score: 0.00 Message-ID: <49A2FDB8.7000303@cox.net> Date: Mon, 23 Feb 2009 12:49:12 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jesrad References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> <61dbdd7d0902230537n20f86856i8b392a80b1740bc0@mail.gmail.com> <53cd6c2e0902230559g73aa66e3u4026f34b95ec215@mail.gmail.com> In-Reply-To: <53cd6c2e0902230559g73aa66e3u4026f34b95ec215@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:48:55 -0000 Jesrad wrote: > This amounts to an implementation of some DRM, if I understand it > correctly. Would it be part of the protocol that grids are to > machine-read it and enforce it ? I would guess so if there is also a > section of the protocol addressing asset exchange. In this case the > problem is still more complex than anticipated (how do I restrict next > owner or next grid from restricting next owner or grid from > grid-exchanging the asset, etc.) > > Nevertheless, the entire issue is avoided by keeping content hosted in > its original grid, and the renderview being supplied by multiple > sources (according to the endpoint identity's credentials, if required > by the source grid implementation). Isn't it ? > Just how many separately hosted grids/asset servers are we talking about here? And how many assets? SL, sorry to keep bringing it up, but its an important usecase, has 20,000 simulators and some ludicrous number of "assets" to deal with. If there's no local caching of assets on any other grid, permissions allowing, then the SL servers would be expected to be asset server to the metaverse and they already groan under the strain of talking to the limited SL world. The metaverse is projected to become 100-100x larger than Secondlife. the AWG's original mission was to try to desing a SL-like meta-grid that would handle such "scary numbers." We can't just handwave the issues away and suggest that existing systems and architectures will "just do it" in some way. Permissions/digital rights of SOME kind is required for any asset that isn't identified as Creative Commons" and even there, a CC license can vary quite a bit. there's a ccREL (rights expression language) defined just to identify variations of the Creative Commons license, and CC is NOT enough to handle all the possible needs for digital rights. L From dcolivares@gmail.com Mon Feb 23 11:58:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E240628C16A for ; Mon, 23 Feb 2009 11:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.401 X-Spam-Level: * X-Spam-Status: No, score=1.401 tagged_above=-999 required=5 tests=[AWL=-4.357, BAYES_00=-2.599, FM_GOOD_ENF_CREDIT=10.357, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86NLCSzGisII for ; Mon, 23 Feb 2009 11:58:00 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 9C4313A67E2 for ; Mon, 23 Feb 2009 11:57:35 -0800 (PST) Received: by fxm11 with SMTP id 11so2147070fxm.13 for ; Mon, 23 Feb 2009 11:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9o0JtUwt9bgGIZuCRiUFWpooWP2L6nojfNyHazj7vK0=; b=d4C3lLifNwEXll3JeyPiur6vJ9h1bD43z/rrUCKH309upLeIAmEznLl+mXci4x4BjB vWIhxVQxVvJPFLAjCGa3uHIcGO2PrIW7ZkPLOW51RBydgJvBo/El9fJya1Hn4UK8iaRA KRyWBbXrxdckuPbfnN19xhKJsZ+vd7HR8YHB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=U9rHEdaDFt5IW5k0EFr9Kz/MBwcNQgb0UmrkmhDPWh3ymkgSDpiGqcExVwdbAjdddS uAJ3qznOqt87/ICM6hI/wYFTKRj0bEkZbEiFI8xEhwbqksffNysLlFmTcDrMCHjandoT XmWq1dp10dd6lDow+9Gcyk/bs2aOev7Tz8isQ= MIME-Version: 1.0 Received: by 10.102.234.18 with SMTP id g18mr3677671muh.102.1235419071663; Mon, 23 Feb 2009 11:57:51 -0800 (PST) In-Reply-To: <20090222.064951.5324.0@webmail15.vgs.untd.com> References: <20090222.064951.5324.0@webmail15.vgs.untd.com> Date: Mon, 23 Feb 2009 14:57:51 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 73 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 19:58:03 -0000 A few arguments that need discussing in the last letter; "Linden Lab will not design a system that lets people openly violate the permissions of SL goods and take them to other worlds. We recognize that intellectual property is the engine that drives Second Life, and we are completely committed to preserving the qualities that make Second Life the unique, innovative and dynamic place that it is today." Your interperetation of this statement is simply your interpretation. My interperetation is, "We acknowledge that intellectual property is important in secondlife and we'll do what we can to protect it.". It also leaves them a liability protection disclaimer for people who violate IP that Linden Lab has not discovered. As a company, they need to provide themselves that to protect from being sued. As other people and yourself have said, most components of the current permission system of easily bypassed by people who have a strong interest in doing so (Ref: Second Inventory, Copybot, etc). >>TLS is _the_ standard used to protect your credit card numbers and it's = perfectly legitimate within the context of a TLS protected message stream = to NOT USE ANY ENCRYPTION WHATSOEVER!!!!!! >I'd like to hear a second opinion on this. When I see someone emotionally = all-capping and exclamation-pointing a proposition, I don't see science, I = see religion. Here's more evidence to confirm what Infinity is saying: http://en.wikipedia.org/wiki/Secure_Sockets_Layer >>so.. you want world of warcraft, penguin cafe, qwaq, there.com, sony >>home, eve online, osgrid, etc. to all use the second life permissions >>system instead of the one they made for their user base because you >>may one day want to use those worlds? >>good luck. "players of SL aren't clamouring to be able to make armour in SL and port it into WoW...oops, they can't do that because there is *no user generated content* in WoW " This would seem to argue against what you are saying. If there's no user generated content in WoW, then they also don't require a permission system. " Let me tell you two words: Facebook TOS. http://uk.reuters.com/article/technologyNewsMolt/idUKTRE51H6V820090218 " Once again, vailed threat with no evidence that Linden Lab will abandon the permission system. "People who implement virtual worlds software, like people who implement social media software, can no longer expect to do this in isolation, and without accountability to, those who they are making it *for*. The reason the call it virtual *world* is because *it's a world with people in it*. The reason they call it social media is because it's *social*. So you cannot develop in isolation from the stakeholders in these worlds and spaces. They are not mere customers you can hold at arm's length while you sell a product as a vendor; interoperability begins at home, between the platform provider and the users." People have developed software in the open for quite a few years now as is evidenced by the fact that anyone can join an IETF working group. All IETF standards have been this way. Additionally, you take part in this group. Open Source software development has always been open. Most accept patches from the general population and have mailing lists or internet chat rooms where the social and technical aspects of the work is discussed. So, I postulate that it isn't the social media that's been kept out. It's the social media that hasn't been interested. "Your "puzzlement" is typical of what I call the Geeks' Forced Migration Policy, as it implies: "If you don't like it, leave." Like America, "Love it or leave it". That's silly. Governance of software is not like an opensource project where you disagree and make a fork. That culture inhibits the free consensus that is needed for further development of the 3D Internet." - Over generalization. See the history of Apache and most other GPL licensed application. Yes, I have compared the rigid, arcane, extensive, oppressive rules and rituals and hive-mind humming of IETF as "like" BDSM culture in this regard: it puts you in the wrong at every turn. You can never understand *enough* about it. Journalists who try to report on it end up "scarred". They are always incorrect, and always needing yet more indoctrination. The atmosphere is not one of liberal democratic discourse, where one can agree or disagree or criticize or support, it's one in which there is only the double-plus-good promotion of the positive proposal and the "yes" vote and never a "no" vote. Whatever "necessity" there is about having this kind of culture to develop code or technical standards and I'm not sure in fact it's a necessity even there) it is not a necessity and is even an obstacle in the development of socialware, which ought to be the third thing after hardware and software in which the customer feedback, the laymen's concerns, are constantly incorporated as a matter of course, and not just tacked on at the end of the process. Whatever concerns you have with the IETF process, please contact them about it so the process can be improved upon. It really isn't subject matter for this working group Best Regards Dan On Sun, Feb 22, 2009 at 6:49 AM, dyerbrookme@juno.com wrote: >>I word my statements to provide the meaning in intend. when i say > "there are no protocols being considered by this group that would > REQUIRE the abandonment of the transport of permissions metadata," i > say it because there are, in fact, no protocols being considered by > this group that would REQUIRE the abandonment of the transport of > permissions metadata. What LL blog post are you talking about? Perhaps y= ou have me confused with someone else (enh. it's an easy mistake.) > > Transport of permissions metadata is not the same thing as implementing t= hose permissions on another grid. Do you get credit for having transported = the metadata if the other grid doesn't implement it? Will you not have as a= marker of trustworthyness of a grid its willingness to accept *and impleme= nt* metadata for permissions? > > No, Infinity. I don't have you confused with some other Linden. The blog = post is here: > http://blog.secondlife.com/2008/07/08/ibm-linden-lab-interoperability-ann= ouncement/ > > In it, we find *the only thing LL has ever said formally about its intent= ions on permissions*. It says: > > "Linden Lab will not design a system that lets people openly violate the = permissions of SL goods and take them to other worlds. We recognize that in= tellectual property is the engine that drives Second Life, and we are compl= etely committed to preserving the qualities that make Second Life the uniqu= e, innovative and dynamic place that it is today." > > It's corporate-speak. And while it says LL "will not design a system that= lets people openly violate the permissions" (hey, thanks!) it does *not* s= ay "LL will design a system that prevents people from violating the permiss= ions". Difference! You're committed? Great! Now could we hear the engineeri= ng plan for preserving that, er, dynamism involved in IP? > > I think it's a valid question to ask. After all, LL allowed its code to b= e reverse-engineered in 2006 despite a rule in the TOS that this was not al= lowed. > >>But yes, we won't be working on a protocol that mandates them UNLESS the= re is unanimous consent that all implementers want to transport > permissions metadata via OGP (or whatever we wind up calling it) and > there is unanimous consent that the second life model for permissions > metadata is appropriate for all implementors. > > This strikes me as odd and inflexible. Who says there has to be unanimous= consent? Isn't the Internet supposed to be a place where you can pick or c= hose? Are you saying that if the SL clone OpenSim decides > it will refuse to transport permissions metadata that you'll drop this de= mand, and cease attempts to secure permissions metadata merely because one = of eight or 250 or how many virtual worlds there are vetos it? Why? Is this= another one of those 0/1 or 100 percent or nothing perfection types of tec= hnical demands superimposed on to governance affairs that ought not to work= in such an inflexible matter? > > In the world of the "Internet copy machin" and the SL copy bot environmen= t, creators are happy if they get 67 percent protection, not 100 percent, = and they don't wish to abandon the 67 percent by declaring 100 percent is i= mpossible. > >>TLS is _the_ standard used to protect your credit card numbers and it's = perfectly legitimate within the context of a TLS protected message stream = to NOT USE ANY ENCRYPTION WHATSOEVER!!!!!! > > I'd like to hear a second opinion on this. When I see someone emotionally= all-capping and exclamation-pointing a proposition, I don't see science, I= see religion. > >>In short... just because a standard says you can shoot yourself in the fo= ot... honestly... you don't have to. When you have a protocol where not all= options make sense for all participants, you generally see people develop = policies with names like "interoperability profiles" or "interop policy." = These policies detail which options are allowed and which are forbidden, an= d under what conditions. > > But if you decide in advance that just because one player among all the v= irtual worlds says that they don't feel like transporting metadata for perm= issions you won't adopt it as a value, then it sounds like there isn't any = flexibility whatsoever. Just because one platform dumped IP, the rest could= n't insist on upholding its implementation even as a choice. > >>So why make broken protocols? > TLS_RSA_WITH_NULL_MD5 is not evidence of brokenness, it is evidence of > flexibility. There are many situations where encryption is not needed > but origin integrity is. In some of these situations, the use of > encryption is actually counter-productive. > > I wouldn't know. That sounds like a political opinion. I'd like to hear m= ore about this. I wonder why origin integrity gets to be invoked, but recei= ving integrity matters not. While it may feel like what is transferred amon= g worlds is just a stream of numbers to you, to users, the code feels like = real tables, houses, water, sky, etc. And the attitude toward them is diffe= rent, and if they are created then the artists might like more care than NU= LL put over it. > >>you MAY use a ciphersuite with a NULL cipher. > > This sounds like something I'd never want a hotel manager to be telling m= e. > >>And so it is with permissions meta-data. It is highly likely we will > produce one or more protocols that do not even mention it. > > Yes, that's what I'm concerned about. > >>and this is why it is not a failure to define a protocol without permissi= ons meta-data. just because one protocol doesn't define it doesn't mean ano= ther one won't. and just because a suite of protocols doesn't define it, do= esn't mean it won't be used in some implementations of the protocol. > > Sounds like now permissions have become a mere module to tack on as an af= terthought. When that is how it is conceived, rather than embedded into the= system as a forthright recognition of the importance of economies to virtu= al worlds, then it seems like we are in an eternal sandbox. > >>so.. you want world of warcraft, penguin cafe, qwaq, there.com, sony > home, eve online, osgrid, etc. to all use the second life permissions > system instead of the one they made for their user base because you > may one day want to use those worlds? > good luck. > > So...I'm supposed to wheel into Azeroth in my Scion and set up a picnic t= able and a barbecue and throw some steaks on the grill and then invite the = orcs for a picnic? Perhaps we can cuddle on the blanket? > > I'm hardly the only participant in this list who is just not getting this= notion of melding versimilitude worlds with fantasy realms. I haven't hear= d any user base in WoW agitating for SL avatars to invade their war game, = and the WoW players of SL aren't clamouring to be able to make armour in SL= and port it into WoW...oops, they can't do that because there is *no user = generated content* in WoW unless you consider player strategies in meta-gam= es like DKP, etc. as UGC (which I do, but its non-inventoriable content). O= ne can imagine that perhaps some light client or "window" into a quest in W= oW could be interesting or useful while someone was simultaneously in SL, k= ind of camming in, but the intensity of the WoW quest would preclude wishin= g to go camming into other worlds and spaces. You don't need interoperabili= ty. You have Windows. You tab the window down? And go in the other game. Ta= kes a second. Worlds for Windows, by Microsoft. > > So it's false to invoke a) non-UGC games like WoW and b) worlds where pro= tection is achieved, like There.com, through the central committee. What's = operative here are the SL clone worlds or worlds emerging that might have a= similar principle of UGC. So then, I don't get this strange reticence to e= mbrace and promote the essential, best core of SL, which is the ability of = people to easily make, share, and sell content with a very easy and underst= ood and widely accepted c/m/t permissions system. Again, I can only repeat = the question: why is it good enough for SL but not good enough for the Meta= verse at large? If it is not good for the Metaverse, why is it still in SL?= Some temporary Leninist NEP, is it, until another revenue source is develo= ped (like domain names or licenses to hook up to the asset server?) > >>again. this is not the forum for this discussion. this is a forum for > people who are implementing virtual worlds software. and honestly, > your participation here is puzzling to me as you have publicly equated > the IETF with a BDSM cult. > > Let me tell you two words: Facebook TOS. > http://uk.reuters.com/article/technologyNewsMolt/idUKTRE51H6V820090218 > > People who implement virtual worlds software, like people who implement s= ocial media software, can no longer expect to do this in isolation, and wit= hout accountability to, those who they are making it *for*. The reason the = call it virtual *world* is because *it's a world with people in it*. The re= ason they call it social media is because it's *social*. So you cannot deve= lop in isolation from the stakeholders in these worlds and spaces. They are= not mere customers you can hold at arm's length while you sell a product a= s a vendor; interoperability begins at home, between the platform provider = and the users. > > Your "puzzlement" is typical of what I call the Geeks' Forced Migration P= olicy, as it implies: "If you don't like it, leave." Like America, "Love it= or leave it". That's silly. Governance of software is not like an opensour= ce project where you disagree and make a fork. That culture inhibits the fr= ee consensus that is needed for further development of the 3D Internet. > > Yes, I have compared the rigid, arcane, extensive, oppressive rules and r= ituals and hive-mind humming of IETF as "like" BDSM culture in this regard:= it puts you in the wrong at every turn. You can never understand *enough* = about it. Journalists who try to report on it end up "scarred". They are al= ways incorrect, and always needing yet more indoctrination. The atmosphere = is not one of liberal democratic discourse, where one can agree or disagree= or criticize or support, it's one in which there is only the double-plus-g= ood promotion of the positive proposal and the "yes" vote and never a "no" = vote. Whatever "necessity" there is about having this kind of culture to de= velop code or technical standards and I'm not sure in fact it's a necessity= even there) it is not a necessity and is even an obstacle in the developme= nt of socialware, which ought to be the third thing after hardware and soft= ware in which the customer feedback, the laymen's concerns, are constantly = incorporated as a > matter of course, and not just tacked on at the end of the process. > >>huh? where do you get this? > > I read what you wrote. And my question stands: why uphold c/m/t in your o= wn world if you do not wish to support it elsewhere? > >>but again... this is not a forum managed by Linden Lab and it is not a fo= rum devoted to Linden Lab's policies. if you have a problem with Linden's p= olicies, please use the appropriate channel. IETF !=3D Linden Lab. > > If Linden Lab's policies are universalized by becoming a standard, they a= re the business of the Metaverse at large and not merely a customer service= problem for your own grid. Sorry, but I reject the Linden "channelling" ap= proach to dismiss issues on a public forum of this nature. > > ____________________________________________________________ > Get important data to help make informed decisions. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTHIsWCzPr4ZKRD95AACAfPA= cApfbx6uav0fIglcT0buMBAZvJIa68/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From wjgeorge@dceo.rutgers.edu Mon Feb 23 12:25:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD86528C13E for ; Mon, 23 Feb 2009 12:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdr+JwgEKOr9 for ; Mon, 23 Feb 2009 12:25:36 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id EBFB128C145 for ; Mon, 23 Feb 2009 12:25:35 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1964321yxm.49 for ; Mon, 23 Feb 2009 12:25:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.33.4 with SMTP id g4mr4559362ang.133.1235420753341; Mon, 23 Feb 2009 12:25:53 -0800 (PST) Date: Mon, 23 Feb 2009 15:25:53 -0500 Message-ID: <27a487810902231225l6698b519rdc6f1d53ba215024@mail.gmail.com> From: William George To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016e645b90426ad0d04639bcf8e Subject: Re: [mmox] Permissions (Gareth Nelson) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:25:37 -0000 --0016e645b90426ad0d04639bcf8e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nice first step, but it's not clear how this would handle composite objects: objects that have two different creators and/or permissions settings. The SL convention of using the root prim's permission for the entire object leads to restrictions concerning the reuse of "no mod" sub assemblies in a larger assemblies. --0016e645b90426ad0d04639bcf8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nice first step, but it's not clear how this would handle composite obj= ects: objects that have two different creators and/or permissions settings.= The SL convention of using the root prim's permission for the entire o= bject leads to restrictions concerning the reuse of "no mod" sub = assemblies in a larger assemblies.

--0016e645b90426ad0d04639bcf8e-- From dcolivares@gmail.com Mon Feb 23 12:25:42 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF1F028C15A for ; Mon, 23 Feb 2009 12:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuPDiI35YACU for ; Mon, 23 Feb 2009 12:25:42 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 8060528C159 for ; Mon, 23 Feb 2009 12:25:41 -0800 (PST) Received: by bwz5 with SMTP id 5so5164743bwz.13 for ; Mon, 23 Feb 2009 12:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QQ2wwnqDe2QHWATr8VYCLXA4YNVHFqcKrJV/49PQuG8=; b=xe1muhB36kzxGpoZj+0B0IvcZH43EDvxcQOPpACa/g81m6PDvJ1AqSXndwaxD7oyoV WZht0dLAN7SRpFRv9b4bsKvc6MZiZemhRbZWZP3NDNNW7xhFjossFtidnEZUoKlR/T9w UP0loJuagOdd8z8D/hWHFVuj3zWwXjW0UAUOQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CP7mnF51vyRaCVVFmtwavtraDpEkluOVeuCSc+pYJ4/EeiAjaxBibkrjsrl90uC58R fuQdk4wYCeimP+agGxZRCL4MciIQSz0Wtmg95dnpHqLCKGwfOQf39eETept1oZhhuBgt o/hmSoY5B1J5IwBASNUq4/BX6TZxovCLy9n7A= MIME-Version: 1.0 Received: by 10.103.222.1 with SMTP id z1mr3717814muq.51.1235420758277; Mon, 23 Feb 2009 12:25:58 -0800 (PST) In-Reply-To: <20090223.144052.24438.3@webmail03.vgs.untd.com> References: <20090223.144052.24438.3@webmail03.vgs.untd.com> Date: Mon, 23 Feb 2009 15:25:58 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:25:43 -0000 "Debating various economic systems and business models wouldn't fall into the purview of this list if it weren't for the very pertinent fact that interoperability precludes or allows forms of economic systems by affirming or denying intellectual property rights in the code." Really? Isn't it good enough to say that some business models will require user created content IP protection and some will not and move on? "Then the unspoken or espoused economic views of the coders matters a great deal. If they all adhere to the copyleftist mode and claim that inserting c/m/t "breaks their business model" (although I don't see that it does, as they can check off "yes" to c/m/t), and they impose that as they only choice articulated in the tools that emerge from the code, then they've foreclosed a Metaverse economy based on IP and micropayments. " Business models that require user content IP protection can limit interoperability based on acceptance of a contract to respect intellectual property rights with punishments for non-compliance. Also, while I agree with you on the I-Phone analogy does demonstrate one business model, I wanted to make a point that the i-phone uses the centralized clearing house you argued against with jw (Jon Watte) regarding There.com. Sincerely Dan On Mon, Feb 23, 2009 at 2:40 PM, dyerbrookme@juno.com wrote: > Debating various economic systems and business models wouldn't fall into = the purview of this list if it weren't for the very pertinent fact that in= teroperability precludes or allows forms of economic systems by affirming o= r denying intellectual property rights in the code. > > Then the unspoken or espoused economic views of the coders matters a grea= t deal. If they all adhere to the copyleftist mode and claim that inserting= c/m/t "breaks their business model" (although I don't see that it does, as= they can check off "yes" to c/m/t), and they impose that as they only choi= ce articulated in the tools that emerge from the code, then they've foreclo= sed a Metaverse economy based on IP and micropayments. > > Or, not to limit ourselves to virtual worlds because interoperability con= nects not only to VW platforms, let's take a story of how someone really ma= kes a living in the real world of real proprietary code who is not an anecd= ote, but typical of a software business: > http://tech.yahoo.com/blogs/null/124073 > > Whatever the jailbreaks and rips, the i-phone is based on proprietary cod= e. It admit various apps and those apps, too, are proprietary in many cases= . This fellow gives away free games, but they are merely loss-leaders to ge= t customers to buy the closed-code game which is sold by the i-phone as clo= sed close. So the interoperability that enabled all the widgets or apps or = whatever is still based on a proprietary code concept for both the technolo= gy vendor and the user. If those who believed there should be no proprietar= y closed code prevailed on the production of the i-phone and its app econom= y for thousands of developers, there'd be no mobile app economy, now would = there. That's because the option did not get foreclosed in development. > > If there's something I haven't understood about how i-phone and apps work= , enlighten me, but I think the analogy is sound. > > ____________________________________________________________ > Click to get free auto insurance quotes from top companies. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTImHYq28cgTcs4n52SAdDcg= 0gdAIaDeGlFIVNVzoPvqnTSmJj3l8M/ > From jwatte@gmail.com Mon Feb 23 12:45:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D545D28C145 for ; Mon, 23 Feb 2009 12:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izjBHyI8sMSe for ; Mon, 23 Feb 2009 12:45:11 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id EEA2F28C120 for ; Mon, 23 Feb 2009 12:45:10 -0800 (PST) Received: by gxk22 with SMTP id 22so5710247gxk.13 for ; Mon, 23 Feb 2009 12:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DrYCGCF8kiMfcFvh4SQdIv06tDwXJQi/jWqp36IowDQ=; b=x0q2tYLku+cUJJ9bZ70xMxEI5TM6pt/xD1B//Rvb/IhXjXQLU39gJPiGn2DcstpYt4 P6TYKU0Vp2K10V791Wj5QOXQCdDdKARRvH7IHCt1CGV8z+zMoMfA7vfhaqqWAEoGVTRl lMdWjUmZiudEKKlu4FPw2xFGkaeCPj+OYAVKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jWEMjH3K7xkWGBeZB3lVLn2P3uGoZvrq7BczsPPFHHM06AHMYESMQ1dnCu6IfZIJJI ARGVPhE/cLteO/1dLnrMy8HNhWcotNULoCSrrfqRUzWA8Ej/TWCWG7TsD2+sx7sBfaIu 1J5rl2nflXqqXNiK9afXGaaFyS7CfVXvDn9bk= Received: by 10.100.108.9 with SMTP id g9mr2365220anc.68.1235421928038; Mon, 23 Feb 2009 12:45:28 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d38sm13611716and.29.2009.02.23.12.45.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 12:45:27 -0800 (PST) Message-ID: <49A30AE5.6060307@gmail.com> Date: Mon, 23 Feb 2009 12:45:25 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jesrad References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> In-Reply-To: <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:45:11 -0000 Jesrad wrote: > Imagine for a second that the cross-grid protocol mandate somehow that > objects made on one grid be hosted and served to clients from this > grid, and not transfered to other grid servers / simulators (though > the owner may have the third-party possibility of exporting from one > and importing to another so it is hosted multiple times and thus > exists in multiple instances). > > How then would the soccer ball on my server be able to affect the soccer goal on your server? If only the clients know about the entities from the 2 servers, your "goal" object on your server would never detect the presence of the "ball" object within its "goal zone." This is why I believe that direct client distribution is not actually the right model. Sincerely, jw From jwatte@gmail.com Mon Feb 23 12:51:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C023A6974 for ; Mon, 23 Feb 2009 12:51:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhfyEyQyp0YX for ; Mon, 23 Feb 2009 12:51:21 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 2EBA03A6897 for ; Mon, 23 Feb 2009 12:51:18 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1974973yxm.49 for ; Mon, 23 Feb 2009 12:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=wcAyaX8eai65D8UctVCbYbT5cWtgaVFoPHXFc3TQKSA=; b=IOOPF1J5+lLS7DK0TtOmHrHeOXu6aiTJQBcxutJJWkAjs9hgtYjyQJPVjI/AGIAT4s TuUYiYYINUv3QsHO0pigDeo3h5N/OIdR+ZjdNdE9qRbRPrRqG2WieL2WXJWLEWYCFK9a Q7RaLK8qZczW2PnnL4FpeQTPeCyd1EqkCYdwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Nj6pCH5jBLEcosfiAo8gb8Iob1OQopiqUeuA+QDMEtDTq8TBfkTm2cRP8ch93CYgAq tA+sGCqII/3y9JP2DgGs0d7xBzq4hleomsc/7AccqZ8yOLT7ETOzWRslFKZAQNZdKQ9+ nXYAuxIVhId3o6jNBc4itBPxruMJLtN0gR4uU= Received: by 10.100.91.3 with SMTP id o3mr4357913anb.66.1235422293824; Mon, 23 Feb 2009 12:51:33 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d24sm7740717and.50.2009.02.23.12.51.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 12:51:33 -0800 (PST) Message-ID: <49A30C53.3020308@gmail.com> Date: Mon, 23 Feb 2009 12:51:31 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jesrad References: <20090221.022731.27043.2@webmail04.vgs.untd.com> <53cd6c2e0902230146x67de6a6fj4c4ee824570be75f@mail.gmail.com> In-Reply-To: <53cd6c2e0902230146x67de6a6fj4c4ee824570be75f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 69 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:51:22 -0000 Jesrad wrote: > I am not subjected to any NDA, agreement, contract or law that would > prevent me from contributing to the MMOX group, my objection is only > grounded in domestic political and ideological context. > Then your ideology forbids you from contributing to the IETF. Or you can re-subscribe to this list using your normal name, and never mention your specific SL identity, and nobody would know to draw the connection. Sincerely, jw From dyerbrookme@juno.com Mon Feb 23 12:55:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70963A6897 for ; Mon, 23 Feb 2009 12:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEKXHU8-Snts for ; Mon, 23 Feb 2009 12:55:10 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 0F2673A6A10 for ; Mon, 23 Feb 2009 12:55:09 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail24.vgs.untd.com [10.181.12.164]) by smtpout01.vgs.untd.com with SMTP id AABE4GDHHAMCYU2A for (sender ); Mon, 23 Feb 2009 12:53:59 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkN4TT6zEXZpbAp8JaFnubFlg== Received: (from dyerbrookme@juno.com) by webmail24.vgs.untd.com (jqueuemail) id N945N2BB; Mon, 23 Feb 2009 12:53:21 PST Received: from [68.161.198.3] by webmail24.vgs.untd.com with HTTP: Mon, 23 Feb 2009 20:52:50 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 20:52:50 GMT To: dcolivares@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.155250.2225.0@webmail24.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 3:4:3208941061 X-MAIL-INFO: 356e279e0f6eeb0fcecefe57d7d77bf7939ade6a9a7b9af36a X-UNTD-Peer-Info: 10.181.12.164|webmail24.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:55:11 -0000 >Business models that require user content IP protection can limit interoperability based on acceptance of a contract to respect intellectual property rights with punishments for non-compliance. Then maybe there's no reason for interoperability? It's ok to debate whe= ther there is isn't a case for operability on the way to discussing the = standards. I have yet to hear a cogent "mission statement" that explains= what the value-add is for interoperability, what the platform providers= gain collectively and individually from this theoretical, arduous, like= ly costly, and likely non-productive exercise. >Also, while I agree with you on the I-Phone analogy does demonstrate one business model, I wanted to make a point that the i-phone uses the centralized clearing house you argued against with jw (Jon Watte) regarding There.com Um, I didn't argue "against" the centralized clearing-model. I pointed o= ut merely that it was a solution to IP theft which many would find too c= ontrolling and rigid, especially after being autonomous actors in a free= economy in Second Life, and that it would not solve the problems of c/m= /t. Like firewalls, it's an internal company solution but it doesn't gra= pple with the collective problem of interoperability and IP, and the pro= blem of how c/m/t is lost through interoperability unless it is welded i= n to start with. Generally, when someone has to start invoking Nizkorisms and begins Fisk= ing and Haskelling and all the rest, they don't have persuasive argument= s and facts, and are left to browbeating over "process". It's usually a= reliable marker. ____________________________________________________________ Let great B to B marketing solutions propel your brand to new heights! C= lick now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTMPaBuiQG6q8ESkQ31Hpx0= mWEFSySuje35XRnFh36XYJsXwfi2uA4/ From jwatte@gmail.com Mon Feb 23 12:56:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7BF3A68A6 for ; Mon, 23 Feb 2009 12:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8n6YjWedQPt for ; Mon, 23 Feb 2009 12:56:13 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id D25273A6897 for ; Mon, 23 Feb 2009 12:56:12 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1976983yxm.49 for ; Mon, 23 Feb 2009 12:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=K4NYY9YVaw7NrJV1HZvkISvFf4YG5DHjM+6ZUIxj+Do=; b=mCw5AX6HnxMwOeNV0HU0z0TytMye1DSCoTMC2U4Fah8zgPjcwh58obl8WKQJbR5sCG 6sNisUic0yMJeKKVAasLacfDL99Hg70H1hmDgfwWd16v7x0AZNCDP0bnyk7gXPZTLQB2 Ez3Xjd+2Z7SdGK3g7/mgv7hXy3DBV0C4FBVY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=mUfZnL5juW7j3fRadTAVd9VNC2vHqRCFAOC1M9cdT1eWL3VCDpv0nQHpDxcCT8GqS+ x8cB/fRI8C5lr8vgKSn8IVsQ/WozlTP4DwQvcwyCYZ+gztshNz95GpoTcxF/qYmC9dxj gubnIG0gY+jqqqHH26zvBWpJpMp2XFtEJuNJ0= Received: by 10.100.225.19 with SMTP id x19mr2371784ang.24.1235422590911; Mon, 23 Feb 2009 12:56:30 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d21sm6210451and.6.2009.02.23.12.56.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 12:56:28 -0800 (PST) Message-ID: <49A30D7A.3040003@gmail.com> Date: Mon, 23 Feb 2009 12:56:26 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:56:13 -0000 Catherine Pfeffer wrote: > > > > success > true > > > something_i_like_to_eat_on_sundays > bananas > > > A better way is bananas natural way to express it.This has less of the angle bracket tax, and it has a VERY straight-forward parsing style. In fact, in my opinion it's the most In XPath, it's now trivial: "value[@key=success]" I'm working on a list of the things I think are wrong with the current proposal, of which this is one thing (there are about six). If we're open to change on those things (including this), then I could get behind the LLSD. Stay tuned :-) Sincerely, jw From jwatte@gmail.com Mon Feb 23 13:06:28 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C5528C173 for ; Mon, 23 Feb 2009 13:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXrZOC2w4g7F for ; Mon, 23 Feb 2009 13:06:28 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id E149B3A68A6 for ; Mon, 23 Feb 2009 13:06:27 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1162196ana.4 for ; Mon, 23 Feb 2009 13:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YdDjHLFsTVEtO0/OgZ7uGbBCVtPinwVvCH/4njwsbPg=; b=OAtKS4vfyE4iiGV1RxNCvkX60aO4qP20R+oq5Ngy6PX2Lus6JdoAChjz00zvF2opOM MK+SbsYja7ygrWFaFcMSjxM28oYxFT16MgmAzu2snrb8O2uC0PvTOHjVYTtku5TfDQTo PlpYdADQJhPhwMhuk3Mbc2x0IlqG4f+glEPXY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KRFVe2MmyioRnvSlrX8q1YfwKyIguERgRuOklieiuBb1RQg4YEOWekJHRceVEEGRhv DtCjCrhowx3pquB4/RKl2cm+FWE4WLm9YihJK8yWsStagyOkpwEV5kkVUej8Fgd5Rh6x PH5gypm4Y6JWUM4Tbx+c95TfW3TVd3Udwp2qQ= Received: by 10.100.138.17 with SMTP id l17mr2559683and.2.1235423205453; Mon, 23 Feb 2009 13:06:45 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d24sm7773932and.50.2009.02.23.13.06.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 13:06:44 -0800 (PST) Message-ID: <49A30FE2.1010801@gmail.com> Date: Mon, 23 Feb 2009 13:06:42 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jesrad References: <20090223.084454.24252.0@webmail09.vgs.untd.com> <53cd6c2e0902230613y6e86f16fyaa841a08db4b86d1@mail.gmail.com> In-Reply-To: <53cd6c2e0902230613y6e86f16fyaa841a08db4b86d1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:06:28 -0000 Jesrad wrote: > I actually wrote that mandating the implementation of DRM on top of > any permission/copyright metadata transmission mechanism would severly > reduce the number of grid systems that comply with the protocol. > Note that it would be totally possible for someone to come up with a DRM scheme, that mandates that content create /under that DRM scheme/ only be transferred to other trusted implementors of that scheme. That would mean that, if the content was created on a compliant system, and properly marked, it could not "escape" into non-DRM systems. I think that enabling this within the standard is important. A world can then compete for attention, by implementing and adhering to some popular scheme. For example, if creators feel most comfortable with "Microsoft VW Content DRM" or "MacroMedia ContentSafe(tm)," they could make sure to create their content in a world certified by one of those providers, and mark the object as not transferable outside those domains. Part of the certification would then be to make sure that such marks are actually adhered to. This neatly splits the interoperability protocol into the interoperability part, which is free, open, and allows OpenSim or LeftistWorld to be as open as they want, and the DRM/enforcement part, which allows the concerned content creators to stay as locked-up as they want within RightistWorld. Sincerely, jw From jwatte@gmail.com Mon Feb 23 13:10:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F30B3A68A6 for ; Mon, 23 Feb 2009 13:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ9P0uDhL5RJ for ; Mon, 23 Feb 2009 13:10:44 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id AD9F53A69CF for ; Mon, 23 Feb 2009 13:10:44 -0800 (PST) Received: by gxk22 with SMTP id 22so5749548gxk.13 for ; Mon, 23 Feb 2009 13:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=FnZf8PikFAOLOmDHfLC3hRW04AnbJjBe8GkY7yV0tqI=; b=dA3SW/qRcfgCA925vRxCuzBRavEn7ff7J3hmym+fhk1r6BWQjIhl3rpY9p5WB2f6Nc mXZFHQa9SyXnwxe8lVFRBJydu5+ddDACrhWTN6k8bUpBogJbgWgyeOFIszNdBdmxkp9p o4bhVPkzTAGrvTTpKPerf1xku+sQQ6VOagY48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=RdHhx6da8IN0A/9S3pd13bECdA1QjCZe45EuHBqvEGSqCeRLlFygpYi3GbXrWoQ4FJ XbLndGYKkIPBQRM6ftoa7IBYkW/UEpHlOC6E+XxHCYbbeTKh3nkbS8dQKCNjmy09p8GO GilLHea9eAe31C56/YAx2YBEiEYg1msDxch64= Received: by 10.100.11.3 with SMTP id 3mr4654747ank.123.1235423461470; Mon, 23 Feb 2009 13:11:01 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d35sm785070and.58.2009.02.23.13.11.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 13:11:00 -0800 (PST) Message-ID: <49A310E2.2040706@gmail.com> Date: Mon, 23 Feb 2009 13:10:58 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> In-Reply-To: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: [mmox] DRM, Permissions, Openness and Leftism: A grand unified theory X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:10:46 -0000 Gareth Nelson wrote: > Possible actions: > Copy > Modify > Transfer > Transfer for cash > > :"Transfer" and "transfer for cash" really aren't different operations. How two entities choose to transfer is up to them. From the point of view of the originating system, a "transfer" means that the "owner" field changes from A to B. It may be that you want "conditional transfer," where there is some URL that needs to return "true" for the transfer to complete; that URL could then affect a sale transaction, or it could do something totally different (like signing a "guest book" or checking against a "black list"). Does "Copy" mean that the originating system creates a new object instance, with a potentially new owner? And I think you may end up with cases where I get a copy of some object you've made. That means that there's an object on your system that has me as the marked owner. I may not actually be a customer at all of your system, so it may be that your system doesn't want to allow me to do that. Or, if they feel that hosting objects for non-customers isn't a problem for one reason or another, they could allow that. (There are some business models where this makes sense; for example where I can't instantiate an object unless I'm in an area on that server, and I can't be in an area on that server unless someone is paying for the machine time) Is there a difference between "modify" as in changing properties of an existing object, versus "read source" as in extracting behavior or presentation specifics (meshes, scripts, etc), versus "derive" as in creating a new object that references the original object with some potential overrides? And are we talking "objects" vs "object blueprints" here? Is it the case that any object is actually a "blueprint," and there's no templating system in SL? I know that many other systems make an explicit division into "instances" vs "blueprints" (or "templates"). An "instance" starts out as the template, but can override some set of properties -- for example, the "position" property would typically always be overridden :-) You also need to specify leftism/stickiness. If you allow "copy" or "derive," then some licenses say that any copy so created must also allow "copy" and "derive." Other licenses say that a "copy" could have its permissions changed. Similarly, a "transfer" may be made in terms of ownership of the particular instance, OR it may be made in terms of source right -- and, in that case, the source rights may be with or without sub-source-right permissions. I think we can capture this by making these changes: 1) specify the "template," if any, of the object 2) specify whether each permission field is "inherited," "revoked" or "immutable" on transfer 3) add the "view" and/or "derive" permission bit Specifically, the left-ism licenses would favor setting the "copy" and "view/derive" bits, and set them with "immutable" semantics. A right-ism license might specify "copy" with "revoke" -- you can't re-copy something that's been copied. Of course, if it's "transferred" then that bit probably shouldn't be revoked, so it might be there's a matrix of what happens to each permission bit under each operation. An additional meta-bit on each operation might be "only when managed by DRM" -- the "copy" bit might say "allowed only when under DRM," and then there's a separate list that identifies the allowed DRM models (so that the source can provide trust or not). As long as the DRM trust chain is unbroken, and the object originates in a DRM system, that would allow a "fully secure" DRM model. Personally, I think that this could, and should, be done, and that it serves the desires of all the parts of the spectrum. The "open" grid needs to identify itself as NOT supporting DRM, and then the "closed" grid will not send the data. If the "open" grid tries to impersonate a "closed" grid, then it's up to the specific DRM schemes to use signatures or whatnot to smoke out the impostor; that capability is very common with distributed DRM schemes and there are technical solutions available, should you want them. Sincerely, jw From jwatte@gmail.com Mon Feb 23 13:14:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6133A6833 for ; Mon, 23 Feb 2009 13:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEV4Hw1ip4FG for ; Mon, 23 Feb 2009 13:14:22 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 5594E3A67E2 for ; Mon, 23 Feb 2009 13:14:22 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so1982756ywh.49 for ; Mon, 23 Feb 2009 13:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tLbTviGVQteQ4Ws2atKZDPCBnxkKDKzXtFAMFrfsnLM=; b=M7ploJl/gK42W+aymwaCTdlLZkI0COf0F2pPqVUu/d8IG5SFzy6g0qxjh0ZtSaKMBF tcmCZLDVFPpqzdVt+42D+VDLwOVpw5bIgdZSF2Uk0RJPzgUR+vHnfJXCzDL6LtE7Oo93 1FLFwFIvs08O8KiC0cqs+S4jNa4ewg/jA8Z+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=bs2yuFw9Ct6x9vVA9I2dQL3N5haYip+V8j6ERQcihasvrmXerwTkQTqV1NDceY83pm tj/yeLwlpCRLAvUFO0iGqtMnHfp4aq58IO9on3DvBgXIV/2LYuHr/h/Ab9vOemv253bG uJ3okq6+ai+F//QW9I7GSrJG8TWfq30v0FB1E= Received: by 10.100.137.12 with SMTP id k12mr4617980and.124.1235423679205; Mon, 23 Feb 2009 13:14:39 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c9sm10114963ana.33.2009.02.23.13.14.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 13:14:38 -0800 (PST) Message-ID: <49A311BC.90405@gmail.com> Date: Mon, 23 Feb 2009 13:14:36 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <49A2500F.3000104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mystical Demina , mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:14:23 -0000 Morgaine wrote: > I can't understand why you continue to raise the spectre that we're > here to rubberstamp SL standards. We aren't. I'm not aware of > anybody with that agenda. > Because there are several people on this list who say "OpenSim and Second Life are already trying to do client interoperability; I think we should run with it and not worry about something bigger." Similarly, I find that the current OGP proposal specifies some thing ("Rezzing" of avatars) that are Second Life centric, while not specifying other things that would be necessary for an actually useful interoperable virtual world (like entity telemetry). Similarly, if OGP is specified as a mostly empty vessel that can contain arbitrary negotiated data, what would probably happen would be that OpenSim puts OpenSim data in that vessel, and IMVU puts IMVU data in that vessel, and both claim to support "OGP interoperability" but you can't do anything useful through that claim. I want to avoid that outcome. > > We are working in good faith towards your item 2), while noting that > item 2) means interop with "all" reasonable worlds, and that includes > Linden worlds. It's not either/or, it's both. Please grant us that, > so that we can actually make headway. > > /(Proviso: your item 2) says /*single ... simulation*/, which is > incorrect, as we have no remit to straightjacket diverse worlds into a > single simulation.)/ What I mean by "single simulation" is what the user sees when connected to a specific, interoperating instance. I suppose the user could be connected to multiple of those, similar to opening multiple video streams in a media player, but then those generally have "nothing" to do with each other. Okay, so if most of us agree on 2), can we just say we have "rough consensus" on that, and politely reject any attempt to steer the work towards 1)? Sincerely, jw From dcolivares@gmail.com Mon Feb 23 13:18:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6FA3A68A6 for ; Mon, 23 Feb 2009 13:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGhHCEaK0ijP for ; Mon, 23 Feb 2009 13:18:47 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id E8AC83A6833 for ; Mon, 23 Feb 2009 13:18:46 -0800 (PST) Received: by fxm11 with SMTP id 11so2228681fxm.13 for ; Mon, 23 Feb 2009 13:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E15ttn9ezsmrcRo1rouNVkJFBbSCwjI1U38B8YqnUok=; b=mZ8+KirFZjnVwFpi1Z/cDEVlGerfDpmpbwB44D/GD6LQeOPDr725d2+I7taRbvJ3kj sQRApF1hNKRu2MaWXiRq+roAS/Z0xRy7aDyKWCG14xM0/Vd1Dma12PZ9ZGBfEsnQDS+p zWDLuiWp8duTyISYkryTf/UMpIXoSgAB3NgnA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pEeQ4nmCi0nBFPC76WjaCZz39xa/o83G1joO70rnpJsDlLLyZ0lJkz52ShDQbA86Yx I6IDdFWpeCB1dunrZAtvwUIqWDfV4p1gOJO4BaD6F+3jRnbJRtRO8NmA8KM9EmiSINPT qR2582bYrfJ39R0jYaOeDa7rN/C2hg5K2Bvbc= MIME-Version: 1.0 Received: by 10.103.246.1 with SMTP id y1mr3767768mur.116.1235423943328; Mon, 23 Feb 2009 13:19:03 -0800 (PST) In-Reply-To: <20090223.155250.2225.0@webmail24.vgs.untd.com> References: <20090223.155250.2225.0@webmail24.vgs.untd.com> Date: Mon, 23 Feb 2009 16:19:03 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:18:49 -0000 "Then maybe there's no reason for interoperability? It's ok to debate whether there is isn't a case for operability on the way to discussing the standards. I have yet to hear a cogent "mission statement" that explains what the value-add is for interoperability, what the platform providers gain collectively and individually from this theoretical, arduous, likely costly, and likely non-productive exercise." You are correct, and are more then welcome to debate the case for interoperability. "Um, I didn't argue "against" the centralized clearing-model. I pointed out merely that it was a solution to IP theft which many would find too controlling and rigid, especially after being autonomous actors in a free economy in Second Life, and that it would not solve the problems of c/m/t. Like firewalls, it's an internal company solution but it doesn't grapple with the collective problem of interoperability and IP, and the problem of how c/m/t is lost through interoperability unless it is welded in to start with." okay, I must have misunderstood you then when you said, "I'm not complaining about the current permissions system, I'm celebrating it as a good thing and urging that it be used as the standard. It's not about privileging one company over another, as I think the c/m/t regime is a pretty workable and remarkably successful regime that works far better than other solutions that companies have come up with (no UGC allowed, all UGC cleared through a central committee, corporate firewalls on private grids, etc.)" and "In the There.com/Forterra context, customer content is cleared through a centralized clearing house and must be approved by the company before it can be uploaded; customers are in a subordinate role. In Second Life, content-makers and scripters and animators appear as equals to the platform provider when it comes to content generation, and in fact have produced the lion's share of the world's content, unlike other worlds where the platform providers make all the content. Therefore this isn't just some "customer specifics" that has to be routed through the company, as you prefer." "Generally, when someone has to start invoking Nizkorisms and begins Fisking and Haskelling and all the rest, they don't have persuasive arguments and facts, and are left to browbeating over "process". It's usually a reliable marker." Logic is not process. Please examine: http://en.wikipedia.org/wiki/Logic I think you'll find that logic is a requirement of any discussion. I've made my position on this issue extremely clear. I'm arguing for the use of 'MAY' in the standard and not "MUST" with regards to protecting User IP rights and let the companies that require it based on their business models to require contracts with punishments to be signed before they allow one organization to 'connect' Thanks Daniel Olivares On Mon, Feb 23, 2009 at 3:52 PM, dyerbrookme@juno.com wrote: >>Business models that require user content IP protection can limit > interoperability based on acceptance of a contract to respect > intellectual property rights with punishments for non-compliance. > > Then maybe there's no reason for interoperability? It's ok to debate whet= her there is isn't a case for operability on the way to discussing the stan= dards. I have yet to hear a cogent "mission statement" that explains what t= he value-add is for interoperability, what the platform providers gain coll= ectively and individually from this theoretical, arduous, likely costly, an= d likely non-productive exercise. > >>Also, while I agree with you on the I-Phone analogy does demonstrate > one business model, I wanted to make a point that the i-phone uses the > centralized clearing house you argued against with jw (Jon Watte) > regarding There.com > > Um, I didn't argue "against" the centralized clearing-model. I pointed ou= t merely that it was a solution to IP theft which many would find too contr= olling and rigid, especially after being autonomous actors in a free econom= y in Second Life, and that it would not solve the problems of c/m/t. Like f= irewalls, it's an internal company solution but it doesn't grapple with the= collective problem of interoperability and IP, and the problem of how c/m/= t is lost through interoperability unless it is welded in to start with. > > Generally, when someone has to start invoking Nizkorisms and begins Fiski= ng and Haskelling and all the rest, they don't have persuasive arguments an= d facts, and are left to browbeating over "process". It's usually a reliab= le marker. > > > > ____________________________________________________________ > Let great B to B marketing solutions propel your brand to new heights! Cl= ick now! > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTMPaBugve2YtZ258gY9lHWA= 9TGr5fwUS8JjrPQ3oSa3t4xHhJzci8/ > From john.hurliman@intel.com Mon Feb 23 13:18:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBA6E28C160 for ; Mon, 23 Feb 2009 13:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKsQQXxI2J9R for ; Mon, 23 Feb 2009 13:18:55 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id B2ACB28C15C for ; Mon, 23 Feb 2009 13:18:55 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 23 Feb 2009 13:19:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,255,1233561600"; d="scan'208";a="113584071" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by azsmga001.ch.intel.com with ESMTP; 23 Feb 2009 13:19:04 -0800 Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.1.311.2; Mon, 23 Feb 2009 14:19:03 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Mon, 23 Feb 2009 14:19:03 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Mon, 23 Feb 2009 14:19:00 -0700 Thread-Topic: [mmox] XML serialization Thread-Index: AcmV+TsvwcYmlNaxQ12dEso7PiLKBAAArnoQ Message-ID: <62BFE5680C037E4DA0B0A08946C0933D5026392C@rrsmsx506.amr.corp.intel.com> References: <49A30D7A.3040003@gmail.com> In-Reply-To: <49A30D7A.3040003@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:18:57 -0000 >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Jon Watte >Sent: Monday, February 23, 2009 12:56 PM >To: Catherine Pfeffer >Cc: mmox@ietf.org >Subject: Re: [mmox] XML serialization > >Catherine Pfeffer wrote: >> >> >> >> success >> true >> >> >> something_i_like_to_eat_on_sundays >> bananas >> >> >> > >A better way is > > > true > key=3D"something_i_like_to_eat_on_sundays">bananas > > >natural way to express it.This has less of the angle bracket tax, and it >has a VERY straight-forward parsing style. In fact, in my opinion it's >the most In XPath, it's now trivial: "value[@key=3Dsuccess]" > > >I'm working on a list of the things I think are wrong with the current >proposal, of which this is one thing (there are about six). If we're >open to change on those things (including this), then I could get behind >the LLSD. Stay tuned :-) > >Sincerely, > >jw > Once you post your LLSD comments I can add them to the LLSD evaluation page= at http://www.openmetaversetech.org/node/13 (this site is currently under = heavy construction, but will become an open wiki soon). John From jwatte@gmail.com Mon Feb 23 13:20:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB493A68A6 for ; Mon, 23 Feb 2009 13:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwYEqHPRg-FH for ; Mon, 23 Feb 2009 13:20:30 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id 923263A6833 for ; Mon, 23 Feb 2009 13:20:29 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1166151ana.4 for ; Mon, 23 Feb 2009 13:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DafRPY93bU3Mi1I1e3erakgSKjNADlDIKF5fChEeTmU=; b=qwAuoI/n0e7e/briUrJLSUyJOwElz0o40j80MBMlrKXuEaIeXYO60PscJau48KL9o7 hO05Fo5Trsav9Z3FQVBJ+Kt6yj+PWsPw0vH80XXarY26y6pHBrasPcJVUpqhcn9NYAct +7JYe1gSK6WXd9kw17JeLDEHu7ry3fCyYpDZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZtKlpMaWA7AJQozkt/20U0AW3sMs3aZ4JKuwJ/dDcjUG3nZdsYLrLamu7ciyQCIfKW XkD5KpCdVN7wfwD4olDYBtkhUV90jWRntxYxEX/fIfjmNyR4PcTyrnaWpr/lQgq9i1pX 0KaM4j2YawuQ8h3PIVmvulPnweZSwz9tYHNnc= Received: by 10.100.8.4 with SMTP id 4mr4376844anh.118.1235424038132; Mon, 23 Feb 2009 13:20:38 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c23sm13551378ana.52.2009.02.23.13.20.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 13:20:37 -0800 (PST) Message-ID: <49A31323.8010804@gmail.com> Date: Mon, 23 Feb 2009 13:20:35 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> <61dbdd7d0902230537n20f86856i8b392a80b1740bc0@mail.gmail.com> <53cd6c2e0902230559g73aa66e3u4026f34b95ec215@mail.gmail.com> <49A2FDB8.7000303@cox.net> In-Reply-To: <49A2FDB8.7000303@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:20:30 -0000 Lawson English wrote: > SL, sorry to keep bringing it up, but its an important usecase, has > 20,000 simulators and some > ludicrous number of "assets" to deal with. If there's no local caching > of assets on any other grid, > permissions allowing, then the SL servers would be expected to be > asset server to the metaverse > and they already groan under the strain of talking to the limited SL > world. The metaverse is Note that the SL assets can only be used when the SL servers are participating in an interoperation scenario. If SL makes it a requirement that at least one SL customer is part of any interoperation scenario involving SL servers, then SL has a revenue stream for each such interoperation scenario. From the point of view of any one service provider, I think that this model will work well, and it will scale fine. The problem is then reduced to a per-provider problem, where each providers' ability to serve its customers is an implementation and business model detail, not an interoperation detail. > projected to become 100-100x larger than Secondlife. the AWG's > original mission was to try to > desing a SL-like meta-grid that would handle such "scary numbers." We > can't just handwave > the issues away and suggest that existing systems and architectures > will "just do it" in some way. > I think we've all agreed that this group is not the AWG. Our role is not how to figure out how to "scale Second Life" or even "scale something Second Life-like." Our role is to figure out how to make multiple, disparate systems able to talk to each other -- hopefully in a way that will let the greater world able to scale in aggregate. Sincerely, jw From jesrad@gmail.com Mon Feb 23 13:23:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF01C28C124 for ; Mon, 23 Feb 2009 13:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF55NLwfGPMk for ; Mon, 23 Feb 2009 13:23:38 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 7CCF13A6833 for ; Mon, 23 Feb 2009 13:23:37 -0800 (PST) Received: by fxm11 with SMTP id 11so2233076fxm.13 for ; Mon, 23 Feb 2009 13:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gZHB0gLFRwEkGNFzocsTSE4u1aGiaKKDfiUU3DAvc80=; b=tCb9EotQ9AjRdvhHRuKimdJSFN7FZkuFomFHs0E+LSv8Dliuu1MbhfAnGSK1MTQFgT tHxKPwGGpsOxvcKzO+mHeZXFX58v/IqFZN8KYy4TsHNlAbNQx57CviznQefQZ247DhAf bHpMsegawbFzSpjOIuqZhSpAPN4XHo8hsecfA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pcaPFGDyc4t7qQTfrr+LqodOCawr7BvAOOokf1MxV/YfzGozGMlQqONwzWAwX4ncKC /nXJG3Y0TAtXHF9nfHt4uAcbT4kTz2qq93GvWmCnc4dVAbxzxOa5X7hzXxE8ZL9MjPgK 96QwGoBMih9KukV4eMyo8wb/ttKY6cgvwkS4w= MIME-Version: 1.0 Received: by 10.181.28.15 with SMTP id f15mr1662367bkj.75.1235424234417; Mon, 23 Feb 2009 13:23:54 -0800 (PST) In-Reply-To: <49A30AE5.6060307@gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <49A30AE5.6060307@gmail.com> Date: Mon, 23 Feb 2009 22:23:54 +0100 Message-ID: <53cd6c2e0902231323p641cd6d4s99d5f97a0340c4c2@mail.gmail.com> From: Jesrad To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:23:38 -0000 > How then would the soccer ball on my server be able to affect the soccer > goal on your server? In Solipsis, a completely decentralized VW, congruent nodes (servers) with dynamic objects keep each other up to date with the movements of those if they are close enough. Objects then determine if they hit the other object and react accordingly: each soccer ball is told about the other's position in real time. On Mon, Feb 23, 2009 at 9:45 PM, Jon Watte wrote: > Jesrad wrote: >> >> Imagine for a second that the cross-grid protocol mandate somehow that >> objects made on one grid be hosted and served to clients from this >> grid, and not transfered to other grid servers / simulators (though >> the owner may have the third-party possibility of exporting from one >> and importing to another so it is hosted multiple times and thus >> exists in multiple instances). >> >> > > How then would the soccer ball on my server be able to affect the soccer > goal on your server? If only the clients know about the entities from the 2 > servers, your "goal" object on your server would never detect the presence > of the "ball" object within its "goal zone." > > This is why I believe that direct client distribution is not actually the > right model. > > Sincerely, > > jw > > From cs@comlounge.net Mon Feb 23 13:24:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA813A6A76 for ; Mon, 23 Feb 2009 13:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul3lOW9Js-k4 for ; Mon, 23 Feb 2009 13:24:31 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 9DDAE3A6882 for ; Mon, 23 Feb 2009 13:24:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 467EE1CE0248; Mon, 23 Feb 2009 22:24:48 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITDrPyDBcOvu; Mon, 23 Feb 2009 22:24:47 +0100 (CET) Received: from [192.168.178.40] (pD9EBD4A1.dip.t-dialin.net [217.235.212.161]) by post.comlounge.net (Postfix) with ESMTP id 7319C1CE0110; Mon, 23 Feb 2009 22:24:43 +0100 (CET) Message-ID: <49A31417.4000500@comlounge.net> Date: Mon, 23 Feb 2009 22:24:39 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jon Watte References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <49A310E2.2040706@gmail.com> In-Reply-To: <49A310E2.2040706@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] DRM, Permissions, Openness and Leftism: A grand unified theory X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:24:32 -0000 Jon Watte schrieb: > Gareth Nelson wrote: >> Possible actions: >> Copy >> Modify >> Transfer >> Transfer for cash >> >> > > :"Transfer" and "transfer for cash" really aren't different operations. > How two entities choose to transfer is up to them. From the point of > view of the originating system, a "transfer" means that the "owner" > field changes from A to B. It may be that you want "conditional > transfer," where there is some URL that needs to return "true" for the > transfer to complete; that URL could then affect a sale transaction, or > it could do something totally different (like signing a "guest book" or > checking against a "black list"). The reason "Transfer for cash" is in there because of events where some full-mod objects which are not meant to be sold were being sold by the new owner. So in fact it might be some condition but I am not pro URLs which perform some check. The reason for this is that when I buy an object I want to know what the rules are. If there is a function under somebody else' control which determines if an object can be transferred to entity X than I cannot be sure of the rules unless I very much trust the entity controlling that URL. Also what happenes if the server hosting that URL goes out of business? Can I then still use the object at all? Because of that I would find a solution better which is self-contained and carries all information necessary. The "transfer for cash" is also more or less a licensing question which IMHO should be dealt with an attached license blurb (GPL, CC whatever). I don't think anyway that we can model all license questions into technical solutions. That being said I am also for a flexible way of attaching such data so that we can support multiple permission or licensing schemes. It's then up to the entity providing data to define which schemes they support. In order to be able to interoperate we of course need at least a basic set which MUST be supported (or we end up with the ability of only exchanging objects which are public domainish). There are of course not only permissions which can be attached as metadata but potentially a lot more (dublin core etc.). > Does "Copy" mean that the originating system creates a new object > instance, with a potentially new owner? > > And I think you may end up with cases where I get a copy of some object > you've made. That means that there's an object on your system that has > me as the marked owner. I may not actually be a customer at all of your > system, so it may be that your system doesn't want to allow me to do > that. Or, if they feel that hosting objects for non-customers isn't a > problem for one reason or another, they could allow that. (There are > some business models where this makes sense; for example where I can't > instantiate an object unless I'm in an area on that server, and I can't > be in an area on that server unless someone is paying for the machine time) We probable run into discussions whether objects should be passed as a whole copy from server A to B or as just a reference (and maybe just metadata passed). But I might again have a problem with the fact that server A could go out of business leaving me with unusable objects (like certain ebook servers going down.. ). > Is there a difference between "modify" as in changing properties of an > existing object, versus "read source" as in extracting behavior or > presentation specifics (meshes, scripts, etc), versus "derive" as in > creating a new object that references the original object with some > potential overrides? > > And are we talking "objects" vs "object blueprints" here? Is it the case > that any object is actually a "blueprint," and there's no templating > system in SL? I know that many other systems make an explicit division > into "instances" vs "blueprints" (or "templates"). An "instance" starts > out as the template, but can override some set of properties -- for > example, the "position" property would typically always be overridden :-) > > You also need to specify leftism/stickiness. If you allow "copy" or > "derive," then some licenses say that any copy so created must also > allow "copy" and "derive." Other licenses say that a "copy" could have > its permissions changed. Similarly, a "transfer" may be made in terms of > ownership of the particular instance, OR it may be made in terms of > source right -- and, in that case, the source rights may be with or > without sub-source-right permissions. > > > I think we can capture this by making these changes: > 1) specify the "template," if any, of the object > 2) specify whether each permission field is "inherited," "revoked" or > "immutable" on transfer > 3) add the "view" and/or "derive" permission bit > > Specifically, the left-ism licenses would favor setting the "copy" and > "view/derive" bits, and set them with "immutable" semantics. A right-ism > license might specify "copy" with "revoke" -- you can't re-copy > something that's been copied. Of course, if it's "transferred" then that > bit probably shouldn't be revoked, so it might be there's a matrix of > what happens to each permission bit under each operation. > > An additional meta-bit on each operation might be "only when managed by > DRM" -- the "copy" bit might say "allowed only when under DRM," and then > there's a separate list that identifies the allowed DRM models (so that > the source can provide trust or not). As long as the DRM trust chain is > unbroken, and the object originates in a DRM system, that would allow a > "fully secure" DRM model. > > Personally, I think that this could, and should, be done, and that it > serves the desires of all the parts of the spectrum. The "open" grid > needs to identify itself as NOT supporting DRM, and then the "closed" > grid will not send the data. If the "open" grid tries to impersonate a > "closed" grid, then it's up to the specific DRM schemes to use > signatures or whatnot to smoke out the impostor; that capability is very > common with distributed DRM schemes and there are technical solutions > available, should you want them. As said, I really would like to have a more abstract mechanism of attaching metadata with various schemes. The scheme you describe could then be one of them. Having an extensible mechanism might also be more future proof then. -- Christian -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From RGehorsam@forterrainc.com Mon Feb 23 13:30:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AC6A3A67E6 for ; Mon, 23 Feb 2009 13:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL9tEK+KXwT9 for ; Mon, 23 Feb 2009 13:30:00 -0800 (PST) Received: from smtp.forterrainc.com (smtp.forterrainc.com [208.64.184.34]) by core3.amsl.com (Postfix) with ESMTP id 30CD83A67E2 for ; Mon, 23 Feb 2009 13:30:00 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Feb 2009 13:30:23 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com> In-Reply-To: <49A311BC.90405@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mmox] Learning from the past; focusing on the future thread-index: AcmV++FCqr2SCKnDSNOd5vSpvKX5YAAADtbA References: <49A2500F.3000104@gmail.com> <49A311BC.90405@gmail.com> From: "Robert Gehorsam" To: "Jon Watte" , "Morgaine" Cc: Mystical Demina , mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:30:01 -0000 I think part of the issue here with regard to the debate between broad and narrow interoperability is that, other than Jon representing Forterra's technical efforts, there are no other visibly participating technical representatives from any other virtual world technology providers or other relevant groups. No one from Sun, Qwaq, Multiverse, HiPiHi, Activeworlds, any of the browser-based folks, Twinity, any of the game folks or kids worlds, Makena (the company that, contrary to some folks' assertions, is the company that makes and operates There.com), Proton Media, Icarus or its various partners, ECS, and so forth. I've seen references to Qwaq but haven't seen Greg or anyone else from there participating here. There are probably two dozen companies that would be reasonable candidates for this discussion, not to mention companies like Adobe, Google, Intel, Samsung, Sony and, yes, even Microsoft, all of which might arguably have some interesting contributions to make. It may be that this lack of broad participation is creating -- fairly or unfairly -- the sense that the conversation will naturally drift towards an SL-OS orientation -- despite what I see as the best intentions of many people here -- simply because, other than Forterra, no one else is stepping up to the plate. I can tell you that *that* is not something that Forterra wants to see, because it's inherent in our view of the evolution of the internet that interoperability between diverse virtual worlds is essential for all to succeed. So the imbalance in this ongoing discussion creates a false dynamic of conflict when none is intended. Without broad input, how can we achieve broad interoperability? =20 Is there any outreach going on to these various organizations, or is that somehow not part of the policy? Not being really familiar with the workings of these sorts of technical groups, I just don't know. Robert -----Original Message----- From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of Jon Watte Sent: Monday, February 23, 2009 4:15 PM To: Morgaine Cc: Mystical Demina; mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future Morgaine wrote: > I can't understand why you continue to raise the spectre that we're=20 > here to rubberstamp SL standards. We aren't. I'm not aware of=20 > anybody with that agenda. > Because there are several people on this list who say "OpenSim and Second Life are already trying to do client interoperability; I think we should run with it and not worry about something bigger." Similarly, I find that the current OGP proposal specifies some thing ("Rezzing" of avatars) that are Second Life centric, while not specifying other things that would be necessary for an actually useful interoperable virtual world (like entity telemetry). Similarly, if OGP is specified as a mostly empty vessel that can contain arbitrary negotiated data, what would probably happen would be that OpenSim puts OpenSim data in that vessel, and IMVU puts IMVU data in that vessel, and both claim to support "OGP interoperability" but you can't do anything useful through that claim. I want to avoid that outcome. > > We are working in good faith towards your item 2), while noting that=20 > item 2) means interop with "all" reasonable worlds, and that includes=20 > Linden worlds. It's not either/or, it's both. Please grant us that,=20 > so that we can actually make headway. > > /(Proviso: your item 2) says /*single ... simulation*/, which is=20 > incorrect, as we have no remit to straightjacket diverse worlds into a > single simulation.)/ What I mean by "single simulation" is what the user sees when connected to a specific, interoperating instance. I suppose the user could be connected to multiple of those, similar to opening multiple video streams in a media player, but then those generally have "nothing" to do with each other. Okay, so if most of us agree on 2), can we just say we have "rough consensus" on that, and politely reject any attempt to steer the work towards 1)? Sincerely, jw _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox From dcolivares@gmail.com Mon Feb 23 13:35:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C1128C0FB for ; Mon, 23 Feb 2009 13:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRZvGPWRhcHv for ; Mon, 23 Feb 2009 13:35:20 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 144DC3A67E6 for ; Mon, 23 Feb 2009 13:35:19 -0800 (PST) Received: by fxm11 with SMTP id 11so2243756fxm.13 for ; Mon, 23 Feb 2009 13:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5p8PwFq2YwUe4N2pjJ9+nYE9bq+gspOUIheVActreO0=; b=n1pKOHiS+pKcTvWKynBrNmJNXvwCmaA/CHgqghPmXqsN5b81fxvqYbfO7QxSG9gg2H 61V1DV/x6mG/UmT6UQHRheYiS4cLcIib2ppZuYlneDUL7DygLHnAP4pkDQUiovT/GC0O bH8aweHtKN2c8W/3IODnCKtWkpXK03AzXdYUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=V8jEDPR/oDb6/9YPCFWxBpqBAtnePBQiWgNwohaNj81L0WaDky7gL/+aG7aYw/mf+J Konf3G7xmhafhB4cdtJNr6y7/ycdqwepmxxejIWeWgp+LNx7jqKoeeZFRwf8vSVGLhpR mjK4RNpnsRMwTEgFwtxSwq73DI6nx0f9Bktu4= MIME-Version: 1.0 Received: by 10.103.160.9 with SMTP id m9mr1773406muo.53.1235424936759; Mon, 23 Feb 2009 13:35:36 -0800 (PST) In-Reply-To: <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com> References: <49A2500F.3000104@gmail.com> <49A311BC.90405@gmail.com> <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com> Date: Mon, 23 Feb 2009 16:35:36 -0500 Message-ID: From: Dan Olivares To: Robert Gehorsam Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, Mystical Demina , Jon Watte Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:35:22 -0000 I completely agree with you here. Therefore, if this working group is important to you (or anyone else here), I urge you to solicit parties that you feel could make a significant contribution to a MMO/VW standard. Best Regards Daniel Olivares On Mon, Feb 23, 2009 at 4:30 PM, Robert Gehorsam wrote: > I think part of the issue here with regard to the debate between broad > and narrow interoperability is that, other than Jon representing > Forterra's technical efforts, there are no other visibly participating > technical representatives from any other virtual world technology > providers or other relevant groups. No one from Sun, Qwaq, Multiverse, > HiPiHi, Activeworlds, any of the browser-based folks, Twinity, any of > the game folks or kids worlds, Makena (the company that, contrary to > some folks' assertions, is the company that makes and operates > There.com), Proton Media, Icarus or its various partners, ECS, and so > forth. I've seen references to Qwaq but haven't seen Greg or anyone > else from there participating here. There are probably two dozen > companies that would be reasonable candidates for this discussion, not > to mention companies like Adobe, Google, Intel, Samsung, Sony and, yes, > even Microsoft, all of which might arguably have some interesting > contributions to make. > > It may be that this lack of broad participation is creating -- fairly or > unfairly -- the sense that the conversation will naturally drift towards > an SL-OS orientation -- despite what I see as the best intentions of > many people here -- simply because, other than Forterra, no one else is > stepping up to the plate. I can tell you that *that* is not something > that Forterra wants to see, because it's inherent in our view of the > evolution of the internet that interoperability between diverse virtual > worlds is essential for all to succeed. So the imbalance in this > ongoing discussion creates a false dynamic of conflict when none is > intended. Without broad input, how can we achieve broad > interoperability? > > Is there any outreach going on to these various organizations, or is > that somehow not part of the policy? Not being really familiar with the > workings of these sorts of technical groups, I just don't know. > > Robert > > -----Original Message----- > From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of > Jon Watte > Sent: Monday, February 23, 2009 4:15 PM > To: Morgaine > Cc: Mystical Demina; mmox@ietf.org > Subject: Re: [mmox] Learning from the past; focusing on the future > > Morgaine wrote: >> I can't understand why you continue to raise the spectre that we're >> here to rubberstamp SL standards. We aren't. I'm not aware of >> anybody with that agenda. >> > > Because there are several people on this list who say "OpenSim and > Second Life are already trying to do client interoperability; I think we > should run with it and not worry about something bigger." > Similarly, I find that the current OGP proposal specifies some thing > ("Rezzing" of avatars) that are Second Life centric, while not > specifying other things that would be necessary for an actually useful > interoperable virtual world (like entity telemetry). > > Similarly, if OGP is specified as a mostly empty vessel that can contain > arbitrary negotiated data, what would probably happen would be that > OpenSim puts OpenSim data in that vessel, and IMVU puts IMVU data in > that vessel, and both claim to support "OGP interoperability" but you > can't do anything useful through that claim. I want to avoid that > outcome. >> >> We are working in good faith towards your item 2), while noting that >> item 2) means interop with "all" reasonable worlds, and that includes >> Linden worlds. It's not either/or, it's both. Please grant us that, >> so that we can actually make headway. >> >> /(Proviso: your item 2) says /*single ... simulation*/, which is >> incorrect, as we have no remit to straightjacket diverse worlds into a > >> single simulation.)/ > > What I mean by "single simulation" is what the user sees when connected > to a specific, interoperating instance. I suppose the user could be > connected to multiple of those, similar to opening multiple video > streams in a media player, but then those generally have "nothing" to do > with each other. > > > Okay, so if most of us agree on 2), can we just say we have "rough > consensus" on that, and politely reject any attempt to steer the work > towards 1)? > > > Sincerely, > > jw > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From RGehorsam@forterrainc.com Mon Feb 23 13:40:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7EF3A68E0 for ; Mon, 23 Feb 2009 13:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4b4xWaJW9Oi for ; Mon, 23 Feb 2009 13:40:06 -0800 (PST) Received: from smtp.forterrainc.com (smtp.forterrainc.com [208.64.184.34]) by core3.amsl.com (Postfix) with ESMTP id 4DE2D3A63D3 for ; Mon, 23 Feb 2009 13:40:06 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C995FF.77E58760" Date: Mon, 23 Feb 2009 13:41:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C9E@MERCURY.forterrainc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mmox] Learning from the past; focusing on the future thread-index: AcmV/s1vIJumrnzXTye/waEuObs32AAAHvJ9 From: "Robert Gehorsam" To: Cc: mmox@ietf.org, MysticalDemina@xrgrid.com, jwatte@gmail.com Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:40:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C995FF.77E58760 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGFuIC0gDQoNClRoYW5rcy4gIE9uIGl0Lg0KDQpSb2JlcnQNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IERhbiBPbGl2YXJlcyA8ZGNvbGl2YXJlc0BnbWFpbC5jb20+DQpUbzog Um9iZXJ0IEdlaG9yc2FtDQpDQzogSm9uIFdhdHRlIDxqd2F0dGVAZ21haWwuY29tPjsgTW9yZ2Fp bmUgPG1vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbT47IE15c3RpY2FsIERlbWluYSA8TXlz dGljYWxEZW1pbmFAeHJncmlkLmNvbT47IG1tb3hAaWV0Zi5vcmcgPG1tb3hAaWV0Zi5vcmc+DQpT ZW50OiBNb24gRmViIDIzIDEzOjM1OjM2IDIwMDkNClN1YmplY3Q6IFJlOiBbbW1veF0gTGVhcm5p bmcgZnJvbSB0aGUgcGFzdDsgZm9jdXNpbmcgb24gdGhlIGZ1dHVyZQ0KDQpJIGNvbXBsZXRlbHkg YWdyZWUgd2l0aCB5b3UgaGVyZS4gICBUaGVyZWZvcmUsIGlmIHRoaXMgd29ya2luZyBncm91cA0K aXMgaW1wb3J0YW50IHRvIHlvdSAob3IgYW55b25lIGVsc2UgaGVyZSksIEkgdXJnZSB5b3UgdG8g c29saWNpdA0KcGFydGllcyB0aGF0IHlvdSBmZWVsIGNvdWxkIG1ha2UgYSBzaWduaWZpY2FudCBj b250cmlidXRpb24gdG8gYQ0KTU1PL1ZXIHN0YW5kYXJkLg0KDQpCZXN0IFJlZ2FyZHMNCg0KRGFu aWVsIE9saXZhcmVzDQoNCk9uIE1vbiwgRmViIDIzLCAyMDA5IGF0IDQ6MzAgUE0sIFJvYmVydCBH ZWhvcnNhbQ0KPFJHZWhvcnNhbUBmb3J0ZXJyYWluYy5jb20+IHdyb3RlOg0KPiBJIHRoaW5rIHBh cnQgb2YgdGhlIGlzc3VlIGhlcmUgd2l0aCByZWdhcmQgdG8gdGhlIGRlYmF0ZSBiZXR3ZWVuIGJy b2FkDQo+IGFuZCBuYXJyb3cgaW50ZXJvcGVyYWJpbGl0eSBpcyB0aGF0LCBvdGhlciB0aGFuIEpv biByZXByZXNlbnRpbmcNCj4gRm9ydGVycmEncyB0ZWNobmljYWwgZWZmb3J0cywgdGhlcmUgYXJl IG5vIG90aGVyIHZpc2libHkgcGFydGljaXBhdGluZw0KPiB0ZWNobmljYWwgcmVwcmVzZW50YXRp dmVzIGZyb20gYW55IG90aGVyIHZpcnR1YWwgd29ybGQgdGVjaG5vbG9neQ0KPiBwcm92aWRlcnMg b3Igb3RoZXIgcmVsZXZhbnQgZ3JvdXBzLiAgTm8gb25lIGZyb20gU3VuLCBRd2FxLCBNdWx0aXZl cnNlLA0KPiBIaVBpSGksIEFjdGl2ZXdvcmxkcywgYW55IG9mIHRoZSBicm93c2VyLWJhc2VkIGZv bGtzLCBUd2luaXR5LCBhbnkgb2YNCj4gdGhlIGdhbWUgZm9sa3Mgb3Iga2lkcyB3b3JsZHMsIE1h a2VuYSAodGhlIGNvbXBhbnkgdGhhdCwgY29udHJhcnkgdG8NCj4gc29tZSBmb2xrcycgYXNzZXJ0 aW9ucywgaXMgdGhlIGNvbXBhbnkgdGhhdCBtYWtlcyBhbmQgb3BlcmF0ZXMNCj4gVGhlcmUuY29t KSwgUHJvdG9uIE1lZGlhLCBJY2FydXMgb3IgaXRzIHZhcmlvdXMgcGFydG5lcnMsIEVDUywgYW5k IHNvDQo+IGZvcnRoLiAgIEkndmUgc2VlbiByZWZlcmVuY2VzIHRvIFF3YXEgYnV0IGhhdmVuJ3Qg c2VlbiBHcmVnIG9yIGFueW9uZQ0KPiBlbHNlIGZyb20gdGhlcmUgcGFydGljaXBhdGluZyBoZXJl LiAgIFRoZXJlIGFyZSBwcm9iYWJseSB0d28gZG96ZW4NCj4gY29tcGFuaWVzIHRoYXQgd291bGQg YmUgcmVhc29uYWJsZSBjYW5kaWRhdGVzIGZvciB0aGlzIGRpc2N1c3Npb24sIG5vdA0KPiB0byBt ZW50aW9uIGNvbXBhbmllcyBsaWtlIEFkb2JlLCBHb29nbGUsIEludGVsLCBTYW1zdW5nLCBTb255 IGFuZCwgeWVzLA0KPiBldmVuIE1pY3Jvc29mdCwgYWxsIG9mIHdoaWNoIG1pZ2h0IGFyZ3VhYmx5 IGhhdmUgc29tZSBpbnRlcmVzdGluZw0KPiBjb250cmlidXRpb25zIHRvIG1ha2UuDQo+DQo+IEl0 IG1heSBiZSB0aGF0IHRoaXMgbGFjayBvZiBicm9hZCBwYXJ0aWNpcGF0aW9uIGlzIGNyZWF0aW5n IC0tIGZhaXJseSBvcg0KPiB1bmZhaXJseSAtLSB0aGUgc2Vuc2UgdGhhdCB0aGUgY29udmVyc2F0 aW9uIHdpbGwgbmF0dXJhbGx5IGRyaWZ0IHRvd2FyZHMNCj4gYW4gU0wtT1Mgb3JpZW50YXRpb24g LS0gZGVzcGl0ZSB3aGF0IEkgc2VlIGFzIHRoZSBiZXN0IGludGVudGlvbnMgb2YNCj4gbWFueSBw ZW9wbGUgaGVyZSAtLSBzaW1wbHkgYmVjYXVzZSwgb3RoZXIgdGhhbiBGb3J0ZXJyYSwgbm8gb25l IGVsc2UgaXMNCj4gc3RlcHBpbmcgdXAgdG8gdGhlIHBsYXRlLiAgIEkgY2FuIHRlbGwgeW91IHRo YXQgKnRoYXQqIGlzIG5vdCBzb21ldGhpbmcNCj4gdGhhdCBGb3J0ZXJyYSB3YW50cyB0byBzZWUs IGJlY2F1c2UgaXQncyBpbmhlcmVudCBpbiBvdXIgdmlldyBvZiB0aGUNCj4gZXZvbHV0aW9uIG9m IHRoZSBpbnRlcm5ldCB0aGF0IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBkaXZlcnNlIHZpcnR1 YWwNCj4gd29ybGRzIGlzIGVzc2VudGlhbCBmb3IgYWxsIHRvIHN1Y2NlZWQuICBTbyB0aGUgaW1i YWxhbmNlIGluIHRoaXMNCj4gb25nb2luZyBkaXNjdXNzaW9uIGNyZWF0ZXMgYSBmYWxzZSBkeW5h bWljIG9mIGNvbmZsaWN0IHdoZW4gbm9uZSBpcw0KPiBpbnRlbmRlZC4gIFdpdGhvdXQgYnJvYWQg aW5wdXQsIGhvdyBjYW4gd2UgYWNoaWV2ZSBicm9hZA0KPiBpbnRlcm9wZXJhYmlsaXR5Pw0KPg0K PiBJcyB0aGVyZSBhbnkgb3V0cmVhY2ggZ29pbmcgb24gdG8gdGhlc2UgdmFyaW91cyBvcmdhbml6 YXRpb25zLCBvciBpcw0KPiB0aGF0IHNvbWVob3cgbm90IHBhcnQgb2YgdGhlIHBvbGljeT8gIE5v dCBiZWluZyByZWFsbHkgZmFtaWxpYXIgd2l0aCB0aGUNCj4gd29ya2luZ3Mgb2YgdGhlc2Ugc29y dHMgb2YgdGVjaG5pY2FsIGdyb3VwcywgSSBqdXN0IGRvbid0IGtub3cuDQo+DQo+IFJvYmVydA0K Pg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtbW94LWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzptbW94LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBKb24g V2F0dGUNCj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAyMywgMjAwOSA0OjE1IFBNDQo+IFRvOiBN b3JnYWluZQ0KPiBDYzogTXlzdGljYWwgRGVtaW5hOyBtbW94QGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBbbW1veF0gTGVhcm5pbmcgZnJvbSB0aGUgcGFzdDsgZm9jdXNpbmcgb24gdGhlIGZ1dHVy ZQ0KPg0KPiBNb3JnYWluZSB3cm90ZToNCj4+IEkgY2FuJ3QgdW5kZXJzdGFuZCB3aHkgeW91IGNv bnRpbnVlIHRvIHJhaXNlIHRoZSBzcGVjdHJlIHRoYXQgd2UncmUNCj4+IGhlcmUgdG8gcnViYmVy c3RhbXAgU0wgc3RhbmRhcmRzLiAgV2UgYXJlbid0LiAgSSdtIG5vdCBhd2FyZSBvZg0KPj4gYW55 Ym9keSB3aXRoIHRoYXQgYWdlbmRhLg0KPj4NCj4NCj4gQmVjYXVzZSB0aGVyZSBhcmUgc2V2ZXJh bCBwZW9wbGUgb24gdGhpcyBsaXN0IHdobyBzYXkgIk9wZW5TaW0gYW5kDQo+IFNlY29uZCBMaWZl IGFyZSBhbHJlYWR5IHRyeWluZyB0byBkbyBjbGllbnQgaW50ZXJvcGVyYWJpbGl0eTsgSSB0aGlu ayB3ZQ0KPiBzaG91bGQgcnVuIHdpdGggaXQgYW5kIG5vdCB3b3JyeSBhYm91dCBzb21ldGhpbmcg YmlnZ2VyLiINCj4gU2ltaWxhcmx5LCBJIGZpbmQgdGhhdCB0aGUgY3VycmVudCBPR1AgcHJvcG9z YWwgc3BlY2lmaWVzIHNvbWUgdGhpbmcNCj4gKCJSZXp6aW5nIiBvZiBhdmF0YXJzKSB0aGF0IGFy ZSBTZWNvbmQgTGlmZSBjZW50cmljLCB3aGlsZSBub3QNCj4gc3BlY2lmeWluZyBvdGhlciB0aGlu Z3MgdGhhdCB3b3VsZCBiZSBuZWNlc3NhcnkgZm9yIGFuIGFjdHVhbGx5IHVzZWZ1bA0KPiBpbnRl cm9wZXJhYmxlIHZpcnR1YWwgd29ybGQgKGxpa2UgZW50aXR5IHRlbGVtZXRyeSkuDQo+DQo+IFNp bWlsYXJseSwgaWYgT0dQIGlzIHNwZWNpZmllZCBhcyBhIG1vc3RseSBlbXB0eSB2ZXNzZWwgdGhh dCBjYW4gY29udGFpbg0KPiBhcmJpdHJhcnkgbmVnb3RpYXRlZCBkYXRhLCB3aGF0IHdvdWxkIHBy b2JhYmx5IGhhcHBlbiB3b3VsZCBiZSB0aGF0DQo+IE9wZW5TaW0gcHV0cyBPcGVuU2ltIGRhdGEg aW4gdGhhdCB2ZXNzZWwsIGFuZCBJTVZVIHB1dHMgSU1WVSBkYXRhIGluDQo+IHRoYXQgdmVzc2Vs LCBhbmQgYm90aCBjbGFpbSB0byBzdXBwb3J0ICJPR1AgaW50ZXJvcGVyYWJpbGl0eSIgYnV0IHlv dQ0KPiBjYW4ndCBkbyBhbnl0aGluZyB1c2VmdWwgdGhyb3VnaCB0aGF0IGNsYWltLiBJIHdhbnQg dG8gYXZvaWQgdGhhdA0KPiBvdXRjb21lLg0KPj4NCj4+IFdlIGFyZSB3b3JraW5nIGluIGdvb2Qg ZmFpdGggdG93YXJkcyB5b3VyIGl0ZW0gMiksIHdoaWxlIG5vdGluZyB0aGF0DQo+PiBpdGVtIDIp IG1lYW5zIGludGVyb3Agd2l0aCAiYWxsIiByZWFzb25hYmxlIHdvcmxkcywgYW5kIHRoYXQgaW5j bHVkZXMNCj4+IExpbmRlbiB3b3JsZHMuICBJdCdzIG5vdCBlaXRoZXIvb3IsIGl0J3MgYm90aC4g IFBsZWFzZSBncmFudCB1cyB0aGF0LA0KPj4gc28gdGhhdCB3ZSBjYW4gYWN0dWFsbHkgbWFrZSBo ZWFkd2F5Lg0KPj4NCj4+IC8oUHJvdmlzbzogeW91ciBpdGVtIDIpIHNheXMgLypzaW5nbGUgLi4u IHNpbXVsYXRpb24qLywgd2hpY2ggaXMNCj4+IGluY29ycmVjdCwgYXMgd2UgaGF2ZSBubyByZW1p dCB0byBzdHJhaWdodGphY2tldCBkaXZlcnNlIHdvcmxkcyBpbnRvIGENCj4NCj4+IHNpbmdsZSBz aW11bGF0aW9uLikvDQo+DQo+IFdoYXQgSSBtZWFuIGJ5ICJzaW5nbGUgc2ltdWxhdGlvbiIgaXMg d2hhdCB0aGUgdXNlciBzZWVzIHdoZW4gY29ubmVjdGVkDQo+IHRvIGEgc3BlY2lmaWMsIGludGVy b3BlcmF0aW5nIGluc3RhbmNlLiBJIHN1cHBvc2UgdGhlIHVzZXIgY291bGQgYmUNCj4gY29ubmVj dGVkIHRvIG11bHRpcGxlIG9mIHRob3NlLCBzaW1pbGFyIHRvIG9wZW5pbmcgbXVsdGlwbGUgdmlk ZW8NCj4gc3RyZWFtcyBpbiBhIG1lZGlhIHBsYXllciwgYnV0IHRoZW4gdGhvc2UgZ2VuZXJhbGx5 IGhhdmUgIm5vdGhpbmciIHRvIGRvDQo+IHdpdGggZWFjaCBvdGhlci4NCj4NCj4NCj4gT2theSwg c28gaWYgbW9zdCBvZiB1cyBhZ3JlZSBvbiAyKSwgY2FuIHdlIGp1c3Qgc2F5IHdlIGhhdmUgInJv dWdoDQo+IGNvbnNlbnN1cyIgb24gdGhhdCwgYW5kIHBvbGl0ZWx5IHJlamVjdCBhbnkgYXR0ZW1w dCB0byBzdGVlciB0aGUgd29yaw0KPiB0b3dhcmRzIDEpPw0KPg0KPg0KPiBTaW5jZXJlbHksDQo+ DQo+IGp3DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IG1tb3ggbWFpbGluZyBsaXN0DQo+IG1tb3hAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbW94DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1tb3ggbWFpbGluZyBsaXN0DQo+IG1tb3hA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbW94DQo+ DQo= ------_=_NextPart_001_01C995FF.77E58760 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTIuMjQiPg0KPFRJVExFPlJlOiBbbW1veF0g TGVhcm5pbmcgZnJvbSB0aGUgcGFzdDsgZm9jdXNpbmcgb24gdGhlIGZ1dHVyZTwvVElUTEU+DQo8 L0hFQUQ+DQo8Qk9EWT4NCjwhLS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+ DQoNCjxQPjxGT05UIFNJWkU9Mj5EYW4gLTxCUj4NCjxCUj4NClRoYW5rcy4mbmJzcDsgT24gaXQu PEJSPg0KPEJSPg0KUm9iZXJ0PEJSPg0KPEJSPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 QlI+DQpGcm9tOiBEYW4gT2xpdmFyZXMgJmx0O2Rjb2xpdmFyZXNAZ21haWwuY29tJmd0OzxCUj4N ClRvOiBSb2JlcnQgR2Vob3JzYW08QlI+DQpDQzogSm9uIFdhdHRlICZsdDtqd2F0dGVAZ21haWwu Y29tJmd0OzsgTW9yZ2FpbmUgJmx0O21vcmdhaW5lLmRpbm92YUBnb29nbGVtYWlsLmNvbSZndDs7 IE15c3RpY2FsIERlbWluYSAmbHQ7TXlzdGljYWxEZW1pbmFAeHJncmlkLmNvbSZndDs7IG1tb3hA aWV0Zi5vcmcgJmx0O21tb3hAaWV0Zi5vcmcmZ3Q7PEJSPg0KU2VudDogTW9uIEZlYiAyMyAxMzoz NTozNiAyMDA5PEJSPg0KU3ViamVjdDogUmU6IFttbW94XSBMZWFybmluZyBmcm9tIHRoZSBwYXN0 OyBmb2N1c2luZyBvbiB0aGUgZnV0dXJlPEJSPg0KPEJSPg0KSSBjb21wbGV0ZWx5IGFncmVlIHdp dGggeW91IGhlcmUuJm5ic3A7Jm5ic3A7IFRoZXJlZm9yZSwgaWYgdGhpcyB3b3JraW5nIGdyb3Vw PEJSPg0KaXMgaW1wb3J0YW50IHRvIHlvdSAob3IgYW55b25lIGVsc2UgaGVyZSksIEkgdXJnZSB5 b3UgdG8gc29saWNpdDxCUj4NCnBhcnRpZXMgdGhhdCB5b3UgZmVlbCBjb3VsZCBtYWtlIGEgc2ln bmlmaWNhbnQgY29udHJpYnV0aW9uIHRvIGE8QlI+DQpNTU8vVlcgc3RhbmRhcmQuPEJSPg0KPEJS Pg0KQmVzdCBSZWdhcmRzPEJSPg0KPEJSPg0KRGFuaWVsIE9saXZhcmVzPEJSPg0KPEJSPg0KT24g TW9uLCBGZWIgMjMsIDIwMDkgYXQgNDozMCBQTSwgUm9iZXJ0IEdlaG9yc2FtPEJSPg0KJmx0O1JH ZWhvcnNhbUBmb3J0ZXJyYWluYy5jb20mZ3Q7IHdyb3RlOjxCUj4NCiZndDsgSSB0aGluayBwYXJ0 IG9mIHRoZSBpc3N1ZSBoZXJlIHdpdGggcmVnYXJkIHRvIHRoZSBkZWJhdGUgYmV0d2VlbiBicm9h ZDxCUj4NCiZndDsgYW5kIG5hcnJvdyBpbnRlcm9wZXJhYmlsaXR5IGlzIHRoYXQsIG90aGVyIHRo YW4gSm9uIHJlcHJlc2VudGluZzxCUj4NCiZndDsgRm9ydGVycmEncyB0ZWNobmljYWwgZWZmb3J0 cywgdGhlcmUgYXJlIG5vIG90aGVyIHZpc2libHkgcGFydGljaXBhdGluZzxCUj4NCiZndDsgdGVj aG5pY2FsIHJlcHJlc2VudGF0aXZlcyBmcm9tIGFueSBvdGhlciB2aXJ0dWFsIHdvcmxkIHRlY2hu b2xvZ3k8QlI+DQomZ3Q7IHByb3ZpZGVycyBvciBvdGhlciByZWxldmFudCBncm91cHMuJm5ic3A7 IE5vIG9uZSBmcm9tIFN1biwgUXdhcSwgTXVsdGl2ZXJzZSw8QlI+DQomZ3Q7IEhpUGlIaSwgQWN0 aXZld29ybGRzLCBhbnkgb2YgdGhlIGJyb3dzZXItYmFzZWQgZm9sa3MsIFR3aW5pdHksIGFueSBv ZjxCUj4NCiZndDsgdGhlIGdhbWUgZm9sa3Mgb3Iga2lkcyB3b3JsZHMsIE1ha2VuYSAodGhlIGNv bXBhbnkgdGhhdCwgY29udHJhcnkgdG88QlI+DQomZ3Q7IHNvbWUgZm9sa3MnIGFzc2VydGlvbnMs IGlzIHRoZSBjb21wYW55IHRoYXQgbWFrZXMgYW5kIG9wZXJhdGVzPEJSPg0KJmd0OyBUaGVyZS5j b20pLCBQcm90b24gTWVkaWEsIEljYXJ1cyBvciBpdHMgdmFyaW91cyBwYXJ0bmVycywgRUNTLCBh bmQgc288QlI+DQomZ3Q7IGZvcnRoLiZuYnNwOyZuYnNwOyBJJ3ZlIHNlZW4gcmVmZXJlbmNlcyB0 byBRd2FxIGJ1dCBoYXZlbid0IHNlZW4gR3JlZyBvciBhbnlvbmU8QlI+DQomZ3Q7IGVsc2UgZnJv bSB0aGVyZSBwYXJ0aWNpcGF0aW5nIGhlcmUuJm5ic3A7Jm5ic3A7IFRoZXJlIGFyZSBwcm9iYWJs eSB0d28gZG96ZW48QlI+DQomZ3Q7IGNvbXBhbmllcyB0aGF0IHdvdWxkIGJlIHJlYXNvbmFibGUg Y2FuZGlkYXRlcyBmb3IgdGhpcyBkaXNjdXNzaW9uLCBub3Q8QlI+DQomZ3Q7IHRvIG1lbnRpb24g Y29tcGFuaWVzIGxpa2UgQWRvYmUsIEdvb2dsZSwgSW50ZWwsIFNhbXN1bmcsIFNvbnkgYW5kLCB5 ZXMsPEJSPg0KJmd0OyBldmVuIE1pY3Jvc29mdCwgYWxsIG9mIHdoaWNoIG1pZ2h0IGFyZ3VhYmx5 IGhhdmUgc29tZSBpbnRlcmVzdGluZzxCUj4NCiZndDsgY29udHJpYnV0aW9ucyB0byBtYWtlLjxC Uj4NCiZndDs8QlI+DQomZ3Q7IEl0IG1heSBiZSB0aGF0IHRoaXMgbGFjayBvZiBicm9hZCBwYXJ0 aWNpcGF0aW9uIGlzIGNyZWF0aW5nIC0tIGZhaXJseSBvcjxCUj4NCiZndDsgdW5mYWlybHkgLS0g dGhlIHNlbnNlIHRoYXQgdGhlIGNvbnZlcnNhdGlvbiB3aWxsIG5hdHVyYWxseSBkcmlmdCB0b3dh cmRzPEJSPg0KJmd0OyBhbiBTTC1PUyBvcmllbnRhdGlvbiAtLSBkZXNwaXRlIHdoYXQgSSBzZWUg YXMgdGhlIGJlc3QgaW50ZW50aW9ucyBvZjxCUj4NCiZndDsgbWFueSBwZW9wbGUgaGVyZSAtLSBz aW1wbHkgYmVjYXVzZSwgb3RoZXIgdGhhbiBGb3J0ZXJyYSwgbm8gb25lIGVsc2UgaXM8QlI+DQom Z3Q7IHN0ZXBwaW5nIHVwIHRvIHRoZSBwbGF0ZS4mbmJzcDsmbmJzcDsgSSBjYW4gdGVsbCB5b3Ug dGhhdCAqdGhhdCogaXMgbm90IHNvbWV0aGluZzxCUj4NCiZndDsgdGhhdCBGb3J0ZXJyYSB3YW50 cyB0byBzZWUsIGJlY2F1c2UgaXQncyBpbmhlcmVudCBpbiBvdXIgdmlldyBvZiB0aGU8QlI+DQom Z3Q7IGV2b2x1dGlvbiBvZiB0aGUgaW50ZXJuZXQgdGhhdCBpbnRlcm9wZXJhYmlsaXR5IGJldHdl ZW4gZGl2ZXJzZSB2aXJ0dWFsPEJSPg0KJmd0OyB3b3JsZHMgaXMgZXNzZW50aWFsIGZvciBhbGwg dG8gc3VjY2VlZC4mbmJzcDsgU28gdGhlIGltYmFsYW5jZSBpbiB0aGlzPEJSPg0KJmd0OyBvbmdv aW5nIGRpc2N1c3Npb24gY3JlYXRlcyBhIGZhbHNlIGR5bmFtaWMgb2YgY29uZmxpY3Qgd2hlbiBu b25lIGlzPEJSPg0KJmd0OyBpbnRlbmRlZC4mbmJzcDsgV2l0aG91dCBicm9hZCBpbnB1dCwgaG93 IGNhbiB3ZSBhY2hpZXZlIGJyb2FkPEJSPg0KJmd0OyBpbnRlcm9wZXJhYmlsaXR5PzxCUj4NCiZn dDs8QlI+DQomZ3Q7IElzIHRoZXJlIGFueSBvdXRyZWFjaCBnb2luZyBvbiB0byB0aGVzZSB2YXJp b3VzIG9yZ2FuaXphdGlvbnMsIG9yIGlzPEJSPg0KJmd0OyB0aGF0IHNvbWVob3cgbm90IHBhcnQg b2YgdGhlIHBvbGljeT8mbmJzcDsgTm90IGJlaW5nIHJlYWxseSBmYW1pbGlhciB3aXRoIHRoZTxC Uj4NCiZndDsgd29ya2luZ3Mgb2YgdGhlc2Ugc29ydHMgb2YgdGVjaG5pY2FsIGdyb3VwcywgSSBq dXN0IGRvbid0IGtub3cuPEJSPg0KJmd0OzxCUj4NCiZndDsgUm9iZXJ0PEJSPg0KJmd0OzxCUj4N CiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+DQomZ3Q7IEZyb206IG1tb3gtYm91 bmNlc0BpZXRmLm9yZyBbPEEgSFJFRj0ibWFpbHRvOm1tb3gtYm91bmNlc0BpZXRmLm9yZyI+bWFp bHRvOm1tb3gtYm91bmNlc0BpZXRmLm9yZzwvQT5dIE9uIEJlaGFsZiBPZjxCUj4NCiZndDsgSm9u IFdhdHRlPEJSPg0KJmd0OyBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDIzLCAyMDA5IDQ6MTUgUE08 QlI+DQomZ3Q7IFRvOiBNb3JnYWluZTxCUj4NCiZndDsgQ2M6IE15c3RpY2FsIERlbWluYTsgbW1v eEBpZXRmLm9yZzxCUj4NCiZndDsgU3ViamVjdDogUmU6IFttbW94XSBMZWFybmluZyBmcm9tIHRo ZSBwYXN0OyBmb2N1c2luZyBvbiB0aGUgZnV0dXJlPEJSPg0KJmd0OzxCUj4NCiZndDsgTW9yZ2Fp bmUgd3JvdGU6PEJSPg0KJmd0OyZndDsgSSBjYW4ndCB1bmRlcnN0YW5kIHdoeSB5b3UgY29udGlu dWUgdG8gcmFpc2UgdGhlIHNwZWN0cmUgdGhhdCB3ZSdyZTxCUj4NCiZndDsmZ3Q7IGhlcmUgdG8g cnViYmVyc3RhbXAgU0wgc3RhbmRhcmRzLiZuYnNwOyBXZSBhcmVuJ3QuJm5ic3A7IEknbSBub3Qg YXdhcmUgb2Y8QlI+DQomZ3Q7Jmd0OyBhbnlib2R5IHdpdGggdGhhdCBhZ2VuZGEuPEJSPg0KJmd0 OyZndDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyBCZWNhdXNlIHRoZXJlIGFyZSBzZXZlcmFsIHBlb3Bs ZSBvbiB0aGlzIGxpc3Qgd2hvIHNheSAmcXVvdDtPcGVuU2ltIGFuZDxCUj4NCiZndDsgU2Vjb25k IExpZmUgYXJlIGFscmVhZHkgdHJ5aW5nIHRvIGRvIGNsaWVudCBpbnRlcm9wZXJhYmlsaXR5OyBJ IHRoaW5rIHdlPEJSPg0KJmd0OyBzaG91bGQgcnVuIHdpdGggaXQgYW5kIG5vdCB3b3JyeSBhYm91 dCBzb21ldGhpbmcgYmlnZ2VyLiZxdW90OzxCUj4NCiZndDsgU2ltaWxhcmx5LCBJIGZpbmQgdGhh dCB0aGUgY3VycmVudCBPR1AgcHJvcG9zYWwgc3BlY2lmaWVzIHNvbWUgdGhpbmc8QlI+DQomZ3Q7 ICgmcXVvdDtSZXp6aW5nJnF1b3Q7IG9mIGF2YXRhcnMpIHRoYXQgYXJlIFNlY29uZCBMaWZlIGNl bnRyaWMsIHdoaWxlIG5vdDxCUj4NCiZndDsgc3BlY2lmeWluZyBvdGhlciB0aGluZ3MgdGhhdCB3 b3VsZCBiZSBuZWNlc3NhcnkgZm9yIGFuIGFjdHVhbGx5IHVzZWZ1bDxCUj4NCiZndDsgaW50ZXJv cGVyYWJsZSB2aXJ0dWFsIHdvcmxkIChsaWtlIGVudGl0eSB0ZWxlbWV0cnkpLjxCUj4NCiZndDs8 QlI+DQomZ3Q7IFNpbWlsYXJseSwgaWYgT0dQIGlzIHNwZWNpZmllZCBhcyBhIG1vc3RseSBlbXB0 eSB2ZXNzZWwgdGhhdCBjYW4gY29udGFpbjxCUj4NCiZndDsgYXJiaXRyYXJ5IG5lZ290aWF0ZWQg ZGF0YSwgd2hhdCB3b3VsZCBwcm9iYWJseSBoYXBwZW4gd291bGQgYmUgdGhhdDxCUj4NCiZndDsg T3BlblNpbSBwdXRzIE9wZW5TaW0gZGF0YSBpbiB0aGF0IHZlc3NlbCwgYW5kIElNVlUgcHV0cyBJ TVZVIGRhdGEgaW48QlI+DQomZ3Q7IHRoYXQgdmVzc2VsLCBhbmQgYm90aCBjbGFpbSB0byBzdXBw b3J0ICZxdW90O09HUCBpbnRlcm9wZXJhYmlsaXR5JnF1b3Q7IGJ1dCB5b3U8QlI+DQomZ3Q7IGNh bid0IGRvIGFueXRoaW5nIHVzZWZ1bCB0aHJvdWdoIHRoYXQgY2xhaW0uIEkgd2FudCB0byBhdm9p ZCB0aGF0PEJSPg0KJmd0OyBvdXRjb21lLjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgV2Ug YXJlIHdvcmtpbmcgaW4gZ29vZCBmYWl0aCB0b3dhcmRzIHlvdXIgaXRlbSAyKSwgd2hpbGUgbm90 aW5nIHRoYXQ8QlI+DQomZ3Q7Jmd0OyBpdGVtIDIpIG1lYW5zIGludGVyb3Agd2l0aCAmcXVvdDth bGwmcXVvdDsgcmVhc29uYWJsZSB3b3JsZHMsIGFuZCB0aGF0IGluY2x1ZGVzPEJSPg0KJmd0OyZn dDsgTGluZGVuIHdvcmxkcy4mbmJzcDsgSXQncyBub3QgZWl0aGVyL29yLCBpdCdzIGJvdGguJm5i c3A7IFBsZWFzZSBncmFudCB1cyB0aGF0LDxCUj4NCiZndDsmZ3Q7IHNvIHRoYXQgd2UgY2FuIGFj dHVhbGx5IG1ha2UgaGVhZHdheS48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IC8oUHJvdmlz bzogeW91ciBpdGVtIDIpIHNheXMgLypzaW5nbGUgLi4uIHNpbXVsYXRpb24qLywgd2hpY2ggaXM8 QlI+DQomZ3Q7Jmd0OyBpbmNvcnJlY3QsIGFzIHdlIGhhdmUgbm8gcmVtaXQgdG8gc3RyYWlnaHRq YWNrZXQgZGl2ZXJzZSB3b3JsZHMgaW50byBhPEJSPg0KJmd0OzxCUj4NCiZndDsmZ3Q7IHNpbmds ZSBzaW11bGF0aW9uLikvPEJSPg0KJmd0OzxCUj4NCiZndDsgV2hhdCBJIG1lYW4gYnkgJnF1b3Q7 c2luZ2xlIHNpbXVsYXRpb24mcXVvdDsgaXMgd2hhdCB0aGUgdXNlciBzZWVzIHdoZW4gY29ubmVj dGVkPEJSPg0KJmd0OyB0byBhIHNwZWNpZmljLCBpbnRlcm9wZXJhdGluZyBpbnN0YW5jZS4gSSBz dXBwb3NlIHRoZSB1c2VyIGNvdWxkIGJlPEJSPg0KJmd0OyBjb25uZWN0ZWQgdG8gbXVsdGlwbGUg b2YgdGhvc2UsIHNpbWlsYXIgdG8gb3BlbmluZyBtdWx0aXBsZSB2aWRlbzxCUj4NCiZndDsgc3Ry ZWFtcyBpbiBhIG1lZGlhIHBsYXllciwgYnV0IHRoZW4gdGhvc2UgZ2VuZXJhbGx5IGhhdmUgJnF1 b3Q7bm90aGluZyZxdW90OyB0byBkbzxCUj4NCiZndDsgd2l0aCBlYWNoIG90aGVyLjxCUj4NCiZn dDs8QlI+DQomZ3Q7PEJSPg0KJmd0OyBPa2F5LCBzbyBpZiBtb3N0IG9mIHVzIGFncmVlIG9uIDIp LCBjYW4gd2UganVzdCBzYXkgd2UgaGF2ZSAmcXVvdDtyb3VnaDxCUj4NCiZndDsgY29uc2Vuc3Vz JnF1b3Q7IG9uIHRoYXQsIGFuZCBwb2xpdGVseSByZWplY3QgYW55IGF0dGVtcHQgdG8gc3RlZXIg dGhlIHdvcms8QlI+DQomZ3Q7IHRvd2FyZHMgMSk/PEJSPg0KJmd0OzxCUj4NCiZndDs8QlI+DQom Z3Q7IFNpbmNlcmVseSw8QlI+DQomZ3Q7PEJSPg0KJmd0OyBqdzxCUj4NCiZndDs8QlI+DQomZ3Q7 PEJSPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XzxCUj4NCiZndDsgbW1veCBtYWlsaW5nIGxpc3Q8QlI+DQomZ3Q7IG1tb3hAaWV0Zi5vcmc8QlI+ DQomZ3Q7IDxBIEhSRUY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW1v eCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbW94PC9BPjxCUj4NCiZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+DQom Z3Q7IG1tb3ggbWFpbGluZyBsaXN0PEJSPg0KJmd0OyBtbW94QGlldGYub3JnPEJSPg0KJmd0OyA8 QSBIUkVGPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tb3giPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW1veDwvQT48QlI+DQomZ3Q7PEJSPg0K PC9GT05UPg0KPC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+ ------_=_NextPart_001_01C995FF.77E58760-- From infinity@lindenlab.com Mon Feb 23 13:46:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA53B28C1D0 for ; Mon, 23 Feb 2009 13:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8X5cJjm+owd for ; Mon, 23 Feb 2009 13:46:41 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 047FD28C1AE for ; Mon, 23 Feb 2009 13:46:41 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 468EC1414006; Mon, 23 Feb 2009 13:46:58 -0800 (PST) Message-Id: <2F80CC37-A5BD-4EAD-8E12-D31A21912A8B@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49A30D7A.3040003@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 13:46:58 -0800 References: <49A30D7A.3040003@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:46:41 -0000 Catherine... Jon... can you create a proposal for a next generation XML serialization? the existing serialization is in current use by SL, OpenSim and PyOGP, so there's probably going to be a lot of resistance to changing something that currently works and is deployed. keep in mind, however, that OGP does not use XML to represent it's PDUs, it uses LLSD. XML is one of three defined serializations of LLSD. it's a subtle difference, but important. for instance... is there a benefit to explicitly adding support for namespaces to the XML serialization? there was a bit of discussion about this amongst some AWG members, and the consensus was... "why bother? the XML (presentation layer) is not the place where you want to extend the PDU... you want to extend it in the LLSD / LLIDL definition of the interaction." but, i still think it's an interesting idea as it might allow systems that use XML serialization exclusively to extend display and distribution options of various PDUs. -cheers -m On Feb 23, 2009, at 12:56 PM, Jon Watte wrote: > Catherine Pfeffer wrote: >> >> >> >> success >> true >> >> >> something_i_like_to_eat_on_sundays >> bananas >> >> >> > > A better way is > > > key="something_i_like_to_eat_on_sundays">bananas > > > natural way to express it.This has less of the angle bracket tax, > and it has a VERY straight-forward parsing style. In fact, in my > opinion it's the most In XPath, it's now trivial: > "value[@key=success]" > > > I'm working on a list of the things I think are wrong with the > current proposal, of which this is one thing (there are about six). > If we're open to change on those things (including this), then I > could get behind the LLSD. Stay tuned :-) > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From jwatte@gmail.com Mon Feb 23 13:49:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B863A6A76 for ; Mon, 23 Feb 2009 13:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zUdqybLwiYMD for ; Mon, 23 Feb 2009 13:49:55 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 2ECD23A6A75 for ; Mon, 23 Feb 2009 13:49:54 -0800 (PST) Received: by gxk22 with SMTP id 22so5808908gxk.13 for ; Mon, 23 Feb 2009 13:50:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=x5PqggUci8w9BIo4vW43l9xTys5kXYCvIqBHtFT+RuI=; b=gbopczAKMpTyyVNwMQ33MyuqVD84vlpPmA1CrulN+0qhupyh1rj7/ydqeeR7i2Akby LZ/9CW6As66h2vTKG8GwdkREYOcUewYZXPnRS+X3xssTK4Tm/P4QuajpxQIFyqpknzmG eQcuBhPvUKv0WG5U5e5BZIcBIHWXDdZWuuq20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=veJEJzClSCryuqg/C2dp4A639fxbfeRUOfYLiz6Dz8wgIvxWVFPQy95NlxszEjvR+y YBD1pBGvTFlKh+ujVPOHQTPrU2kGAhj6W1reTAVsRourDUSxask6cfZH+2q3PDImjY4y z72B3q6om6B0ThWRuPXeOoQcXlmrAdOrvAyJs= Received: by 10.100.138.17 with SMTP id l17mr2635275and.2.1235425812612; Mon, 23 Feb 2009 13:50:12 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b32sm702479ana.55.2009.02.23.13.50.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 13:50:11 -0800 (PST) Message-ID: <49A31A11.2000503@gmail.com> Date: Mon, 23 Feb 2009 13:50:09 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dan Olivares References: <20090223.155250.2225.0@webmail24.vgs.untd.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:49:56 -0000 Dan Olivares wrote: > "In the There.com/Forterra context, customer content is cleared > through a centralized clearing house and must be approved by the > company before it can be uploaded; customers are in a subordinate > Just to be clear: There.com (operated by Makena Technologies) and OLIVE (sold by Forterra Systems) are different products, with very different customers and very different processes. There.com has a central clearinghouse. Forterra Systems does not -- each customer of the OLIVE platform decides how and what content goes into their installation. The There.com model is "we provide a PG-13 safe environment with some degree of content protection, and we implement it through a content review system" (and now the iPhone store does the same thing). The OLIVE model is "let the customer decide, although we can help you with that if you need help." Sincerely, jw From jwatte@gmail.com Mon Feb 23 13:53:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B08428C1AE for ; Mon, 23 Feb 2009 13:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwMVkGgV4ciN for ; Mon, 23 Feb 2009 13:53:07 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 63C3E28C18B for ; Mon, 23 Feb 2009 13:53:07 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1174984ana.4 for ; Mon, 23 Feb 2009 13:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ao4FwZCkZdM8BuGDcy/O1MnpLyV4Wnf0XT+WM+HllhY=; b=F3PE0BKYK4H/4mHHQAWveIq6AfCyih3qFHJ10wkJRj8fiSm53VR9CP8wdd8SjRSiPP RUZbq9GnMB2+hXRmWlRRIiHvTEIejmc9p7jUVtcnGgxvR9dQpmv2eu1NAvXrHCQV+6w4 doeDn1g2Q5M8BBW5XBVXrC3cPvNIqtklZMDhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=uKac84Wz4fWMDQfS47wVxylqpQaxh3i5qESQ9p1seJYAJqSAH3iJfE54idD+jnvBO9 ncAULYKpK3Uhiywfeo7VNAx/veYlmMIB87NV49WGoSElUHqpXo3YUnk9jxtlrvR6t7zK ETul1k64W5Fwvhj2ylhFms2ieAzxiFnAOtoao= Received: by 10.100.141.5 with SMTP id o5mr4730400and.53.1235426004962; Mon, 23 Feb 2009 13:53:24 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d35sm9609110and.38.2009.02.23.13.53.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 13:53:24 -0800 (PST) Message-ID: <49A31AD2.40402@gmail.com> Date: Mon, 23 Feb 2009 13:53:22 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jesrad References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <49A30AE5.6060307@gmail.com> <53cd6c2e0902231323p641cd6d4s99d5f97a0340c4c2@mail.gmail.com> In-Reply-To: <53cd6c2e0902231323p641cd6d4s99d5f97a0340c4c2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:53:08 -0000 Jesrad wrote: >> How then would the soccer ball on my server be able to affect the soccer >> goal on your server? >> > > In Solipsis, a completely decentralized VW, congruent nodes (servers) > with dynamic objects keep each other up to date with the movements of > those if they are close enough. Objects then determine if they hit the > other object and react accordingly: each soccer ball is told about the > other's position in real time. > > That's right! That's the model I think will work. What I'm arguing against is the argument that _clients_ connect to multiple servers (in a client/server system); in such as system there is no way that the server object of the soccer goal can know about the other-server object soccer ball. My argument is simply against the idea that a single client connecting to two separate virutal world servers could provide a usefully consistent view of a virtual world simulation. Unless you require the client to serve as proxy/gateway/translator for funneling data between the servers (again, in a c/s system), which would be terrible for both technical, trust and scalability reasons. Sincerely, jw From infinity@lindenlab.com Mon Feb 23 13:54:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A543B28C20B for ; Mon, 23 Feb 2009 13:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzERu+fJ7lan for ; Mon, 23 Feb 2009 13:54:11 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id BC61528C203 for ; Mon, 23 Feb 2009 13:54:11 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 5139D3DBC44F; Mon, 23 Feb 2009 13:54:30 -0800 (PST) Message-Id: <9EF1FD3F-6E1B-471B-B11B-169CA6CFAB7C@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49A31A11.2000503@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 13:54:30 -0800 References: <20090223.155250.2225.0@webmail24.vgs.untd.com> <49A31A11.2000503@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:54:12 -0000 but i believe the sense of the comment was that the end user (distinct from the person who administers the service) is not allowed to upload arbitrary content. my understanding of both OLIVE and there.com is that they both do not allow arbitrary content upload, but instead require someone other than the content creator approve (and transfer) the content. but... i could be wrong. On Feb 23, 2009, at 1:50 PM, Jon Watte wrote: > Dan Olivares wrote: >> "In the There.com/Forterra context, customer content is cleared >> through a centralized clearing house and must be approved by the >> company before it can be uploaded; customers are in a subordinate >> > > Just to be clear: There.com (operated by Makena Technologies) and > OLIVE (sold by Forterra Systems) are different products, with very > different customers and very different processes. There.com has a > central clearinghouse. Forterra Systems does not -- each customer of > the OLIVE platform decides how and what content goes into their > installation. > > The There.com model is "we provide a PG-13 safe environment with > some degree of content protection, and we implement it through a > content review system" (and now the iPhone store does the same thing). > > The OLIVE model is "let the customer decide, although we can help > you with that if you need help." > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From RGehorsam@forterrainc.com Mon Feb 23 13:56:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C9B428C210 for ; Mon, 23 Feb 2009 13:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psVsV+SMTds5 for ; Mon, 23 Feb 2009 13:56:15 -0800 (PST) Received: from smtp.forterrainc.com (smtp.forterrainc.com [208.64.184.34]) by core3.amsl.com (Postfix) with ESMTP id 7FA4028C20B for ; Mon, 23 Feb 2009 13:56:15 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99601.B98A44B0" Date: Mon, 23 Feb 2009 13:57:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C9F@MERCURY.forterrainc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mmox] mmox Digest, Vol 1, Issue 113 thread-index: AcmWAXEoGYcEP9HsRRSJoFwKwx/s+gAABnCA From: "Robert Gehorsam" To: , Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:56:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99601.B98A44B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGtleSBwb2ludCByZWxhdGl2ZSB0byBlYXJsaWVyIGNvbW1lbnRzIGlzIHRoYXQgRm9ydGVy cmEgaXMgTk9UIEVWRVIgdGhlIGNsZWFyaW5naG91c2UgZm9yIGl0cyBjdXN0b21lcnMuLiAgVGhh dCB3YXMgdGhlIGVycm9uZW91cyBhc3N1bXB0aW9uLiAgQW4gYWRtaW5pc3RyYXRvciBjb3VsZCBw cm9iYWJseSBzZXQgd2hhdGV2ZXIgcG9saWN5IHRoZXkgd2FudGVkLg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogbW1veC1ib3VuY2VzQGlldGYub3JnIDxtbW94LWJvdW5jZXNA aWV0Zi5vcmc+DQpUbzogSm9uIFdhdHRlIDxqd2F0dGVAZ21haWwuY29tPg0KQ0M6IG1tb3hAaWV0 Zi5vcmcgPG1tb3hAaWV0Zi5vcmc+OyBkeWVyYnJvb2ttZUBqdW5vLmNvbSA8ZHllcmJyb29rbWVA anVuby5jb20+DQpTZW50OiBNb24gRmViIDIzIDEzOjU0OjMwIDIwMDkNClN1YmplY3Q6IFJlOiBb bW1veF0gbW1veCBEaWdlc3QsIFZvbCAxLCBJc3N1ZSAxMTMNCg0KYnV0IGkgYmVsaWV2ZSB0aGUg c2Vuc2Ugb2YgdGhlIGNvbW1lbnQgd2FzIHRoYXQgdGhlIGVuZCB1c2VyIChkaXN0aW5jdCAgDQpm cm9tIHRoZSBwZXJzb24gd2hvIGFkbWluaXN0ZXJzIHRoZSBzZXJ2aWNlKSBpcyBub3QgYWxsb3dl ZCB0byB1cGxvYWQgIA0KYXJiaXRyYXJ5IGNvbnRlbnQuDQoNCm15IHVuZGVyc3RhbmRpbmcgb2Yg Ym90aCBPTElWRSBhbmQgdGhlcmUuY29tIGlzIHRoYXQgdGhleSBib3RoIGRvIG5vdCAgDQphbGxv dyBhcmJpdHJhcnkgY29udGVudCB1cGxvYWQsIGJ1dCBpbnN0ZWFkIHJlcXVpcmUgc29tZW9uZSBv dGhlciB0aGFuICANCnRoZSBjb250ZW50IGNyZWF0b3IgYXBwcm92ZSAoYW5kIHRyYW5zZmVyKSB0 aGUgY29udGVudC4NCg0KYnV0Li4uIGkgY291bGQgYmUgd3JvbmcuDQoNCk9uIEZlYiAyMywgMjAw OSwgYXQgMTo1MCBQTSwgSm9uIFdhdHRlIHdyb3RlOg0KDQo+IERhbiBPbGl2YXJlcyB3cm90ZToN Cj4+ICJJbiB0aGUgVGhlcmUuY29tL0ZvcnRlcnJhIGNvbnRleHQsIGN1c3RvbWVyIGNvbnRlbnQg aXMgY2xlYXJlZA0KPj4gdGhyb3VnaCBhIGNlbnRyYWxpemVkIGNsZWFyaW5nIGhvdXNlIGFuZCBt dXN0IGJlIGFwcHJvdmVkIGJ5IHRoZQ0KPj4gY29tcGFueSBiZWZvcmUgaXQgY2FuIGJlIHVwbG9h ZGVkOyBjdXN0b21lcnMgYXJlIGluIGEgc3Vib3JkaW5hdGUNCj4+DQo+DQo+IEp1c3QgdG8gYmUg Y2xlYXI6IFRoZXJlLmNvbSAob3BlcmF0ZWQgYnkgTWFrZW5hIFRlY2hub2xvZ2llcykgYW5kICAN Cj4gT0xJVkUgKHNvbGQgYnkgRm9ydGVycmEgU3lzdGVtcykgYXJlIGRpZmZlcmVudCBwcm9kdWN0 cywgd2l0aCB2ZXJ5ICANCj4gZGlmZmVyZW50IGN1c3RvbWVycyBhbmQgdmVyeSBkaWZmZXJlbnQg cHJvY2Vzc2VzLiBUaGVyZS5jb20gaGFzIGEgIA0KPiBjZW50cmFsIGNsZWFyaW5naG91c2UuIEZv cnRlcnJhIFN5c3RlbXMgZG9lcyBub3QgLS0gZWFjaCBjdXN0b21lciBvZiAgDQo+IHRoZSBPTElW RSBwbGF0Zm9ybSBkZWNpZGVzIGhvdyBhbmQgd2hhdCBjb250ZW50IGdvZXMgaW50byB0aGVpciAg DQo+IGluc3RhbGxhdGlvbi4NCj4NCj4gVGhlIFRoZXJlLmNvbSBtb2RlbCBpcyAid2UgcHJvdmlk ZSBhIFBHLTEzIHNhZmUgZW52aXJvbm1lbnQgd2l0aCAgDQo+IHNvbWUgZGVncmVlIG9mIGNvbnRl bnQgcHJvdGVjdGlvbiwgYW5kIHdlIGltcGxlbWVudCBpdCB0aHJvdWdoIGEgIA0KPiBjb250ZW50 IHJldmlldyBzeXN0ZW0iIChhbmQgbm93IHRoZSBpUGhvbmUgc3RvcmUgZG9lcyB0aGUgc2FtZSB0 aGluZykuDQo+DQo+IFRoZSBPTElWRSBtb2RlbCBpcyAibGV0IHRoZSBjdXN0b21lciBkZWNpZGUs IGFsdGhvdWdoIHdlIGNhbiBoZWxwICANCj4geW91IHdpdGggdGhhdCBpZiB5b3UgbmVlZCBoZWxw LiINCj4NCj4gU2luY2VyZWx5LA0KPg0KPiBqdw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtbW94IG1haWxpbmcgbGlzdA0KPiBtbW94QGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW1veA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW1veCBtYWls aW5nIGxpc3QNCm1tb3hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbW1veA0K ------_=_NextPart_001_01C99601.B98A44B0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTIuMjQiPg0KPFRJVExFPlJlOiBbbW1veF0g bW1veCBEaWdlc3QsIFZvbCAxLCBJc3N1ZSAxMTM8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQo8 IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPg0KDQo8UD48Rk9OVCBTSVpF PTI+VGhlIGtleSBwb2ludCByZWxhdGl2ZSB0byBlYXJsaWVyIGNvbW1lbnRzIGlzIHRoYXQgRm9y dGVycmEgaXMgTk9UIEVWRVIgdGhlIGNsZWFyaW5naG91c2UgZm9yIGl0cyBjdXN0b21lcnMuLiZu YnNwOyBUaGF0IHdhcyB0aGUgZXJyb25lb3VzIGFzc3VtcHRpb24uJm5ic3A7IEFuIGFkbWluaXN0 cmF0b3IgY291bGQgcHJvYmFibHkgc2V0IHdoYXRldmVyIHBvbGljeSB0aGV5IHdhbnRlZC48QlI+ DQo8QlI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4NCkZyb206IG1tb3gtYm91bmNl c0BpZXRmLm9yZyAmbHQ7bW1veC1ib3VuY2VzQGlldGYub3JnJmd0OzxCUj4NClRvOiBKb24gV2F0 dGUgJmx0O2p3YXR0ZUBnbWFpbC5jb20mZ3Q7PEJSPg0KQ0M6IG1tb3hAaWV0Zi5vcmcgJmx0O21t b3hAaWV0Zi5vcmcmZ3Q7OyBkeWVyYnJvb2ttZUBqdW5vLmNvbSAmbHQ7ZHllcmJyb29rbWVAanVu by5jb20mZ3Q7PEJSPg0KU2VudDogTW9uIEZlYiAyMyAxMzo1NDozMCAyMDA5PEJSPg0KU3ViamVj dDogUmU6IFttbW94XSBtbW94IERpZ2VzdCwgVm9sIDEsIElzc3VlIDExMzxCUj4NCjxCUj4NCmJ1 dCBpIGJlbGlldmUgdGhlIHNlbnNlIG9mIHRoZSBjb21tZW50IHdhcyB0aGF0IHRoZSBlbmQgdXNl ciAoZGlzdGluY3QmbmJzcDs8QlI+DQpmcm9tIHRoZSBwZXJzb24gd2hvIGFkbWluaXN0ZXJzIHRo ZSBzZXJ2aWNlKSBpcyBub3QgYWxsb3dlZCB0byB1cGxvYWQmbmJzcDs8QlI+DQphcmJpdHJhcnkg Y29udGVudC48QlI+DQo8QlI+DQpteSB1bmRlcnN0YW5kaW5nIG9mIGJvdGggT0xJVkUgYW5kIHRo ZXJlLmNvbSBpcyB0aGF0IHRoZXkgYm90aCBkbyBub3QmbmJzcDs8QlI+DQphbGxvdyBhcmJpdHJh cnkgY29udGVudCB1cGxvYWQsIGJ1dCBpbnN0ZWFkIHJlcXVpcmUgc29tZW9uZSBvdGhlciB0aGFu Jm5ic3A7PEJSPg0KdGhlIGNvbnRlbnQgY3JlYXRvciBhcHByb3ZlIChhbmQgdHJhbnNmZXIpIHRo ZSBjb250ZW50LjxCUj4NCjxCUj4NCmJ1dC4uLiBpIGNvdWxkIGJlIHdyb25nLjxCUj4NCjxCUj4N Ck9uIEZlYiAyMywgMjAwOSwgYXQgMTo1MCBQTSwgSm9uIFdhdHRlIHdyb3RlOjxCUj4NCjxCUj4N CiZndDsgRGFuIE9saXZhcmVzIHdyb3RlOjxCUj4NCiZndDsmZ3Q7ICZxdW90O0luIHRoZSBUaGVy ZS5jb20vRm9ydGVycmEgY29udGV4dCwgY3VzdG9tZXIgY29udGVudCBpcyBjbGVhcmVkPEJSPg0K Jmd0OyZndDsgdGhyb3VnaCBhIGNlbnRyYWxpemVkIGNsZWFyaW5nIGhvdXNlIGFuZCBtdXN0IGJl IGFwcHJvdmVkIGJ5IHRoZTxCUj4NCiZndDsmZ3Q7IGNvbXBhbnkgYmVmb3JlIGl0IGNhbiBiZSB1 cGxvYWRlZDsgY3VzdG9tZXJzIGFyZSBpbiBhIHN1Ym9yZGluYXRlPEJSPg0KJmd0OyZndDs8QlI+ DQomZ3Q7PEJSPg0KJmd0OyBKdXN0IHRvIGJlIGNsZWFyOiBUaGVyZS5jb20gKG9wZXJhdGVkIGJ5 IE1ha2VuYSBUZWNobm9sb2dpZXMpIGFuZCZuYnNwOzxCUj4NCiZndDsgT0xJVkUgKHNvbGQgYnkg Rm9ydGVycmEgU3lzdGVtcykgYXJlIGRpZmZlcmVudCBwcm9kdWN0cywgd2l0aCB2ZXJ5Jm5ic3A7 PEJSPg0KJmd0OyBkaWZmZXJlbnQgY3VzdG9tZXJzIGFuZCB2ZXJ5IGRpZmZlcmVudCBwcm9jZXNz ZXMuIFRoZXJlLmNvbSBoYXMgYSZuYnNwOzxCUj4NCiZndDsgY2VudHJhbCBjbGVhcmluZ2hvdXNl LiBGb3J0ZXJyYSBTeXN0ZW1zIGRvZXMgbm90IC0tIGVhY2ggY3VzdG9tZXIgb2YmbmJzcDs8QlI+ DQomZ3Q7IHRoZSBPTElWRSBwbGF0Zm9ybSBkZWNpZGVzIGhvdyBhbmQgd2hhdCBjb250ZW50IGdv ZXMgaW50byB0aGVpciZuYnNwOzxCUj4NCiZndDsgaW5zdGFsbGF0aW9uLjxCUj4NCiZndDs8QlI+ DQomZ3Q7IFRoZSBUaGVyZS5jb20gbW9kZWwgaXMgJnF1b3Q7d2UgcHJvdmlkZSBhIFBHLTEzIHNh ZmUgZW52aXJvbm1lbnQgd2l0aCZuYnNwOzxCUj4NCiZndDsgc29tZSBkZWdyZWUgb2YgY29udGVu dCBwcm90ZWN0aW9uLCBhbmQgd2UgaW1wbGVtZW50IGl0IHRocm91Z2ggYSZuYnNwOzxCUj4NCiZn dDsgY29udGVudCByZXZpZXcgc3lzdGVtJnF1b3Q7IChhbmQgbm93IHRoZSBpUGhvbmUgc3RvcmUg ZG9lcyB0aGUgc2FtZSB0aGluZykuPEJSPg0KJmd0OzxCUj4NCiZndDsgVGhlIE9MSVZFIG1vZGVs IGlzICZxdW90O2xldCB0aGUgY3VzdG9tZXIgZGVjaWRlLCBhbHRob3VnaCB3ZSBjYW4gaGVscCZu YnNwOzxCUj4NCiZndDsgeW91IHdpdGggdGhhdCBpZiB5b3UgbmVlZCBoZWxwLiZxdW90OzxCUj4N CiZndDs8QlI+DQomZ3Q7IFNpbmNlcmVseSw8QlI+DQomZ3Q7PEJSPg0KJmd0OyBqdzxCUj4NCiZn dDs8QlI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPEJSPg0KJmd0OyBtbW94IG1haWxpbmcgbGlzdDxCUj4NCiZndDsgbW1veEBpZXRmLm9yZzxC Uj4NCiZndDsgPEEgSFJFRj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9t bW94Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tb3g8L0E+PEJSPg0K PEJSPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+ DQptbW94IG1haWxpbmcgbGlzdDxCUj4NCm1tb3hAaWV0Zi5vcmc8QlI+DQo8QSBIUkVGPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tb3giPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbW1veDwvQT48QlI+DQo8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9E WT4NCjwvSFRNTD4= ------_=_NextPart_001_01C99601.B98A44B0-- From jwatte@gmail.com Mon Feb 23 13:58:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B0BC28C150 for ; Mon, 23 Feb 2009 13:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wx0+Ku9bnT4K for ; Mon, 23 Feb 2009 13:58:22 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 3838E28C13E for ; Mon, 23 Feb 2009 13:58:22 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1176438ana.4 for ; Mon, 23 Feb 2009 13:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=TN0B/yrH8nhaJ4izDT+BFvCwgEXUMcqrozhxijG61po=; b=pObc8M8ScVAO+wWQIkN9HB6u7Po41g4LXa/y7TB2twjASrecgMt4cmUlWFwd/Dy43J le/czK/I3hU1g1WqQ14hZM+30U4TfuomebrTFFWlWZ0XWtqE2TCAyvDsEr6OgdlbZYBl FLVQvN4ToEgVzJE4EmcaO0Qt70dhz5OE/xMkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=GugV7fvfmOq4qIU5wT0wZ8eMYGQVMVE7RbGOrkevWcmhIw19QZlQC+CxeZzQ9yozmq 3gqw8KcvGzsFZY5ZggR2n29Uj6ad+Y1YnXnTYclAJ3bSvvYbcOn6UWCRi1nfO4Hzf5Ox C4aRzGfOVeyLOnYO14D/YI11YlqGfoKeOGrZY= Received: by 10.100.151.14 with SMTP id y14mr4741662and.117.1235426319818; Mon, 23 Feb 2009 13:58:39 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d38sm13749880and.29.2009.02.23.13.58.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 13:58:39 -0800 (PST) Message-ID: <49A31C0D.2010906@gmail.com> Date: Mon, 23 Feb 2009 13:58:37 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Christian Scholz References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <49A310E2.2040706@gmail.com> <49A31417.4000500@comlounge.net> In-Reply-To: <49A31417.4000500@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] DRM, Permissions, Openness and Leftism: A grand unified theory X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 21:58:23 -0000 Christian Scholz wrote: > much trust the entity controlling that URL. Also what happenes if the > server hosting that URL goes out of business? Can I then still use the > object at all? > If your webhost goes out of business, will links to your website still work? If YouTube goes out of business, will your hosted videos still work? > Because of that I would find a solution better which is self-contained > and carries all information necessary. The "transfer for cash" is also > more or less a licensing question which IMHO should be dealt with an > attached license blurb (GPL, CC whatever). I don't think anyway that > we can model all license questions into technical solutions. > The problem with self-contained systems is that simulation is tightly bound to languages and environments. While a simulatable object may be transportable between services based on the same technology (or even based on the same version of the same technology), general transportability of the object is not a realistic goal. Compare sending a link to your Wiki, versus sending a downloaded copy of your Wiki -- very different things! The ability to transfer an object (rather than a reference) between servers, assuming they can each host the same object, might actually make for yet another kind of operation. "Transfer ownership" is different from "transfer bits." Again, I think that bit could be there, and it could be conditional just like the other bits -- "allow," "deny," "allow and revert," and "sticky allow," coupled with the mark-up of possible DRM requirements, that only needs to be recognized by systems actually implementing DRM. Sincerely, jw From jesrad@gmail.com Mon Feb 23 14:01:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC6628C198 for ; Mon, 23 Feb 2009 14:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id didTDSJ6kAMT for ; Mon, 23 Feb 2009 14:01:15 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 667C428C150 for ; Mon, 23 Feb 2009 14:01:15 -0800 (PST) Received: by bwz5 with SMTP id 5so5254260bwz.13 for ; Mon, 23 Feb 2009 14:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DAeYGX1UF4aPJXd45qinJvesDCRo0BfFcJ6E0Q9r88Y=; b=FSTzFfpZxwcFrb4NUejvxxwJetTlk9DhEDSbBySdu9qM2xtQCYNIUDNlA2T372ZuPm 9VnFhpB5nn2KVsXLlsIp8GyeW9nTcLKNtYewkkdDItvyl5u2mRSD00pWJkhc11onS3D0 F834KmE3FhoD6t9MRSD9bVLznQNennldaH0ow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CS5gfViKNP8HFoyd+AT4YXDjRW29KMYSQ4Cbmz8vK87JMKU4gh4f9LjHxSbjucPzMP Udv4tZAhxhk3R6KJsGZwqJDmpq9XnYPeyRc3TG/EuGJZw095aaP3NJF7kAt1FPPbBes1 /AxS22zf6E+oyzzdzWm5+eO5Xz/1RH1CA7Pkc= MIME-Version: 1.0 Received: by 10.181.240.10 with SMTP id s10mr1678881bkr.12.1235426492881; Mon, 23 Feb 2009 14:01:32 -0800 (PST) In-Reply-To: <20090223.114423.5499.2@webmail09.vgs.untd.com> References: <20090223.114423.5499.2@webmail09.vgs.untd.com> Date: Mon, 23 Feb 2009 23:01:32 +0100 Message-ID: <53cd6c2e0902231401s404f2812qda58cb0e8143eada@mail.gmail.com> From: Jesrad To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:01:16 -0000 I already do check c+m+t on my objects, but that does not prevent in any way the next owner from unchecking them. That is what I mean by "opting out" of the permission system. Just as a copyright-business does not want people to be able to check the missing permissions, I do not want them to be able to uncheck them, because it reduces the value of what I sell and constitutes a violation of either my copyright (in the copyright model) or a violation the further buyers' property rights and fraud (in my model). I do not know what the "8 generatives" refer to. All I know is that I'm making money, that the permission system in SL makes my business model wide open to a little but annoying amount of ripping off that harms its value, and that I'd rather not have that situation extended to all other VWs. On Mon, Feb 23, 2009 at 5:44 PM, dyerbrookme@juno.com wrote: >>My model can coexist with copyright-based models, provided I can > opt my content out of any DRM system. > > With a DRM system like c/m/t being conveyed, you check off c/m/t if you w= ant full perms to be distributed *shrugs*. That's all. Transporting the met= adata of c/m/t -- or no c/m/t and demanding a regime to implement it does n= ot preclude you from "opting out" by...checking off c/m/t. Why would you th= ink that the act of having to check off c/m/t to get full perms, so that ot= hers who *do not* want to check them off and wish to make a living not thro= ugh consulting but by object sales would somehow preclude your full-perms d= istribution? Makes no sense, again, except as an ideological demand. > > There has been no scientific, peer-reviewed study of whether the 8 genera= tives really made a living for anyone already funded; it's one of those ane= cdotal things that a few people spread the memes, and it becomes an urban l= egend. > > ____________________________________________________________ > Compete with the big boys. Click here to find products to benefit your b= usiness. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTI97xtbbXRD0zhtu22xsaZ2= 9LA7F4pgNLlXYLb3XqYFhO0bPSqtfa/ > From infinity@lindenlab.com Mon Feb 23 14:01:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2269F28C220 for ; Mon, 23 Feb 2009 14:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G15I9zmJuEC for ; Mon, 23 Feb 2009 14:01:28 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id EF86028C150 for ; Mon, 23 Feb 2009 14:01:27 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 877A53DBC44F; Mon, 23 Feb 2009 14:01:46 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: "Robert Gehorsam" In-Reply-To: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C9F@MERCURY.forterrainc.com> Content-Type: multipart/alternative; boundary=Apple-Mail-8--578731348 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 14:01:46 -0800 References: <9A27EF31A4DF2C4C8BB45D661B13BA87039B0C9F@MERCURY.forterrainc.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org, jwatte@gmail.com, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:01:29 -0000 --Apple-Mail-8--578731348 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit so OLIVE supports direct end user content upload without administrator interaction? (though it's probably not enabled by policy in some/many deployments?) On Feb 23, 2009, at 1:57 PM, Robert Gehorsam wrote: > The key point relative to earlier comments is that Forterra is NOT > EVER the clearinghouse for its customers.. That was the erroneous > assumption. An administrator could probably set whatever policy > they wanted. > > -----Original Message----- > From: mmox-bounces@ietf.org > To: Jon Watte > CC: mmox@ietf.org ; dyerbrookme@juno.com > > Sent: Mon Feb 23 13:54:30 2009 > Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 > > but i believe the sense of the comment was that the end user (distinct > from the person who administers the service) is not allowed to upload > arbitrary content. > > my understanding of both OLIVE and there.com is that they both do not > allow arbitrary content upload, but instead require someone other than > the content creator approve (and transfer) the content. > > but... i could be wrong. > > On Feb 23, 2009, at 1:50 PM, Jon Watte wrote: > > > Dan Olivares wrote: > >> "In the There.com/Forterra context, customer content is cleared > >> through a centralized clearing house and must be approved by the > >> company before it can be uploaded; customers are in a subordinate > >> > > > > Just to be clear: There.com (operated by Makena Technologies) and > > OLIVE (sold by Forterra Systems) are different products, with very > > different customers and very different processes. There.com has a > > central clearinghouse. Forterra Systems does not -- each customer of > > the OLIVE platform decides how and what content goes into their > > installation. > > > > The There.com model is "we provide a PG-13 safe environment with > > some degree of content protection, and we implement it through a > > content review system" (and now the iPhone store does the same > thing). > > > > The OLIVE model is "let the customer decide, although we can help > > you with that if you need help." > > > > Sincerely, > > > > jw > > > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --Apple-Mail-8--578731348 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable so OLIVE supports direct end = user content upload without administrator interaction? (though it's = probably not enabled by policy in some/many = deployments?)

On Feb 23, 2009, at 1:57 PM, Robert = Gehorsam wrote:

The key point relative to earlier comments is that Forterra = is NOT EVER the clearinghouse for its customers..  That was the = erroneous assumption.  An administrator could probably set whatever = policy they wanted.

-----Original Message-----
From: mmox-bounces@ietf.org <mmox-bounces@ietf.org>
To: = Jon Watte <jwatte@gmail.com>
CC: mmox@ietf.org <mmox@ietf.org>; dyerbrookme@juno.com <dyerbrookme@juno.com>
Sent: = Mon Feb 23 13:54:30 2009
Subject: Re: [mmox] mmox Digest, Vol 1, = Issue 113

but i believe the sense of the comment was that the = end user (distinct 
from the person who administers the = service) is not allowed to upload 
arbitrary content.

= my understanding of both OLIVE and there.com is that they both do = not 
allow arbitrary content upload, but instead require = someone other than 
the content creator approve (and transfer) = the content.

but... i could be wrong.

On Feb 23, 2009, = at 1:50 PM, Jon Watte wrote:

> Dan Olivares wrote:
>> "In = the There.com/Forterra context, customer content is cleared
>> = through a centralized clearing house and must be approved by the
>> = company before it can be uploaded; customers are in a subordinate
= >>
>
> Just to be clear: There.com (operated by Makena = Technologies) and 
> OLIVE (sold by Forterra Systems) are = different products, with very 
> different customers and very = different processes. There.com has a 
> central clearinghouse. = Forterra Systems does not -- each customer of 
> the OLIVE = platform decides how and what content goes into their 
> = installation.
>
> The There.com model is "we provide a PG-13 = safe environment with 
> some degree of content protection, and = we implement it through a 
> content review system" (and now = the iPhone store does the same thing).
>
> The OLIVE model is = "let the customer decide, although we can help 
> you with that = if you need help."
>
> Sincerely,
>
> jw
>
> = _______________________________________________
> mmox mailing = list
> mmox@ietf.org
> https://www.ietf.org/m= ailman/listinfo/mmox

= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/m= ailman/listinfo/mmox

=

= --Apple-Mail-8--578731348-- From missannotoole@yahoo.com Mon Feb 23 14:05:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD7F28C198 for ; Mon, 23 Feb 2009 14:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EVpfyKgPizrp for ; Mon, 23 Feb 2009 14:05:37 -0800 (PST) Received: from web59103.mail.re1.yahoo.com (web59103.mail.re1.yahoo.com [66.196.101.14]) by core3.amsl.com (Postfix) with SMTP id 05AB128C150 for ; Mon, 23 Feb 2009 14:05:36 -0800 (PST) Received: (qmail 79226 invoked by uid 60001); 23 Feb 2009 22:05:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1235426755; bh=fU9u5urjttpB8J3UYVfvMP3W7uZa1dLA61tFuGDPqFU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=dVQDD+lLmkuWb3AYG6Y/G9g2x8qvT1jiugiy9XD3xE8jvCI050NT1DrqkNQEoWMOd99CSSdVO1kNnBLc9PTZufij8dVXl6obkUiiThW+WZV0QD8829334StXCKxf/xj/ZYbPtdsvqq5Vk2bjsdoLUtOuMyQrRIzWrU/wDaIer/0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=kLgQjpdWxftC2jWpDJnndmhjLnzbFWwXMuc8ilchgOeTDWgVbaxolAUdBHkByClEQUbrEtkJDgKVXquIT+rZAsblebKf/qQ3VVA0dNA8cPbHFsxnqr98P1SzIGSAmaGl1HTFwF11Uf0YHbBA/oMnDFWhrwI07s5M176KAowFfnY=; Message-ID: <162490.78744.qm@web59103.mail.re1.yahoo.com> X-YMail-OSG: 2r6Mf_gVM1lGkMXyJeOSHWHUuM7NMFHnhTXe2X4sCE.BxW4BDHFnngseIyB3NGyIG4S1GcOM0H4mvnn1Z3E1wwpB1TSKY5P3vOCRBWUBTWGoOGkDhVgrp_MffO9jyN3xPQBZJd6ChVs6Ywoi9XJ8pHXZ_g0Wgw2_6lR.z8K2n2J__gPGLOL1CfxPyfACi8WQv2cPM3I_CmuL.mBHb6U5rOI8eG6rTu8Ucuc- Received: from [97.102.254.236] by web59103.mail.re1.yahoo.com via HTTP; Mon, 23 Feb 2009 14:05:55 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> <61dbdd7d0902230537n20f86856i8b392a80b1740bc0@mail.gmail.com> <53cd6c2e0902230559g73aa66e3u4026f34b95ec215@mail.gmail.com> <49A2FDB8.7000303@cox.net> <49A31323.8010804@gmail.com> Date: Mon, 23 Feb 2009 14:05:55 -0800 (PST) From: Ann Otoole To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-359660762-1235426755=:78744" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:05:38 -0000 --0-359660762-1235426755=:78744 Content-Type: text/plain; charset=us-ascii "If SL makes it a requirement that at least one SL customer is part of any interoperation scenario involving SL servers, then SL has a revenue stream for each such interoperation scenario." You forget that there was no requirement established that participation in standards does not require for profit only status sir. Or that sentence of yours was not stated in a sufficiently clear and unambiguous manner. If Kapor/Rosedale wishes to establish interop for non profit activities then Kapor/Rosedale will do so. It is their money. In addition I think it would be useful to replace any Linden Lab participant's name with "The CEO of Linden Lab said:" to get this correct since the level of discourse has been established at the corporate officer level and is no no way possible to drop to technical level unless the corporate officers of various corporations trying to direct this effort remove themselves and allow peers only to participate. If the Linden Lab staff are not representing their CEO then they need to get a formal corporate officer rep in here since Linden Lab's competitors' corporate officers are here en masse. >From the available information I have seen Second Life/Second Life derivitives have the interoperability momentum at the moment. Exactly what public "grid" does Forterra bring to the table anyway? How many simulators is Forterra running in use 24*7? How many actual end users does Forterra have on a daily basis? Why should we consider anything from Forterra as authorative? They just show up and start shoving people around complaining about the industry leader? Why does anyone care about Forterra Systems? What does Forterra think will happen if awareness of this effort was properly communicated to the millions of Second Life customers and some thousands of them decided to begin actively participating in these proceedings? Do we really want that mob scene to take place? Personally I would prefer the animosity stop and this remain technical instead of corporate competition postitioning level. All it takes to deal with the issue of permissions in general is a commitment to include permissions as a component in the standard, whatever that looks like, and then create a sub committee/list to debate permissions seperately and once consensus is acheived the proposal be brought forth for debate. --0-359660762-1235426755=:78744 Content-Type: text/html; charset=us-ascii
"If SL makes it a requirement that at least one SL customer is part of any interoperation scenario involving SL servers, then SL has a revenue stream for each such interoperation scenario."

You forget that there was no requirement established that participation in standards does not require for profit only status sir. Or that sentence of yours was not stated in a sufficiently clear and unambiguous manner. If Kapor/Rosedale wishes to establish interop for non profit activities then Kapor/Rosedale will do so. It is their money.

In addition I think it would be useful to replace any Linden Lab participant's name with "The CEO of Linden Lab said:" to get this correct since the level of discourse has been established at the corporate officer level and is no no way possible to drop to technical level unless the corporate officers of various corporations trying to direct this effort remove themselves and allow peers only to participate. If the Linden Lab staff are not representing their CEO then they need to get a formal corporate officer rep in here since Linden Lab's competitors' corporate officers are here en masse.

From the available information I have seen Second Life/Second Life derivitives have the interoperability momentum at the moment. Exactly what public "grid" does Forterra bring to the table anyway? How many simulators is Forterra running in use 24*7? How many actual end users does Forterra have on a daily basis? Why should we consider anything from Forterra as authorative? They just show up and start shoving people around complaining about the industry leader? Why does anyone care about Forterra Systems? What does Forterra think will happen if awareness of this effort was properly communicated to the millions of Second Life customers and some thousands of them decided to begin actively participating in these proceedings? Do we really want that mob scene to take place?

Personally I would prefer the animosity stop and this remain technical instead of corporate competition postitioning level.

All it takes to deal with the issue of permissions in general is a commitment to include permissions as a component in the standard, whatever that looks like, and then create a sub committee/list to debate permissions seperately and once consensus is acheived the proposal be brought forth for debate.


--0-359660762-1235426755=:78744-- From jesrad@gmail.com Mon Feb 23 14:07:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A503A6A47 for ; Mon, 23 Feb 2009 14:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EMZRuVAHmBj for ; Mon, 23 Feb 2009 14:07:55 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by core3.amsl.com (Postfix) with ESMTP id 9DCD03A67B4 for ; Mon, 23 Feb 2009 14:07:54 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d3so425721nfc.39 for ; Mon, 23 Feb 2009 14:08:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x84m/95B03q1aiSZRaxLrmufl3SokBAHuvaK7tMh4mc=; b=gJV8bIPbyjhL8eyka5fD2SV3kiedS05GvQaWRJFQ0QOeZghAffHbD+h4/dzwsPWYMy 3G4ILpy9aqEbnY4N3s/23xntaJ170TCwZWFvS+fxSVkN28Swo23RnPJXitoRKH9rtgXy knJww4ofQ3G4keNx45N7bMzUscMIqcndNnoYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZRJtRhUu1h85FFo27JOWlBWEDRNZa/jxSFZaADCFy47FJkFSJ4m4OgJRje1aJygmvs MeAM54ORUQlDiPWwWrY6DQ+GKMJxYg8bzhf7qDost+CW/xbTLfYpmT74p1NZ6REl4UUA hSVYi50CUzVPgs9sVYGxHwR6wR2BxOLt3CvOo= MIME-Version: 1.0 Received: by 10.210.38.17 with SMTP id l17mr3775638ebl.192.1235426892023; Mon, 23 Feb 2009 14:08:12 -0800 (PST) In-Reply-To: <49A31AD2.40402@gmail.com> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <49A30AE5.6060307@gmail.com> <53cd6c2e0902231323p641cd6d4s99d5f97a0340c4c2@mail.gmail.com> <49A31AD2.40402@gmail.com> Date: Mon, 23 Feb 2009 23:08:11 +0100 Message-ID: <53cd6c2e0902231408y3fb35487v4125171b4ca5b16d@mail.gmail.com> From: Jesrad To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:07:56 -0000 > What I'm arguing against is the argument that _clients_ connect to multiple > servers (in a client/server system); in such as system there is no way that > the server object of the soccer goal can know about the other-server object > soccer ball. My argument is simply against the idea that a single client > connecting to two separate virutal world servers could provide a usefully > consistent view of a virtual world simulation. Well, that's precisely the model Solipsis is based on, and it seems to give a reasonably consistent view. The node with the soccer ball can decide to let others know about it or not, and that makes little difference for the rest of the world. In this model you're free to have things exist only in your own universe and not affect anything else, and that's fine if that's what you want (meaning you can have inconsistency if you want it). If you're interested to see how decentralized a VW can get in practice and theory, read the paper the project team wrote: http://bots.netofpeers.net/riam_solipsis/LOT1/MMVE_ID_6_Solipsis.pdf On Mon, Feb 23, 2009 at 10:53 PM, Jon Watte wrote: > Jesrad wrote: >>> >>> How then would the soccer ball on my server be able to affect the soccer >>> goal on your server? >>> >> >> In Solipsis, a completely decentralized VW, congruent nodes (servers) >> with dynamic objects keep each other up to date with the movements of >> those if they are close enough. Objects then determine if they hit the >> other object and react accordingly: each soccer ball is told about the >> other's position in real time. >> >> > > That's right! That's the model I think will work. > > What I'm arguing against is the argument that _clients_ connect to multiple > servers (in a client/server system); in such as system there is no way that > the server object of the soccer goal can know about the other-server object > soccer ball. My argument is simply against the idea that a single client > connecting to two separate virutal world servers could provide a usefully > consistent view of a virtual world simulation. Unless you require the client > to serve as proxy/gateway/translator for funneling data between the servers > (again, in a c/s system), which would be terrible for both technical, trust > and scalability reasons. > > Sincerely, > > jw > > From cs@comlounge.net Mon Feb 23 14:08:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE38D28C22A for ; Mon, 23 Feb 2009 14:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obAKYkbuVHre for ; Mon, 23 Feb 2009 14:08:17 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 5A0F028C228 for ; Mon, 23 Feb 2009 14:08:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 1916B1CE024E; Mon, 23 Feb 2009 23:08:35 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNTwCfeNGoiQ; Mon, 23 Feb 2009 23:08:34 +0100 (CET) Received: from [192.168.178.40] (pD9EBD4A1.dip.t-dialin.net [217.235.212.161]) by post.comlounge.net (Postfix) with ESMTP id 6CFFB1CE0110; Mon, 23 Feb 2009 23:08:32 +0100 (CET) Message-ID: <49A31E5C.2010903@comlounge.net> Date: Mon, 23 Feb 2009 23:08:28 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jon Watte References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <49A310E2.2040706@gmail.com> <49A31417.4000500@comlounge.net> <49A31C0D.2010906@gmail.com> In-Reply-To: <49A31C0D.2010906@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] DRM, Permissions, Openness and Leftism: A grand unified theory X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:08:18 -0000 Jon Watte schrieb: > Christian Scholz wrote: >> much trust the entity controlling that URL. Also what happenes if the >> server hosting that URL goes out of business? Can I then still use the >> object at all? >> > > If your webhost goes out of business, will links to your website still > work? > If YouTube goes out of business, will your hosted videos still work? No but I can copy that video to my collection if I want to. And if I pay for something I expect it to be downloadable anyway. Services might be different but we see in the case of music that to sell just a license is not really working. People want to own their stuff. When I buy something in a virtual world in a virtual shop in-world I am thinking about this the same way I buy something in real life. It's not suddenly gone. But even if we say we can reference objects it would still be useful to also have the ability to make a real copy if both parties wish to do so. >> Because of that I would find a solution better which is self-contained >> and carries all information necessary. The "transfer for cash" is also >> more or less a licensing question which IMHO should be dealt with an >> attached license blurb (GPL, CC whatever). I don't think anyway that >> we can model all license questions into technical solutions. >> > > The problem with self-contained systems is that simulation is tightly > bound to languages and environments. While a simulatable object may be > transportable between services based on the same technology (or even > based on the same version of the same technology), general > transportability of the object is not a realistic goal. Compare sending > a link to your Wiki, versus sending a downloaded copy of your Wiki -- > very different things! I still can download the wiki if I'd like to. I can also download photos from flickr and so on. And I am really not sure if on the long run not all systems might become similar in their technology. In the beginning you always need gateways to move data around but later on those might more and more vanish and be replaced by one winning format which might or might not be a mix of all the formerly existing ones. On the short run though I agree that not everybody now will change their deployed system to conform to the one and only standard. I can also live by having a full copy and reference, I just don't want the full copy ruled out directly. > The ability to transfer an object (rather than a reference) between > servers, assuming they can each host the same object, might actually > make for yet another kind of operation. "Transfer ownership" is > different from "transfer bits." Again, I think that bit could be there, > and it could be conditional just like the other bits -- "allow," "deny," > "allow and revert," and "sticky allow," coupled with the mark-up of > possible DRM requirements, that only needs to be recognized by systems > actually implementing DRM. As said, I would favour various metadata schemes which you can attach to an object or a reference so things stay flexible. -- Christian -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From john.hurliman@intel.com Mon Feb 23 14:09:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F4E53A6A76 for ; Mon, 23 Feb 2009 14:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga--tCxvf1VG for ; Mon, 23 Feb 2009 14:09:24 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id BD7A43A6A75 for ; Mon, 23 Feb 2009 14:09:21 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 23 Feb 2009 14:09:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,256,1233561600"; d="scan'208";a="113600364" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by azsmga001.ch.intel.com with ESMTP; 23 Feb 2009 14:09:40 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Mon, 23 Feb 2009 15:09:39 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Mon, 23 Feb 2009 15:09:34 -0700 Thread-Topic: Industry involvement (was RE: [mmox] Learning from the past; focusing on the future) Thread-Index: AcmV++FCqr2SCKnDSNOd5vSpvKX5YAAADtbAAACWddA= Message-ID: <62BFE5680C037E4DA0B0A08946C0933D502639B5@rrsmsx506.amr.corp.intel.com> References: <49A2500F.3000104@gmail.com> <49A311BC.90405@gmail.com> <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com> In-Reply-To: <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mmox] Industry involvement (was RE: Learning from the past; focusing on the future) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:09:25 -0000 I am representing Intel on this list and possibly at the BOF. My opinion is= that there is a "wait and see" attitude across many industry and community= partners, to see if a usable multi-platform spec is produced. As evidenced= by the current discussion archives for MMOX, the amount of effort that it = is taking to steer this in a vendor neutral direction is overwhelming. I ha= d to rewrite the proposed charter just to keep the *definition of the group= * from being written as a timeline to standardizing Linden Lab's protocol s= tack. The standardization of LLSD is embedded in the timeline, while myself= and others have raised concerns about its utility in comparison to other c= ompeting IDLs. While this discussion is going on, there is a risk of participation being p= erceived as consent. IBM's implementation of the first OGP teleport spec wa= s added to the OpenSim codebase, and now OGP is touted as a joint effort be= tween Linden Lab and the open source communities surrounding Second Life. I= wrote an initial implementation of LLIDL, so I suppose under that definiti= on LLSD/LLIDL is a joint effort between Intel and Linden Lab. This could easily become a full time job for participants, and from what I = can tell the only guaranteed output is that Linden Lab's LLSD/LLIDL/OGP tec= hnology will become standardized. Whether or not that stack is competitive = with alternative proposals, or an alternative standard is proposed in paral= lel, is an open question. As Intel is not a virtual world vendor, and inter= ested more in the wider technology landscape of virtual worlds it makes sen= se for me to be here. That doesn't apply to Qwaq, Multiverse, HiPiHi, Activ= eWorlds, etc. who will lose nothing by ignoring the creation of a standard = that doesn't provide any value to their platforms. Unless there is a clear = return on the time investment it is unlikely that there will be broad indus= try participation. John >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Robert Gehorsam >Sent: Monday, February 23, 2009 1:30 PM >To: Jon Watte; Morgaine >Cc: Mystical Demina; mmox@ietf.org >Subject: Re: [mmox] Learning from the past; focusing on the future > >I think part of the issue here with regard to the debate between broad >and narrow interoperability is that, other than Jon representing >Forterra's technical efforts, there are no other visibly participating >technical representatives from any other virtual world technology >providers or other relevant groups. No one from Sun, Qwaq, Multiverse, >HiPiHi, Activeworlds, any of the browser-based folks, Twinity, any of >the game folks or kids worlds, Makena (the company that, contrary to >some folks' assertions, is the company that makes and operates >There.com), Proton Media, Icarus or its various partners, ECS, and so >forth. I've seen references to Qwaq but haven't seen Greg or anyone >else from there participating here. There are probably two dozen >companies that would be reasonable candidates for this discussion, not >to mention companies like Adobe, Google, Intel, Samsung, Sony and, yes, >even Microsoft, all of which might arguably have some interesting >contributions to make. > >It may be that this lack of broad participation is creating -- fairly or >unfairly -- the sense that the conversation will naturally drift towards >an SL-OS orientation -- despite what I see as the best intentions of >many people here -- simply because, other than Forterra, no one else is >stepping up to the plate. I can tell you that *that* is not something >that Forterra wants to see, because it's inherent in our view of the >evolution of the internet that interoperability between diverse virtual >worlds is essential for all to succeed. So the imbalance in this >ongoing discussion creates a false dynamic of conflict when none is >intended. Without broad input, how can we achieve broad >interoperability? > >Is there any outreach going on to these various organizations, or is >that somehow not part of the policy? Not being really familiar with the >workings of these sorts of technical groups, I just don't know. > >Robert > >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Jon Watte >Sent: Monday, February 23, 2009 4:15 PM >To: Morgaine >Cc: Mystical Demina; mmox@ietf.org >Subject: Re: [mmox] Learning from the past; focusing on the future > >Morgaine wrote: >> I can't understand why you continue to raise the spectre that we're >> here to rubberstamp SL standards. We aren't. I'm not aware of >> anybody with that agenda. >> > >Because there are several people on this list who say "OpenSim and >Second Life are already trying to do client interoperability; I think we >should run with it and not worry about something bigger." >Similarly, I find that the current OGP proposal specifies some thing >("Rezzing" of avatars) that are Second Life centric, while not >specifying other things that would be necessary for an actually useful >interoperable virtual world (like entity telemetry). > >Similarly, if OGP is specified as a mostly empty vessel that can contain >arbitrary negotiated data, what would probably happen would be that >OpenSim puts OpenSim data in that vessel, and IMVU puts IMVU data in >that vessel, and both claim to support "OGP interoperability" but you >can't do anything useful through that claim. I want to avoid that >outcome. >> >> We are working in good faith towards your item 2), while noting that >> item 2) means interop with "all" reasonable worlds, and that includes >> Linden worlds. It's not either/or, it's both. Please grant us that, >> so that we can actually make headway. >> >> /(Proviso: your item 2) says /*single ... simulation*/, which is >> incorrect, as we have no remit to straightjacket diverse worlds into a > >> single simulation.)/ > >What I mean by "single simulation" is what the user sees when connected >to a specific, interoperating instance. I suppose the user could be >connected to multiple of those, similar to opening multiple video >streams in a media player, but then those generally have "nothing" to do >with each other. > > >Okay, so if most of us agree on 2), can we just say we have "rough >consensus" on that, and politely reject any attempt to steer the work >towards 1)? > > >Sincerely, > >jw > > >_______________________________________________ >mmox mailing list >mmox@ietf.org >https://www.ietf.org/mailman/listinfo/mmox >_______________________________________________ >mmox mailing list >mmox@ietf.org >https://www.ietf.org/mailman/listinfo/mmox > From infinity@lindenlab.com Mon Feb 23 14:10:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F3D028C22F for ; Mon, 23 Feb 2009 14:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0AYVocpTIz9 for ; Mon, 23 Feb 2009 14:10:08 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 89F8C28C228 for ; Mon, 23 Feb 2009 14:10:08 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 2129A3DBC44F; Mon, 23 Feb 2009 14:10:27 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: "Robert Gehorsam" In-Reply-To: <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 14:10:26 -0800 References: <49A2500F.3000104@gmail.com> <49A311BC.90405@gmail.com> <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org, Mystical Demina , Jon Watte Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:10:09 -0000 yes. the purpose of the upcoming MMOX BoF session is to get people from a diverse collection of virtual worlds / MMOs in the same room at the same time to discuss: a. is a working group a good idea? b. if so, how should we constrain the problem domain? c. if we can't agree on the same problem domain, does it make sense to have multiple working groups? it is telling that the 74th IETF meeting is held during the same week and less than a mile away from this year's game developers conference, but it is not my place to commit representatives from the companies you mention to attend. -cheers -meadhbh On Feb 23, 2009, at 1:30 PM, Robert Gehorsam wrote: > I think part of the issue here with regard to the debate between broad > and narrow interoperability is that, other than Jon representing > Forterra's technical efforts, there are no other visibly participating > technical representatives from any other virtual world technology > providers or other relevant groups. No one from Sun, Qwaq, > Multiverse, > HiPiHi, Activeworlds, any of the browser-based folks, Twinity, any of > the game folks or kids worlds, Makena (the company that, contrary to > some folks' assertions, is the company that makes and operates > There.com), Proton Media, Icarus or its various partners, ECS, and so > forth. I've seen references to Qwaq but haven't seen Greg or anyone > else from there participating here. There are probably two dozen > companies that would be reasonable candidates for this discussion, not > to mention companies like Adobe, Google, Intel, Samsung, Sony and, > yes, > even Microsoft, all of which might arguably have some interesting > contributions to make. > > It may be that this lack of broad participation is creating -- > fairly or > unfairly -- the sense that the conversation will naturally drift > towards > an SL-OS orientation -- despite what I see as the best intentions of > many people here -- simply because, other than Forterra, no one else > is > stepping up to the plate. I can tell you that *that* is not > something > that Forterra wants to see, because it's inherent in our view of the > evolution of the internet that interoperability between diverse > virtual > worlds is essential for all to succeed. So the imbalance in this > ongoing discussion creates a false dynamic of conflict when none is > intended. Without broad input, how can we achieve broad > interoperability? > > Is there any outreach going on to these various organizations, or is > that somehow not part of the policy? Not being really familiar with > the > workings of these sorts of technical groups, I just don't know. > > Robert > > -----Original Message----- > From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf > Of > Jon Watte > Sent: Monday, February 23, 2009 4:15 PM > To: Morgaine > Cc: Mystical Demina; mmox@ietf.org > Subject: Re: [mmox] Learning from the past; focusing on the future > > Morgaine wrote: >> I can't understand why you continue to raise the spectre that we're >> here to rubberstamp SL standards. We aren't. I'm not aware of >> anybody with that agenda. >> > > Because there are several people on this list who say "OpenSim and > Second Life are already trying to do client interoperability; I > think we > should run with it and not worry about something bigger." > Similarly, I find that the current OGP proposal specifies some thing > ("Rezzing" of avatars) that are Second Life centric, while not > specifying other things that would be necessary for an actually useful > interoperable virtual world (like entity telemetry). > > Similarly, if OGP is specified as a mostly empty vessel that can > contain > arbitrary negotiated data, what would probably happen would be that > OpenSim puts OpenSim data in that vessel, and IMVU puts IMVU data in > that vessel, and both claim to support "OGP interoperability" but you > can't do anything useful through that claim. I want to avoid that > outcome. >> >> We are working in good faith towards your item 2), while noting that >> item 2) means interop with "all" reasonable worlds, and that includes >> Linden worlds. It's not either/or, it's both. Please grant us that, >> so that we can actually make headway. >> >> /(Proviso: your item 2) says /*single ... simulation*/, which is >> incorrect, as we have no remit to straightjacket diverse worlds >> into a > >> single simulation.)/ > > What I mean by "single simulation" is what the user sees when > connected > to a specific, interoperating instance. I suppose the user could be > connected to multiple of those, similar to opening multiple video > streams in a media player, but then those generally have "nothing" > to do > with each other. > > > Okay, so if most of us agree on 2), can we just say we have "rough > consensus" on that, and politely reject any attempt to steer the work > towards 1)? > > > Sincerely, > > jw > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From jesrad@gmail.com Mon Feb 23 14:14:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560BF3A6897 for ; Mon, 23 Feb 2009 14:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsM8DHEkcoIa for ; Mon, 23 Feb 2009 14:14:15 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id 8DD213A6817 for ; Mon, 23 Feb 2009 14:14:14 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d3so426148nfc.39 for ; Mon, 23 Feb 2009 14:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2pzjgnr/UFbDpUrbCaHGjnRRzk+CnpdY5Lfwo2dBL/M=; b=jTGyVWFeCPOt54xcKwnEWk0IDJDUmXRd0njDVnmmWPrNk2cabQDoGqi6pWRdJIymO7 rLLbesgCXE9iSyH5/2GUB+TeYfUUc3dXb+4EKG7HmYBX1llacNdDycAlq8m16n2C1is5 KFp28yNyTtG8wwkS/lkVR3vcwjIBwS1dTS2PY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=H4m2pbOuHITdLNe7pOvxdjQtnTwnhiugnXA4jgi1rFOe0TyBu0MVzXZaKiMy+uoaub GjKGMVVzXL8MZxVkgWmIEXHwvqr6vlXoJbkhP+0kceCkLdZ/UKi71Pc63NjW7Ku3o6s+ HQ6MGeUUqlCpeoyuEndaosArkqEg48Vg6Pm7g= MIME-Version: 1.0 Received: by 10.210.59.14 with SMTP id h14mr3813575eba.16.1235427271592; Mon, 23 Feb 2009 14:14:31 -0800 (PST) In-Reply-To: <49A2FDB8.7000303@cox.net> References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> <61dbdd7d0902230537n20f86856i8b392a80b1740bc0@mail.gmail.com> <53cd6c2e0902230559g73aa66e3u4026f34b95ec215@mail.gmail.com> <49A2FDB8.7000303@cox.net> Date: Mon, 23 Feb 2009 23:14:31 +0100 Message-ID: <53cd6c2e0902231414o5c88f51ap78d857d2ff8f4aa0@mail.gmail.com> From: Jesrad To: lenglish5@cox.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:14:16 -0000 Very interesting point, thank you ! I figure we can have local caching with encrypted, timestamped copies, and have the original grid/host only transmit the decryption key to the intended endpoint. That way, we can have caching without unwanted disclosure of the data to the caching middlemen. On Mon, Feb 23, 2009 at 8:49 PM, Lawson English wrote: > Jesrad wrote: >> >> This amounts to an implementation of some DRM, if I understand it >> correctly. Would it be part of the protocol that grids are to >> machine-read it and enforce it ? I would guess so if there is also a >> section of the protocol addressing asset exchange. In this case the >> problem is still more complex than anticipated (how do I restrict next >> owner or next grid from restricting next owner or grid from >> grid-exchanging the asset, etc.) >> >> Nevertheless, the entire issue is avoided by keeping content hosted in >> its original grid, and the renderview being supplied by multiple >> sources (according to the endpoint identity's credentials, if required >> by the source grid implementation). Isn't it ? >> > > Just how many separately hosted grids/asset servers are we talking about > here? > > And how many assets? > > > SL, sorry to keep bringing it up, but its an important usecase, has 20,000 > simulators and some > ludicrous number of "assets" to deal with. If there's no local caching of > assets on any other grid, > permissions allowing, then the SL servers would be expected to be asset > server to the metaverse > and they already groan under the strain of talking to the limited SL world. > The metaverse is > projected to become 100-100x larger than Secondlife. the AWG's original > mission was to try to > desing a SL-like meta-grid that would handle such "scary numbers." We can't > just handwave > the issues away and suggest that existing systems and architectures will > "just do it" in some way. > > > Permissions/digital rights of SOME kind is required for any asset that > isn't identified as > Creative Commons" and even there, a CC license can vary quite a bit. there's > a ccREL > (rights expression language) defined just to identify variations of the > Creative Commons license, > and CC is NOT enough to handle all the possible needs for digital rights. > > > L > From john.hurliman@intel.com Mon Feb 23 14:18:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA5B3A63D3 for ; Mon, 23 Feb 2009 14:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.87 X-Spam-Level: X-Spam-Status: No, score=-5.87 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, J_BACKHAIR_43=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-ibZarcpsSi for ; Mon, 23 Feb 2009 14:18:16 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 3EF0C3A6817 for ; Mon, 23 Feb 2009 14:18:16 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 23 Feb 2009 14:11:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,256,1233561600"; d="scan'208";a="389151684" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by orsmga002.jf.intel.com with ESMTP; 23 Feb 2009 14:27:12 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Mon, 23 Feb 2009 15:18:24 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Mon, 23 Feb 2009 15:18:22 -0700 Thread-Topic: [mmox] XML serialization Thread-Index: AcmWAEW4YMZUOSbuTKuxaZegCQw2FgAA0oZA Message-ID: <62BFE5680C037E4DA0B0A08946C0933D502639CF@rrsmsx506.amr.corp.intel.com> References: <49A30D7A.3040003@gmail.com> <2F80CC37-A5BD-4EAD-8E12-D31A21912A8B@lindenlab.com> In-Reply-To: <2F80CC37-A5BD-4EAD-8E12-D31A21912A8B@lindenlab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:18:21 -0000 Speaking as the maintainer of OpenSim's LLSD<->XML serialization library (O= penMetaverse.StructuredData) I can say there would be zero resistance from = me in adopting a better serialization. In fact, I would greet the changes w= ith open arms, as would most people in the open source virtual world sphere= . Please do not put any of the OpenSim/OpenMetaverse efforts in the same se= ntence when claiming that improvements will be met with resistance. If ther= e is going to be a significant amount of resistance to anything that improv= es on deployed and working Second Life technology, then I don't think this = will get very far. John >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Meadhbh Hamrick (Infinity) >Sent: Monday, February 23, 2009 1:47 PM >To: Jon Watte >Cc: mmox@ietf.org >Subject: Re: [mmox] XML serialization > >Catherine... Jon... > >can you create a proposal for a next generation XML serialization? > >the existing serialization is in current use by SL, OpenSim and PyOGP, >so there's probably going to be a lot of resistance to changing >something that currently works and is deployed. > >keep in mind, however, that OGP does not use XML to represent it's >PDUs, it uses LLSD. XML is one of three defined serializations of >LLSD. it's a subtle difference, but important. > >for instance... is there a benefit to explicitly adding support for >namespaces to the XML serialization? there was a bit of discussion >about this amongst some AWG members, and the consensus was... "why >bother? the XML (presentation layer) is not the place where you want >to extend the PDU... you want to extend it in the LLSD / LLIDL >definition of the interaction." > >but, i still think it's an interesting idea as it might allow systems >that use XML serialization exclusively to extend display and >distribution options of various PDUs. > >-cheers >-m > >On Feb 23, 2009, at 12:56 PM, Jon Watte wrote: > >> Catherine Pfeffer wrote: >>> >>> >>> >>> success >>> true >>> >>> >>> something_i_like_to_eat_on_sundays >>> bananas >>> >>> >>> >> >> A better way is >> >> >> true >> > key=3D"something_i_like_to_eat_on_sundays">bananas >> >> >> natural way to express it.This has less of the angle bracket tax, >> and it has a VERY straight-forward parsing style. In fact, in my >> opinion it's the most In XPath, it's now trivial: >> "value[@key=3Dsuccess]" >> >> >> I'm working on a list of the things I think are wrong with the >> current proposal, of which this is one thing (there are about six). >> If we're open to change on those things (including this), then I >> could get behind the LLSD. Stay tuned :-) >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > >_______________________________________________ >mmox mailing list >mmox@ietf.org >https://www.ietf.org/mailman/listinfo/mmox > From jwatte@gmail.com Mon Feb 23 14:35:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24D993A6954 for ; Mon, 23 Feb 2009 14:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M71kQpuYSVAP for ; Mon, 23 Feb 2009 14:35:36 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.248]) by core3.amsl.com (Postfix) with ESMTP id 2149E3A6817 for ; Mon, 23 Feb 2009 14:35:35 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1186413ana.4 for ; Mon, 23 Feb 2009 14:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=iIdWyE49vVhelie7Me0glWwOXnZourbOOYwu9HRdgb0=; b=NuUckFWovsJGIpr2xnvI/ZmIEHUW8xVKmN8gxUD5yK6YerSE/g27SVIVDVSwDeDPOG 9hMh/OCRI6hpBkBmqxtsVs8ktN6bUlle/0tHQToR02dO84lOxamFjK3o6ns6sV1ttTWI q49N5bo5YMrlSO71ROOYyfTFarw3HGZLw9qDA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KgOl8fw2LphDZPKEjgZpFg78GOYyBvfucJJ+h7KTtdMHs+ke4nF60OIqNDVRs2BKk7 7iODtnILdd2PNA07A5CXjPCVTv1m7ua1wAd9yQhQKzBIlfp1Sx8NHPFIwlvAuIhJ+BP3 Z4MyXrJuXeOeOaAo2CFVF2ktsYbhE5tnOwAfc= Received: by 10.100.125.14 with SMTP id x14mr4778647anc.145.1235428552283; Mon, 23 Feb 2009 14:35:52 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c37sm9538903ana.22.2009.02.23.14.35.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 14:35:51 -0800 (PST) Message-ID: <49A324C5.6060006@gmail.com> Date: Mon, 23 Feb 2009 14:35:49 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <49A30D7A.3040003@gmail.com> <2F80CC37-A5BD-4EAD-8E12-D31A21912A8B@lindenlab.com> In-Reply-To: <2F80CC37-A5BD-4EAD-8E12-D31A21912A8B@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:35:37 -0000 Meadhbh Hamrick (Infinity) wrote: > the existing serialization is in current use by SL, OpenSim and PyOGP, > so there's probably going to be a lot of resistance to changing > something that currently works and is deployed. Honestly, for a vendor neutral standard, I don't think that argument holds much water. I have put a write-up of the high-level points I want to see addressed for LLSD to work as a general purpose data description language for interoperable virtual worlds here: http://www.interopworld.com/node/32 Note that it is not an in-detail specification edit, because it addresses a large number of concerns -- instead, it's a checklist of in-detail edits that would have to be done for LLSD to "fit the bill" in my opinion. However, I'm not sure that we should actually make all those edits just yet, because I think it's still too early to actually decide to standardize a data interchange description language. Sincerely, jw From jwatte@gmail.com Mon Feb 23 14:37:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B4E3A6921 for ; Mon, 23 Feb 2009 14:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFPSRhCDHzxU for ; Mon, 23 Feb 2009 14:37:06 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id E75803A6897 for ; Mon, 23 Feb 2009 14:37:05 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so2015244ywh.49 for ; Mon, 23 Feb 2009 14:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=JEcMwJFVnimAL4dsPgtFO6eKmnqZ8r+CscanLJ6wKrk=; b=gWAiuDtmGlZHkP++6qvpAlcq+dOExh7EF3zgnpAktzUad5NhdtHN/R1GPaRap+wNqV z2bipfyPrJpoamkztyFvba+BkwGyACKDyKX6veqGTvDPVHbzVq/fYrcIpusMKaPXWdm4 6eMAmsD72RfAE889ysscRFzPXjc/LwsOk1GA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ApGQvNvsZeMAQY1kIBOSGzsZfN3CAmpOlLZ9V/1+xjzWN0LrPS09Qkui+5puhPfkOh W0pyu4zbn6eT7lnhN81rlQCtupn1TEwuxxuL+QTtWSSGucpZ+KWYfEJm3K9kyMc6pqod Ba4AXtaHUcV+eEZFTKGprNbcpVT3TBEzGbhNs= Received: by 10.100.189.10 with SMTP id m10mr4190488anf.35.1235428643613; Mon, 23 Feb 2009 14:37:23 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d24sm7975750and.50.2009.02.23.14.37.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 14:37:23 -0800 (PST) Message-ID: <49A32520.9030507@gmail.com> Date: Mon, 23 Feb 2009 14:37:20 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <20090223.155250.2225.0@webmail24.vgs.untd.com> <49A31A11.2000503@gmail.com> <9EF1FD3F-6E1B-471B-B11B-169CA6CFAB7C@lindenlab.com> In-Reply-To: <9EF1FD3F-6E1B-471B-B11B-169CA6CFAB7C@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:37:07 -0000 Meadhbh Hamrick (Infinity) wrote: > my understanding of both OLIVE and there.com is that they both do not > allow arbitrary content upload, but instead require someone other than > the content creator approve (and transfer) the content. > > but... i could be wrong. OLIVE can support that just fine. The fact that most installations don't bother or wish for that to happen is a policy decision, not a mechanism problem. And the fact that pretty much all customers of ours make that policy decision might also mean something, although I'm not yet sure exactly what... Sincerely, jw From jwatte@gmail.com Mon Feb 23 14:48:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75C53A69AB for ; Mon, 23 Feb 2009 14:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BoNyx9NYg+g for ; Mon, 23 Feb 2009 14:48:21 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id D20213A68FE for ; Mon, 23 Feb 2009 14:48:20 -0800 (PST) Received: by gxk22 with SMTP id 22so5890350gxk.13 for ; Mon, 23 Feb 2009 14:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=b46+/M/7oBNzoVzDh0zDIoUwY7rnF39ye3R4aWxnjgY=; b=VAfvm80s8vdpHaNOWFFSXf1mgTskTBQ97iJdvLR7qanGZ7MA44M5g7C5D+ztsHquUC juYbgj+50Ao9H1JnW0OJPsw75uc5/k7bZbgo7DOWpZDox14YClX17RhQ3ucVXCExeS28 r5KSXk/GolRd3xfX+9Vd8x84vtoU1STimNADU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rlD4WbTKDQYDulEmRpUYUD06t6u/Nzwi0UpN2LI/2sR07Y5NcnMvPRNvrJ8szfMh/2 zqf3fEfM+tg3IaFuX7mwYRqyuftX9xzJRqVlbom2LOzLHXCxPwao7ICtR1yIoDNtSz21 qZ0yLnTRZ+YncCJQwnwYhDU4oSRnrRcGRPImA= Received: by 10.100.207.14 with SMTP id e14mr2365499ang.128.1235429318464; Mon, 23 Feb 2009 14:48:38 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c9sm547243ana.53.2009.02.23.14.48.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 14:48:37 -0800 (PST) Message-ID: <49A327C3.3070903@gmail.com> Date: Mon, 23 Feb 2009 14:48:35 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ann Otoole References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> <61dbdd7d0902230537n20f86856i8b392a80b1740bc0@mail.gmail.com> <53cd6c2e0902230559g73aa66e3u4026f34b95ec215@mail.gmail.com> <49A2FDB8.7000303@cox.net> <49A31323.8010804@gmail.com> <162490.78744.qm@web59103.mail.re1.yahoo.com> In-Reply-To: <162490.78744.qm@web59103.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:48:22 -0000 Ann Otoole wrote: > "If SL makes it a requirement that at least one SL customer is part of > any interoperation scenario involving SL servers, then SL has a > revenue stream for each such interoperation scenario." > > You forget that there was no requirement established that > participation in standards does not require for profit only status > sir. Or that sentence of yours was not stated in a sufficiently clear > and unambiguous manner. If Kapor/Rosedale wishes to establish interop > for non profit activities then Kapor/Rosedale will do so. It is their > money. > Absolutely! What I'm saying is that, even for people who don't want to give away computing time for free, the context of allowing their servers to host objects for "owners" who aren't actually customers can still make sense. This means that the model is universally applicable to both for-profit and for-free service providers. > > From the available information I have seen Second Life/Second Life > derivitives have the interoperability momentum at the moment. Exactly > what public "grid" does Forterra bring to the table anyway? How many > simulators is Forterra running in use 24*7? Forterra does not operate "grids." Forterra licenses technology and consulting to organizations who want to operate their own virtual world systems, of all different kinds of size and scale (think "dozens" to "millions"). We are a privately held company, and do not disclose our sales numbers publicly, but I can tell you that the number of OLIVE systems in production 24*7 is more than a handful. Additionally, OLIVE systems have been in use in interoperating virtual worlds of various kinds since 2005, which includes displaying avatars from other systems and vice versa, so I believe we have a lot of beneficial learning to share. > All it takes to deal with the issue of permissions in general is a > commitment to include permissions as a component in the standard, > whatever that looks like, and then create a sub committee/list to > debate permissions seperately and once consensus is acheived the > proposal be brought forth for debate. It's surprising to me that you seem to try to attack the credibility of the company I work for, yet the specific proposals I make on this group address exactly the specific requirements you say you want to address, in a way that makes them generally acceptable to all kinds of operators and all kinds of content creators. If there is some technical problem with the proposal I've made, that you believe would not serve the needs of some particular kind of content creator or virtual world operator, I would like to see that technical deficiency pointed out, so that it can be corrected. If not, then I expect you to actually support the specific proposal. Sincerely, jw From jwatte@gmail.com Mon Feb 23 14:51:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41BDA3A69AB for ; Mon, 23 Feb 2009 14:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8mT7OKUbM4L for ; Mon, 23 Feb 2009 14:51:01 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 4F60A3A63D3 for ; Mon, 23 Feb 2009 14:51:01 -0800 (PST) Received: by gxk22 with SMTP id 22so5893806gxk.13 for ; Mon, 23 Feb 2009 14:51:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=IGDrmZcGdpkL96Bbtjab7qInOzo3oISUYVBzrp7xJRo=; b=SjZLVSzhN097wsKA5pHoiSLrAUrF0bqMQcMKqHYfNVzPVCeajRxrToRUmZbZiU+wgt YObVM1Q7TZt7aI+1oEN60oz18RNjmxGR6vE4MRzvxQWCGuLwgbAoWhz0KbCMnzAyd/p0 E/n9ptHBqkLqczHet1boeLJlpziRhVUatXCjo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=AXVIjEUyVb71cjXpYbtompWxWoGgZFM/qvYGzUwnX3l+ahcblyimSbIk19Ccd2iWyE udJY7fwtQsLHiCxoCy8hdgSmfmniypx7QAvD/UEJ1vOT9sU1Krcn1QqG3zumGT1MAZxV 7B4b8OiCodvfbFrqeyNO8f8nfjT/Xxm8B+wq0= Received: by 10.100.112.10 with SMTP id k10mr4799269anc.114.1235429479522; Mon, 23 Feb 2009 14:51:19 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d35sm9700451and.38.2009.02.23.14.51.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 14:51:18 -0800 (PST) Message-ID: <49A32864.9040605@gmail.com> Date: Mon, 23 Feb 2009 14:51:16 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jesrad References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <49A30AE5.6060307@gmail.com> <53cd6c2e0902231323p641cd6d4s99d5f97a0340c4c2@mail.gmail.com> <49A31AD2.40402@gmail.com> <53cd6c2e0902231408y3fb35487v4125171b4ca5b16d@mail.gmail.com> In-Reply-To: <53cd6c2e0902231408y3fb35487v4125171b4ca5b16d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Permissions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:51:02 -0000 Jesrad wrote: >> soccer ball. My argument is simply against the idea that a single client >> connecting to two separate virutal world servers could provide a usefully >> consistent view of a virtual world simulation. >> > > Well, that's precisely the model Solipsis is based on, and it seems to > give a reasonably consistent view. The node with the soccer ball can > decide to let others know about it or not, and that makes little > difference for the rest of the world. In this model you're free to > In the general case, letting arbitrary, untrusted clients introduce content into a virtual world is not desirable. It would actually leave organizational users open to various kinds of discrimination and harassment lawsuits. However, if for Sollipsis you consider each "peer" as being a "server" in the proposal I've suggested (which, btw, was explicitly called out in the keynote slides for last year's IEEE MMVE), then it is the same model. I would expect that you could actually quite easily implement the proposed interoperability model into Sollipsis and interoperate with any other peer or server that wanted to interoperate with you. Sincerely, jw From markl@lindenlab.com Mon Feb 23 14:54:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCFE03A6ADC for ; Mon, 23 Feb 2009 14:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azytNbFpbVHE for ; Mon, 23 Feb 2009 14:54:33 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 100813A63D3 for ; Mon, 23 Feb 2009 14:54:33 -0800 (PST) Received: from nil.lindenlab.com (nil.lindenlab.com [10.1.16.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 628013DBC44C for ; Mon, 23 Feb 2009 14:54:51 -0800 (PST) Message-Id: <777F85B9-1676-491D-91C8-0E772253619D@lindenlab.com> From: Mark Lentczner To: mmox@ietf.org In-Reply-To: <49A30D7A.3040003@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 14:54:51 -0800 References: <49A30D7A.3040003@gmail.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:54:33 -0000 Catherine Pfeffer wrote: > > > > success > true > > > something_i_like_to_eat_on_sundays > bananas > > > Jon Watte wrote: > > key="something_i_like_to_eat_on_sundays">bananas > This format is notably more difficult for schemas (from XMLSchema to RelaxNG) to support, since value now has a key attribute that is only valid iff it is tested in a map element. Second, you have left out the top element, which needs to be something fixed, rather than being map or array or value depending on the structure of the data. Including a type attribute also makes things difficult for schemas, as the content of the value element now depends on the value of one of it's attributes. Including the key value as an attribute value will make this somewhat harder to edit in some systems where "human readable" text is generally much easier to handle as element content. Keeping the key value as element content also keeps the processing with key values consistent with the processing of string values with respect to string handling including normalization. The issue of wrapping each key value pair of a map in an entry element or just using ordered alternation is one of those infinite XML debates. The XPath argument doesn't hold: XPath expressions for selecting the value of the success entry in a map are about the same, and not all that difficult: Current draft LLSD: /llsd/map/key[.="success"]/following-sibling::*[1] Catherine's LLSD: /llsd/map/entry/key[.="success"]/following-sibling::*[1] Jon's LLSD: /llsd/map/value[@key="success"] True, Jon's LLSD yields a slightly smaller and cleaner XPath expression, the others are nothing out of the ordinary. - Mark Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From infinity@lindenlab.com Mon Feb 23 14:58:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5840B3A6ADC for ; Mon, 23 Feb 2009 14:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, J_BACKHAIR_43=1, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paHQRdu-Fbng for ; Mon, 23 Feb 2009 14:58:16 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 2480D3A69AB for ; Mon, 23 Feb 2009 14:58:15 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id BC2931414005; Mon, 23 Feb 2009 14:58:33 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: "Hurliman, John" In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D502639CF@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 14:58:33 -0800 References: <49A30D7A.3040003@gmail.com> <2F80CC37-A5BD-4EAD-8E12-D31A21912A8B@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D502639CF@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 22:58:17 -0000 i stand corrected... okay... John, Catherine and Jon... can you create a proposal for a next generation XML serialization? the existing serialization is in current use by SL, OpenSim and PyOGP, so there's probably going to be some resistance (from Linden) to changing something that currently works and is deployed and some people who have deployed OpenSim code (distinct from the people who created the code) MAY have some resistance. which is to say... my co-workers will pummel with rotten vegetables if i commit them to supporting another serialization, despite it's obvious advantages. before making a change of this sort, we would be doing a fair amount of testing to ensure our system works fine with the new serialization. this would require a non-zero amount of resources be spent on deploying the change. ergo, we would need some justification for making the change. that being said... "there are a number of deployed hosts with whom we want to interoperate who use this serialization" might be a suitable justification, or at least it would decrease the number of rotten vegetables i would be pelted with to an acceptably low level. but may i ask? why do we need to change something that we know works, is already deployed, and seems to work without flaw? my suspicion is that there's a belief that: 1. there are too many angle brackets, leading to wasted bandwidth and wasted CPU use. 2. it's hard to use with XSLT so my response would be: 1.a. can we look at the effect before making this change? my suspicion is that message sizes will be much more affected by turning on compressed content encoding than with the change from one DTD to another. 1.b. do any of us have numbers about how much more efficient the "new" encoding is vs. the "legacy" encoding? sure.. there are fewer angle brackets, but really you're just trading parsing angle brackets for parsing attributes and enclosing quote. 2.a. to a certain degree, the contents of the XML serialization are un-important compared to the contents of the object to which it deserializes. 2.b. why is this more of an issue with XML map elements than it was when people were trying to use Apple plists with XSLT? so... my recommendation might be... * can someone write a "next generation" XML serialization proposal? * can we do a bake off? * first with testing the space savings between the two serialization schemes after compressed content encoding is taken into account and * second with seeing how much of a decoding speed improvement you get from moving from keys in their own elements to keys as attributes. -cheers, -meadhbh On Feb 23, 2009, at 2:18 PM, Hurliman, John wrote: > Speaking as the maintainer of OpenSim's LLSD<->XML serialization > library (OpenMetaverse.StructuredData) I can say there would be zero > resistance from me in adopting a better serialization. In fact, I > would greet the changes with open arms, as would most people in the > open source virtual world sphere. Please do not put any of the > OpenSim/OpenMetaverse efforts in the same sentence when claiming > that improvements will be met with resistance. If there is going to > be a significant amount of resistance to anything that improves on > deployed and working Second Life technology, then I don't think this > will get very far. > > John > >> -----Original Message----- >> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On >> Behalf Of >> Meadhbh Hamrick (Infinity) >> Sent: Monday, February 23, 2009 1:47 PM >> To: Jon Watte >> Cc: mmox@ietf.org >> Subject: Re: [mmox] XML serialization >> >> Catherine... Jon... >> >> can you create a proposal for a next generation XML serialization? >> >> the existing serialization is in current use by SL, OpenSim and >> PyOGP, >> so there's probably going to be a lot of resistance to changing >> something that currently works and is deployed. >> >> keep in mind, however, that OGP does not use XML to represent it's >> PDUs, it uses LLSD. XML is one of three defined serializations of >> LLSD. it's a subtle difference, but important. >> >> for instance... is there a benefit to explicitly adding support for >> namespaces to the XML serialization? there was a bit of discussion >> about this amongst some AWG members, and the consensus was... "why >> bother? the XML (presentation layer) is not the place where you want >> to extend the PDU... you want to extend it in the LLSD / LLIDL >> definition of the interaction." >> >> but, i still think it's an interesting idea as it might allow systems >> that use XML serialization exclusively to extend display and >> distribution options of various PDUs. >> >> -cheers >> -m >> >> On Feb 23, 2009, at 12:56 PM, Jon Watte wrote: >> >>> Catherine Pfeffer wrote: >>>> >>>> >>>> >>>> success >>>> true >>>> >>>> >>>> something_i_like_to_eat_on_sundays >>>> bananas >>>> >>>> >>>> >>> >>> A better way is >>> >>> >>> >> key="something_i_like_to_eat_on_sundays">bananas >>> >>> >>> natural way to express it.This has less of the angle bracket tax, >>> and it has a VERY straight-forward parsing style. In fact, in my >>> opinion it's the most In XPath, it's now trivial: >>> "value[@key=success]" >>> >>> >>> I'm working on a list of the things I think are wrong with the >>> current proposal, of which this is one thing (there are about six). >>> If we're open to change on those things (including this), then I >>> could get behind the LLSD. Stay tuned :-) >>> >>> Sincerely, >>> >>> jw >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From jwatte@gmail.com Mon Feb 23 15:02:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B81128C243 for ; Mon, 23 Feb 2009 15:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rJlgDVVIskH for ; Mon, 23 Feb 2009 15:02:55 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 774D528C242 for ; Mon, 23 Feb 2009 15:02:55 -0800 (PST) Received: by gxk22 with SMTP id 22so5908840gxk.13 for ; Mon, 23 Feb 2009 15:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=kMkMRwV5A5J/28Y/rkxiE2i0WhjhYCXEB+11hBp7Jpc=; b=gG1AsGYhgVTca0HQ8uUxmiA4WiGTrMPiUTpWtUWfETHk5nIQaOHQZaEqyTqFJ3skP+ c1ZgkM6EOJ8CF/wG8MMP0DH/Vf6IWd6GO9TUWhP5Vw9YBzT/3SrSbMhs2G+Dy36wqwTI LaVntAk581JvAwUVojDzC/XFIjIJNYunJAFbw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=EMXW1M/bYjQEdLQEBw4gyrPp2fPj4EhQPFZo5CCSOslwneq5mgHAhIJ/Kj/pPtrCvy rbfmFWrtiTPH7SNVfMNxXog6VUGfopq06FbAzvl6LBGlzmb/iFaVgeg2r1ASfZ68p41Y +w5pzozWv4hVSJQ4XiPN9qufXcpoA9pWs2Ihs= Received: by 10.100.138.10 with SMTP id l10mr4903973and.25.1235430192792; Mon, 23 Feb 2009 15:03:12 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c9sm5798357ana.13.2009.02.23.15.03.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 15:03:12 -0800 (PST) Message-ID: <49A32B2E.5030606@gmail.com> Date: Mon, 23 Feb 2009 15:03:10 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mark Lentczner References: <49A30D7A.3040003@gmail.com> <777F85B9-1676-491D-91C8-0E772253619D@lindenlab.com> In-Reply-To: <777F85B9-1676-491D-91C8-0E772253619D@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 23:02:56 -0000 Mark Lentczner wrote: > Jon Watte wrote: >> >> > key="something_i_like_to_eat_on_sundays">bananas >> > > This format is notably more difficult for schemas (from XMLSchema to > RelaxNG) to support, since value now has a key attribute that is only > valid iff it is tested in a map element. Second, you have left out > the top element, which needs to be something fixed, rather than being > map or array or value depending on the structure of the data. > Yes, my illustration was only an illustration of how to turn a tag-fest into something more useful. > Including a type attribute also makes things difficult for schemas, as > the content of the value element now depends on the value of one of > it's attributes. > I don't think you can verify the content of any element absent the actual executable code endpoint. Trying to do that in schema is pretty useless IMO. For example, if we have a "float64_3" type for global position, then perhaps a schema validator could verify that the content of that element would be three float64 values separated by commas (assuming that's the defined serialization), but there would be no way for the schema to validate that that position was actually semantically valid within the target context, because that's a simulation property. > Including the key value as an attribute value will make this somewhat > harder to edit in some systems where "human readable" text is > generally much easier to handle as element content. Keeping the key > value as element content also keeps the processing with key values > consistent with the processing of string values with respect to string > handling including normalization. > My experience is the opposite. Hence, my proposed change :-) Also, my suggested serialization is invariant to child node re-ordering. Most of the time, that's not important, but for some cases, where a tree might be put into a hash map for fast access, it matters. Not-order-specific XML is generally faster to parse and more robust, when you can actually assume it's non-order-specific. I'd be comfortable with backing off to say that the element tag name is the data type, while key is still an attribute, but from my experience, putting the type as an attribute as well actually works out better in practice. Sincerely, jw From dyerbrookme@juno.com Mon Feb 23 15:42:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F099D28C209 for ; Mon, 23 Feb 2009 15:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ThAPQcCodg3 for ; Mon, 23 Feb 2009 15:42:57 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 7434C28C228 for ; Mon, 23 Feb 2009 15:42:57 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail14.vgs.untd.com [10.181.12.154]) by smtpout06.vgs.untd.com with SMTP id AABE4GPC9AUKZZ32 for (sender ); Mon, 23 Feb 2009 15:42:23 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNT/IJsIGU8sS4m3Yr+Jt6Jg== Received: (from dyerbrookme@juno.com) by webmail14.vgs.untd.com (jqueuemail) id N95FCB4U; Mon, 23 Feb 2009 15:42:16 PST Received: from [68.161.198.3] by webmail14.vgs.untd.com with HTTP: Mon, 23 Feb 2009 23:41:32 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Mon, 23 Feb 2009 23:41:32 GMT To: RGehorsam@forterrainc.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.184132.16346.0@webmail14.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:917333643 X-MAIL-INFO: 2868911c9109694d159c5d159c8505d19c615ca9d1385c5cddf5e9c871dcfc8948c98845c84d155db55d09c988ace925ec898cccf1a1ec1c2c X-UNTD-Peer-Info: 10.181.12.154|webmail14.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, jwatte@gmail.com, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 23:42:59 -0000 Once again, just to be clear again: There.com has a central-clearing hou= se for content. That's the point that's relevant here. The fact that Forterra, which shares a close history with There.com base= d on the same technology, obviously does not clear its private clients' = contents on their private grids shouldn't distract from the point about = There.com, where the user does not have that privilege. (http://en.wikip= edia.org/wiki/Forterra_Systems_Inc, "There is based on shared technology= with Forterra Systems that was initially developed in conjunction with = a US Army project.[2] The There service was spun off to Makena Technolog= ies in 2005") The statement "There/Forterra context" isn't a claim about Forterra not = letting its private clients upload content -- I knew that before, and go= t it again when it was pointed out; I did NOT claim that this company, w= hose demonstrations I've seen in person at expositions, was somehow clea= ring its clients' customized content using its software. No. Rather, it'= s about *how you deal with IP theft* which is either a) central clearanc= e or b) private grid with corporate or government firewall -- solutions = that do not involve freedom for the user on a public grid, i.e. open to = the public by subscription, and involve a subordinate relationship to a = user facing an administrator on a private grid. None of these correctives and admonishments for alleged "erroneous assum= ptions" somehow perceived should distract from the point at hand here: T= here.com has a model for users that involves clearing their content thro= ugh a central administrator; Forterra's clients have a solution that inv= olves firewalls. Neither should become the sole models for interoperabil= ity. The clearance of content through a central committee in There.com as a w= ay of handling the problem of appropriateness AND the problem of IP cont= rol is *one way* to solve the problem of IP protection. It isn't the onl= y one. And it can't work for SL, which already has user content produced= spontaneously by the user with the tools, with a regime only of TOS abu= se-reporting and DMCA takedowns after the creation. = That's the point here; the point here isn't somehow to imply that Forter= ra's customers today somehow clear content through them. That was in fac= t never said and never implied. In fact what was said that Forterra's ev= idently customers solve the IP problem *another* way which is through go= vernment and corporate firewalls. So unless the project of interoperabil= ity is enforcing only two solutions for IP protection -- central clearan= ce OR government/corporate firewalls -- then something still has to be d= one about c/m/t in the metadata as a permissions system on open grids wh= ere the public openly creates. ____________________________________________________________ Grow your small business with email marketing. Click Now. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEFeRJRL0sMzeN5pbUzb9j= Wg2LQGMLBWGV9hzwV7QK2vMlskIm788/ From jwatte@gmail.com Mon Feb 23 15:58:28 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAAF03A6A7F for ; Mon, 23 Feb 2009 15:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.455 X-Spam-Level: X-Spam-Status: No, score=-1.455 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAJecQ+llgST for ; Mon, 23 Feb 2009 15:58:27 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id BDA173A67B4 for ; Mon, 23 Feb 2009 15:58:26 -0800 (PST) Received: by gxk22 with SMTP id 22so5972760gxk.13 for ; Mon, 23 Feb 2009 15:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ix2EpIqdh8zwJ0osphx/wfarxwc3huG4fBy/TRMYLbM=; b=CYEWxuyyygkYqgXdL53EnpJ6CqINlgRmX8SGyrxyyLpZiS5SgkMHF3PiSXwJ36+/lx xOTXkjgQeboqpE3Oc4++fwJN/M86HGZ5N4fSLxJLL6iszkHRfUNcZlkUqMIbgbRVcWwk Qagg/4MQeKyU2YwINJPZ7X1xR9C2HpEBJLxcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=uerqb1qDRAAQ9s7vZJId5UJ+EquNbIiAEgVVyQA+Xom6KcovlA1R575irLVytHnbGX tQk7Hr5tiNAM7fARaM+RkvPJmQcfTjgsyo9HXaazBUvh6ELSME4CmJQPF3G0aBhDET8G zIpxj5/fqKAeUS01Zlxm8o5sSdpMGfuFEoZM4= Received: by 10.100.153.6 with SMTP id a6mr4907474ane.76.1235433523235; Mon, 23 Feb 2009 15:58:43 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c40sm9126665anc.48.2009.02.23.15.58.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 15:58:42 -0800 (PST) Message-ID: <49A33830.1060509@gmail.com> Date: Mon, 23 Feb 2009 15:58:40 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <49A30D7A.3040003@gmail.com> <2F80CC37-A5BD-4EAD-8E12-D31A21912A8B@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D502639CF@rrsmsx506.amr.corp.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 23:58:28 -0000 Meadhbh Hamrick (Infinity) wrote: > our system works fine with the new serialization. this would require a > non-zero amount of resources be spent on deploying the change. ergo, > we would need some justification for making the change. > Do you agree that any kind of generally suitable interoperability will require engineering effort, sometimes significant, on the part of all possible implementors, including Linden Lab or the Open Sim developers? You do not have to update your internal serialization at all just because we, collectively, design a serialization scheme with differences. You don't need to do any work until and unless such time that 1) there is an actual standard, or at least a concrete proposal 2) you decide that supporting this standard is in the best interests of your company or group > > but may i ask? why do we need to change something that we know works, > is already deployed, and seems to work without flaw? > Because it can work better. It can be more compact, it can better suit a variety of parser styles, it can be easier read and written by human beings, it can be easier expanded or adapted, it can more easily be processed using fast hashing-based (order independent) processing methods. If your argument is that "while I understand that some other people feel that direction X is better, we are currently using direction Y in the Second Life implementation, so I think Second Life's way should prevail" then you're not actually signed on to the generally applicable, vendor neutral interoperability standard bandwagon. > * can we do a bake off? Once we're done with a serialization format that fulfills all the necessary requirements, I believe there won't be anything "else" to bake-off against. See here for some requirements I would put on a standardized format: http://www.interopworld.com/node/32 I will copy and paste for the convenience of those who don't like out-of-line references: I have looked at the proposal, and see a number of issues that I think need to be addressed before the proposal can be used as a general interoperability standard. ! Proposal Name The name probably should change to something like "VWSD" to avoid any accusation of vendor bias. I trust we can just get this done without too much argument about specific naming. ! Large and Small Integers The "integer" data type needs to be more flexible. 64-bit integers are important, and you can even view UUIDs as 128-bit integers. I propose that integers can be specified as a specific bit width, and signed or unsigned. If you want to stay byte aligned, the set of allowable sizes may be limited to 8, 16, 32 or 64. I additionally propose that a Variable Length Integer Encoding be specified. ! Float32 and Float16 Reals should come in at least two forms: 64-bit and 32-bit. The reason is that localized position relative to some center usually is best described as a 32-bit float. Additionally, mesh data is generally described as 32-bit float vertices, rather than 64-bit. There may be some additional benefit in supporting 16-bit floats, for things like normals, color values or direction vectors. ! Compact Binary Serialization There needs to be support for a binary serialization that does not contain embedded type or key references, but instead use explicit external schema. Thus, to describe a "quaternion" you would simply specify four fp16 (or fp32) values in sequence, with no specific type information. This can extend to describing general entity property values: the type information can be carried by the schema for the entity, and does not need to be encoded in the actual data. Allowing external schema leads to significant bandwidth savings during transmission. ! XPath Friendly XML The XML encoding needs to be XPath friendly, and friendly to introducing or adapting new types in a negotiated higher-version schema. Generally, this means that it looks something like: true 67.0 The currently proposed serialization is poor because it's not easy or efficient to find specific values you care about by key; it's also inefficient because it requires any new data types to update the XSD schema, because each type is a tag name. ! Machine Parsable Descriptions It is likely that the language describing the serialization structures will actually be read by machines at runtime, rather than used to generate code. This is definitely true for things like proxy servers and systems that treat entities as "generic collections of data" but want to have some understanding of the underlying data for display, translation, or other processing. While it would be possible to write a parser for the current LLSD syntax, introducing a new language syntax into the world doesn't seem warranted. I propose that the data structure definition language be moved to some XML schema. Sincerely, jw From john.hurliman@intel.com Mon Feb 23 16:48:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B15128C23E for ; Mon, 23 Feb 2009 16:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.22 X-Spam-Level: X-Spam-Status: No, score=-5.22 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4hfDJg89IDu for ; Mon, 23 Feb 2009 16:48:35 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 1451728C23B for ; Mon, 23 Feb 2009 16:48:35 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 23 Feb 2009 16:46:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,256,1233561600"; d="scan'208";a="433547839" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by fmsmga002.fm.intel.com with ESMTP; 23 Feb 2009 16:44:47 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Mon, 23 Feb 2009 17:48:53 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Mon, 23 Feb 2009 17:48:50 -0700 Thread-Topic: [mmox] XML serialization Thread-Index: AcmWErMRK86K2hmoTx2RqOSpKlVTxQAA98fA Message-ID: <62BFE5680C037E4DA0B0A08946C0933D50263B34@rrsmsx506.amr.corp.intel.com> References: <49A30D7A.3040003@gmail.com> <2F80CC37-A5BD-4EAD-8E12-D31A21912A8B@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D502639CF@rrsmsx506.amr.corp.intel.com> <49A33830.1060509@gmail.com> In-Reply-To: <49A33830.1060509@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 00:48:36 -0000 >-----Original Message----- >From: Jon Watte [mailto:jwatte@gmail.com] >Sent: Monday, February 23, 2009 3:59 PM >To: Meadhbh Hamrick (Infinity) >Cc: Hurliman, John; mmox@ietf.org >Subject: Re: [mmox] XML serialization > >Meadhbh Hamrick (Infinity) wrote: >> our system works fine with the new serialization. this would require a >> non-zero amount of resources be spent on deploying the change. ergo, >> we would need some justification for making the change. >> > >Do you agree that any kind of generally suitable interoperability will >require engineering effort, sometimes significant, on the part of all >possible implementors, including Linden Lab or the Open Sim developers? > >You do not have to update your internal serialization at all just >because we, collectively, design a serialization scheme with >differences. You don't need to do any work until and unless such time >that >1) there is an actual standard, or at least a concrete proposal >2) you decide that supporting this standard is in the best interests of >your company or group > >> >> but may i ask? why do we need to change something that we know works, >> is already deployed, and seems to work without flaw? >> > >Because it can work better. It can be more compact, it can better suit a >variety of parser styles, it can be easier read and written by human >beings, it can be easier expanded or adapted, it can more easily be >processed using fast hashing-based (order independent) processing >methods. > >If your argument is that "while I understand that some other people feel >that direction X is better, we are currently using direction Y in the >Second Life implementation, so I think Second Life's way should prevail" >then you're not actually signed on to the generally applicable, vendor >neutral interoperability standard bandwagon. > >> * can we do a bake off? > >Once we're done with a serialization format that fulfills all the >necessary requirements, I believe there won't be anything "else" to >bake-off against. >See here for some requirements I would put on a standardized format: >http://www.interopworld.com/node/32 > >I will copy and paste for the convenience of those who don't like >out-of-line references: > >I have looked at the proposal, and see a number of issues that I think >need to be addressed before the proposal can be used as a general >interoperability standard. > >! Proposal Name > >The name probably should change to something like "VWSD" to avoid any >accusation of vendor bias. I trust we can just get this done without too >much argument about specific naming. > No opinion here, other than not tying it to virtual worlds. All we are doin= g is defining yet another IDL, because the group asserts that ASN.1, Apache= Thrift, Google Protocol Buffers, and any other proposed solutions will not= work as a virtual world interop base for technical or political reasons. H= owever, that doesn't mean that we have to create an IDL that only works for= virtual worlds. >! Large and Small Integers > >The "integer" data type needs to be more flexible. 64-bit integers are >important, and you can even view UUIDs as 128-bit integers. I propose >that integers can be specified as a specific bit width, and signed or >unsigned. If you want to stay byte aligned, the set of allowable sizes >may be limited to 8, 16, 32 or 64. I additionally propose that a >Variable Length Integer Encoding be specified. > Agreed on supporting multiple lengths of signed vs. unsigned. I would reall= y like to see int32, int64, uint32, uint64 and could take or leave the rest= personally. Doing variable length integer encoding (such as the base-128 v= arints used in Google Protocol Buffers: http://code.google.com/apis/protoco= lbuffers/docs/encoding.html) would be a nice fix for the binary encoding. >! Float32 and Float16 > >Reals should come in at least two forms: 64-bit and 32-bit. The reason >is that localized position relative to some center usually is best >described as a 32-bit float. Additionally, mesh data is generally >described as 32-bit float vertices, rather than 64-bit. There may be >some additional benefit in supporting 16-bit floats, for things like >normals, color values or direction vectors. > Just adding 32-bit float support is probably fine for most use cases. I don= 't understand the reasoning behind only supporting 64-bit floats in LLSD at= all, especially considering the vast majority of floating point data in Se= cond Life is 32-bit. >! Compact Binary Serialization > >There needs to be support for a binary serialization that does not >contain embedded type or key references, but instead use explicit >external schema. Thus, to describe a "quaternion" you would simply >specify four fp16 (or fp32) values in sequence, with no specific type >information. This can extend to describing general entity property >values: the type information can be carried by the schema for the >entity, and does not need to be encoded in the actual data. Allowing >external schema leads to significant bandwidth savings during >transmission. > Maybe one of the existing binary serializations used by Apache Thrift or Go= ogle Protocol Buffers could be supported? Even if we don't want to tie the = LLSD spec to third party references, something that draws on the techniques= from those IDLs would be much more efficient than the current LLSD binary.= I think the need to tightly couple the IDL and type system for this kind o= f serialization highlights the fact that LLSD/LLIDL is not doing anything n= ew; the same dependencies are still present. >! XPath Friendly XML > >The XML encoding needs to be XPath friendly, and friendly to introducing >or adapting new types in a negotiated higher-version schema. Generally, >this means that it looks something like: > >true >67.0 > >The currently proposed serialization is poor because it's not easy or >efficient to find specific values you care about by key; it's also >inefficient because it requires any new data types to update the XSD >schema, because each type is a tag name. > >! Machine Parsable Descriptions > >It is likely that the language describing the serialization structures >will actually be read by machines at runtime, rather than used to >generate code. This is definitely true for things like proxy servers and >systems that treat entities as "generic collections of data" but want to >have some understanding of the underlying data for display, translation, >or other processing. While it would be possible to write a parser for >the current LLSD syntax, introducing a new language syntax into the >world doesn't seem warranted. I propose that the data structure >definition language be moved to some XML schema. > -1 on this. The LLIDL syntax is very easy to parse, and I posted a simple g= rammar file to generate a lexer/parser. Introducing a new XML schema create= s just as much implementation work. However, LLSD/LLIDL is still encouragin= g code that is difficult to read and easy to break. Data should enter and e= xit in the form of a struct, not a map of string/value pairs where anything= can be inserted but only a fixed subset of possibilities will be valid. > >Sincerely, > >jw John=20 From lisa.dusseault@gmail.com Mon Feb 23 16:49:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A99028C26A for ; Mon, 23 Feb 2009 16:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tRoHd1ASSuh for ; Mon, 23 Feb 2009 16:49:35 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 57BDB28C1C6 for ; Mon, 23 Feb 2009 16:49:35 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2051818rvb.49 for ; Mon, 23 Feb 2009 16:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=986Inz51lusV3A43rpK4PQ2CB2FbK7Hy53p2UcCoA44=; b=OhBcfb8rfcVlYpV4p/pyhHLe8lRQEn9XwoonkvAErCi5YelhmeQnapTVjxhe4rJJO4 1DSXYlCMkIUALxldYajC2Gav4dPTw455fkchRzysLNfB2xJSbF/H6ZAYR8822SRKb5df e7E58oUslKNhOcC+5/b4lQ9YUrT3Q/CO0qNHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I9igeiaVjFKSbFOlzhLkbCCC1mL5agRZCHIy12PE22hO/adPEPhJCK1gF8LNyYn4QH g4cXjoD3msA0eKIcJ9Uf7I22tw0OJJhHnTOd/Sos1KYvGuxLzAcEqsSVJnAxmXHn3VgD /5TuhY5N6C+9uDBsb403JDQSZTpFvxxooIeME= MIME-Version: 1.0 Received: by 10.141.132.1 with SMTP id j1mr2258948rvn.277.1235436593119; Mon, 23 Feb 2009 16:49:53 -0800 (PST) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> <61320.78349.qm@web82607.mail.mud.yahoo.com> <962799.66993.qm@web82608.mail.mud.yahoo.com> <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> <88DFFC67-0B59-4D65-86FB-8776899B794A@lindenlab.com> <499F10D7.5080605@gmail.com> Date: Mon, 23 Feb 2009 16:49:53 -0800 Message-ID: From: Lisa Dusseault To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=000e0cd295f44681f304639f7f99 Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] LLSD and content schema X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 00:49:36 -0000 --000e0cd295f44681f304639f7f99 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Finally, a topic on which I have more than passing technical familiarity: On Sat, Feb 21, 2009 at 1:18 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > In this sense XML is more restrictive because it REQUIRES you to create a > new DTD to extend an existing message flow (though presumably you would > configure your DTDs or Schemas to be easily extensible.) The way XML is used in IETF protocols certainly does not require anybody to create a new DTD to extend an existing message flow. E.g. in WebDAV XML request bodies, a client may insert additional elements at certain places (other places have defined meanings) and if the server doesn't recognize them it just ignores them. Same with Jabber. > > LLSD is intended to be used in a "loosely coupled" environment. one > "feature" of such an environment is that systems be resilient in the face of > heterogeneity in terms of component version. for example, consider a logging > system that received logging messages from a number of clients and stores > them for later analysis. when the system is initially deployed, messages may > be defined as the tuple (source, severity, description). it is not difficult > to imagine the situation where one client wishes to add a value to that > tuple to make it (source, facility, severity, description). in tightly bound > systems, you might create a new message PDU format, but both the client and > the server would need to know about this change at exactly the same time > (otherwise the server would signal an error when it received an unknown > message format. now imagine the mess if half of the systems were in one > administrative domain and the rest in another. > > Again, this is very much the way IETF uses XML, so I don't see this as a distinguishing point between XML and LLSD. Also, related to this thread, the IETF rarely does binary protocols in the layers I've been involved in. Clear text, perhaps with compression at a lower layer, makes a protocol much easier to debug, maintain, test and make interoperate. Lisa --000e0cd295f44681f304639f7f99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Finally, a topic on which I have more than passing technical familiarity:
On Sat, Feb 21, 2009 at 1:18 AM, Meadhbh H= amrick (Infinity) <infinity@lindenlab.com> wrote:
 In this sen= se XML is more restrictive because it REQUIRES you to create a new DTD to e= xtend an existing message flow (though presumably you would configure your = DTDs or Schemas to be easily extensible.)

The way XML is used in IETF protocols certainly does not require a= nybody to create a new DTD to extend an existing message flow.  E.g. i= n WebDAV XML request bodies, a client may insert additional elements at cer= tain places (other places have defined meanings) and if the server doesn= 9;t recognize them it just ignores them.  Same with Jabber. 
 
=
LLSD is intended to be used in a "loosely coupled" environment. o= ne "feature" of such an environment is that systems be resilient = in the face of heterogeneity in terms of component version. for example, co= nsider a logging system that received logging messages from a number of cli= ents and stores them for later analysis. when the system is initially deplo= yed, messages may be defined as the tuple (source, severity, description). = it is not difficult to imagine the situation where one client wishes to add= a value to that tuple to make it (source, facility, severity, description)= . in tightly bound systems, you might create a new message PDU format, but = both the client and the server would need to know about this change at exac= tly the same time (otherwise the server would signal an error when it recei= ved an unknown message format. now imagine the mess if half of the systems = were in one administrative domain and the rest in another.

Again, this is very much the way IETF uses XM= L, so I don't see this as a distinguishing point between XML and LLSD.<= br>
Also, related to this thread, the IETF rarely does binary protocols = in the layers I've been involved in.  Clear text, perhaps with com= pression at a lower layer, makes a protocol much easier to debug, maintain,= test and make interoperate.

Lisa

--000e0cd295f44681f304639f7f99-- From jwatte@gmail.com Mon Feb 23 17:21:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95F128C1C6 for ; Mon, 23 Feb 2009 17:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkbe0U2vmo0h for ; Mon, 23 Feb 2009 17:21:22 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by core3.amsl.com (Postfix) with ESMTP id C8D0128C0DF for ; Mon, 23 Feb 2009 17:21:21 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1223644ana.4 for ; Mon, 23 Feb 2009 17:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ItENfNv59NiHqP/qnjH+PFylnj1vF1ltvkk1OE90vmc=; b=LapcCAIU1kRl4sGADr0mI2abRe8b8v8Cbg6oKMnA8SoWA4GreqsyPY5tX9PVFe45vA z3UoaJRkpI3n4JV75VtlgoZNhGyx3YmdCuF97UI0KEX2n52m9hTVkkTaSjHD3sti4mhx ZepD65igqNsKTh4mSyOflP/OL+3xFsl25uV9I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jgBt3Ah6V5cYEeqI/h4FpI3pBZzvSdnArM0QPZzLL2sc/JBhrthum3zCR9/4G0FWer lpMg8Gw4MEUarpv44QkOhO1E4Z0dtKekmzf/MY3kRNkS0bjee+oj4kdbb/LGFxfpDWLT q+VAK6FRuU2hAm87DbY8VR0DvWYbfIPT0x/vM= Received: by 10.100.133.1 with SMTP id g1mr4548757and.106.1235438493005; Mon, 23 Feb 2009 17:21:33 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b29sm6043918ana.11.2009.02.23.17.21.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 17:21:32 -0800 (PST) Message-ID: <49A34B9A.5060704@gmail.com> Date: Mon, 23 Feb 2009 17:21:30 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Hurliman, John" References: <49A30D7A.3040003@gmail.com> <2F80CC37-A5BD-4EAD-8E12-D31A21912A8B@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D502639CF@rrsmsx506.amr.corp.intel.com> <49A33830.1060509@gmail.com> <62BFE5680C037E4DA0B0A08946C0933D50263B34@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D50263B34@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:21:22 -0000 Hurliman, John wrote: > length integer encoding (such as the base-128 varints used in Google Protocol Buffers: http://code.google.com/apis/protocolbuffers/docs/encoding.html) would be a nice fix for the binary encoding. > > That needs a fix for signed-ness, though. My proposal is to encode the sign bit in the 6th bit of the first byte IF the value is less than 0 or greater than 127 (keeping the encoding of small positive integers to a single byte). For negative numbers, encode the one's complement and the sign bit, and negate when done. This nicely sidesteps problems you'd get when trying to encode two's complement in a variable-width container. But that might be a slightly premature technical detail ;-) > -1 on this. The LLIDL syntax is very easy to parse, and I posted a simple grammar file to generate a lexer/parser. Introducing a new XML schema creates just as much implementation My point is that XML for a schema language is even easier to parse: xd = new System.Xml.XmlDocument(); xd.LoadXml(...); Done. And this allows various code bases to easily adopt various levels of knowledge of the serialized data using existing tools, instead of having to add yet another kind of language parser with yet another set of mutually ambiguous or buggy implementations. Sincerely, jw From jwatte@gmail.com Mon Feb 23 17:22:42 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E9228C1C6 for ; Mon, 23 Feb 2009 17:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KEJsii8qq24 for ; Mon, 23 Feb 2009 17:22:42 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id E87A528C0DF for ; Mon, 23 Feb 2009 17:22:41 -0800 (PST) Received: by gxk22 with SMTP id 22so6065570gxk.13 for ; Mon, 23 Feb 2009 17:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=6VfyZsldUOBoL350Z0UYM88aOvPYGkfU3aJiIRmJCdo=; b=h1ISoRdwsIyxGVtJQvz66aKnY8dHOmMsj/XVC3wST8eYHdSe+yg24S7ONrDigKCbkF i1eRmPnqYGdFTN5tvYCvG9vqUPzUYjwCe8c2zO0ZoXHBudFkwLZmLpb6E9gMeUGCzVfY OhLB2c6ZNq8I58mwog0a6ZUXVxi6pWRlHal+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Tt8kETLHxg9w+nTHpR0VeY2l4/2l12ifogZbiR2/Ond3nMG1Lfp5iTakfr5ei6YwFT 978LTP7j62z1ZwUe/+OY6dsmBifPr8A0POGBHhxd05s0bE0PWVBcbjktNhsOkiK73uW5 T/gRv0i4gUlX2/y3NBgESt80tRW3DCHf01c1Q= Received: by 10.100.8.4 with SMTP id 4mr4742102anh.118.1235438579800; Mon, 23 Feb 2009 17:22:59 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b32sm1141143ana.55.2009.02.23.17.22.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 17:22:59 -0800 (PST) Message-ID: <49A34BF1.6050501@gmail.com> Date: Mon, 23 Feb 2009 17:22:57 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Lisa Dusseault References: <62BFE5680C037E4DA0B0A08946C0933D501FE18E@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D50262DA8@rrsmsx506.amr.corp.intel.com> <29656.28734.qm@web82607.mail.mud.yahoo.com> <61320.78349.qm@web82607.mail.mud.yahoo.com> <962799.66993.qm@web82608.mail.mud.yahoo.com> <53cd6c2e0902200741m2313b1eeqffc87c8601fd72e2@mail.gmail.com> <88DFFC67-0B59-4D65-86FB-8776899B794A@lindenlab.com> <499F10D7.5080605@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] LLSD and content schema X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:22:43 -0000 Lisa Dusseault wrote: > Also, related to this thread, the IETF rarely does binary protocols in > the layers I've been involved in. Clear text, perhaps with > compression at a lower layer, makes a protocol much easier to debug, > maintain, test and make interoperate. I agree, for services and transactional stuff, text protocols are much better. Real-time entity telemetry data probably needs to be binary, for the same reason that streaming video, or VoIP data is binary. Sincerely, jw From dyerbrookme@juno.com Mon Feb 23 17:24:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE4228C25A for ; Mon, 23 Feb 2009 17:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[AWL=2.589, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6B+t3Muj-uQ for ; Mon, 23 Feb 2009 17:24:38 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 5E81628C1C6 for ; Mon, 23 Feb 2009 17:24:38 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail20.vgs.untd.com [10.181.12.160]) by smtpout05.vgs.untd.com with SMTP id AABE4GVCTAWLCUV2 for (sender ); Mon, 23 Feb 2009 17:24:33 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNVdnaVrwNtX2cVPnIAnNE+Q== Received: (from dyerbrookme@juno.com) by webmail20.vgs.untd.com (jqueuemail) id N95L6RPH; Mon, 23 Feb 2009 17:24:05 PST Received: from [10.181.11.33] by webmail20.vgs.untd.com with HTTP: Tue, 24 Feb 2009 01:23:13 GMT X-Originating-IP: [10.181.11.33] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Tue, 24 Feb 2009 01:23:13 GMT To: dcolivares@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.202313.9421.0@webmail20.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 7:3:950807501 X-UNTD-Peer-Info: 10.181.12.160|webmail20.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:24:39 -0000 >Logic is not process Perhaps not, but deliberation and governance are. Everyone must have the= right to make a false or non-falsifiable proposition in an open society= in the course of debate. X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C7463A6B01 for ; Mon, 23 Feb 2009 17:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4a2grjIOh5dV for ; Mon, 23 Feb 2009 17:37:01 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 965573A6AFD for ; Mon, 23 Feb 2009 17:37:01 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2078413yxm.49 for ; Mon, 23 Feb 2009 17:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YvMThIlitgTOTS7OWAk21PHl/jUymRTGUFfFi7mwg5Q=; b=YNkUiDjici/IG0fTgJ179tJGHfCqA++MXaGVZkCOlL04i0E+wOem28rJppESx1LvAr FkxRfkC8WdwLXyPTNaJqtLoXmneexl/FtSnNU8RIcdGkw5fi+j7xVifkywN9UkJSkXtp YewIH9vQ/zepcN8VlUkbsrjC8EQwNGYyizeoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VFAeC1p2jLkFUqFAS7l0KcatVg2lWG/tbKEuETU3wwBQEoXsiFl55wE23RE+kLtuTs HonuYzd6REPHdc0raiP9qQYd1mgUi1E/AkYwVzocFITtMt1LDooIl1LJv2RW039YJUpf MZzAM5GyboRmzaEt99iqWZYiKciv+8f5U0T28= Received: by 10.100.43.14 with SMTP id q14mr2736846anq.60.1235439439174; Mon, 23 Feb 2009 17:37:19 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b32sm1169896ana.55.2009.02.23.17.37.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 17:37:18 -0800 (PST) Message-ID: <49A34F4C.8090800@gmail.com> Date: Mon, 23 Feb 2009 17:37:16 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090223.202313.9421.0@webmail20.vgs.untd.com> In-Reply-To: <20090223.202313.9421.0@webmail20.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:37:02 -0000 dyerbrookme@juno.com wrote: > "It's great that we're all interoperable now! woot! We love finally being able to download and upload our inventories from other worlds and also populating our barren servers with all It is my understanding that the current proposal does not even transfer inventory at all; it just transfers a representation of inventory. The current proposal is for a system where downloading and uploading of inventories between different servers is neither necessary nor specified. Sincerely, jw From belxjander@gmail.com Mon Feb 23 17:42:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10D9F3A657C for ; Mon, 23 Feb 2009 17:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yE0BDtaex8+t for ; Mon, 23 Feb 2009 17:42:10 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id 2F29D3A68B5 for ; Mon, 23 Feb 2009 17:42:09 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2070708rvb.49 for ; Mon, 23 Feb 2009 17:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=PBaA97eFKNVtzml797y0eHoK99EdnFKwHP1n0+LfNF4=; b=ofB6JfsWld4KWDV9eraHt2G/AO/1wlciFziFzkeMU47w5Al/rFKe3/oveabe+g5nEr AeB0Xkwmr2fmXijagQuv6DzDwNTrynEXC36DUdQ4iNPmWi1uV89a1vK06BgDgSni7NX8 h4IfSqyjfcFySMSBvujyvwcQrcZcjc6kkziv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=LnvLydFtNL/kKsqabQRzVMRla6686MVrdyWYdBmqoCTKeL+A4yGlzo2jOcUfVo+utr O/cCEl/KIhNM8Z9rH+REllYwpourgKa6BzDoMdsCqHsEN9hkV1NprkYyOLRBp5IemVBO jJAkosJBCxmZiQs4Y0RpcsN18tWThWubHuMPs= Received: by 10.141.28.2 with SMTP id f2mr2299255rvj.43.1235439747252; Mon, 23 Feb 2009 17:42:27 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g22sm6879421rvb.0.2009.02.23.17.42.25 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 17:42:26 -0800 (PST) From: Kajikawa Jeremy To: "dyerbrookme@juno.com" In-Reply-To: <20090223.140736.24438.0@webmail03.vgs.untd.com> References: <20090223.140736.24438.0@webmail03.vgs.untd.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ITcdQqs6UyvnYCm7USV7" Date: Tue, 24 Feb 2009 01:37:05 +0000 Message-Id: <1235439425.6608.80.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: "mmox@ietf.org" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:42:11 -0000 --=-ITcdQqs6UyvnYCm7USV7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable So *you* are this "Prokofy Neva" person Ive heard about... I always wondered if the reputation was deserved, ...that question is now answered for me at least. and I would expect you to put up equally the same as others on this list when asked for details... Im happy to state full details about myself on this list and invite anyone to refute me, but that is also taking conversations out of scope... My understanding of this list is to knock out a VW *agnostic* protocol with means to support *multiple* ideologies without exclusion and in an extensible manner. do you disagree? Jeremy Kajikawa AKA Belxjander Serechai AKA Freija Yoshikawa On Mon, 2009-02-23 at 19:07 +0000, dyerbrookme@juno.com wrote: > Dear Dan, >=20 > "Ad hominem" ("to the man") refers to people, not software programs or pl= atforms. Criticism of software concepts or people's ideas isn't an "ad homi= nem" attack; labelling perjoratively isn't even an "ad hominem" attack. Eve= n if this can somehow be construed as a "violation," there's been any numbe= r of such acts already on this list, that met with your silence. Ultimately= *you're* the one the characterized OpenSim as "Leninist"; I tend to agree,= given the absence of protections of IP and the rigid conceptions about how= the Metaverse must be organized with collectivization.=20 >=20 > As for "logical fallicies," yes, there's always the risk of being kicked = off the Latin boys' school debate team for violations of these sorts of arc= ane rhetoric rules. But, commonsense can prevail nevertheless and you can h= ave a normal conversation urging technologists not to sneak ideological pre= scriptions into the protocols. As for bullying, your effort to invoke the b= oys' school rules would be characterized as just that.=20 >=20 > It's important not to weld worldviews into the code and into the interope= rability in advance, whether Leninism, militarism, or any "ism". There shou= ld be authentic diversity and choice, and not a forced march to technocommu= nism. Virtual worlds need to be sustained by commerce, and commerce is sust= ained by property rights. Private property rights in general and specifical= ly intellectual property rights are ok; they are not wrong, they enable peo= ple to make a living, including technology vendors. Copyleftism and collect= ivism are only one ideology for the Internet, and can't be the only one. >=20 > Since there are a number of "Dan Olivares" on the Internet, could you exp= lain which one you are? >=20 > Prokofy Neva >=20 >=20 > ____________________________________________________________ > Click here to save cash and find low rates on auto loans. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLaW0FYMjWhFUjLaV0gAMua= vgDTXgbYSdN85xrhA3CrEcy6vcRaoQ/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-ITcdQqs6UyvnYCm7USV7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJo09BAAoJECHrKutFYVwT9SMP+wd/OC14Cj30qiCuUauaQWMN u5KGMeOvrsJX/I5cR+UbrQitzExXNH6xQlQGB1+jCx8vLmul41Vbu8kLzq1u892X GYGJWl1mTHZKBjIXg7EUEc1VyZFAbgyDLMoQjAT0vKidgObbnjKmcGtufz7t3tsS hHsKrNkDxPdcudcTkXuZ0nhyFkrSYQsvY+uiHRsJfazqVOOM5uvQ1e0H58+uyaPP nHXJU24Hy3GEjiFsaQMd5DgtfmjDORPRWWsLvk1meDnI+tap5gE4NHYYWiStOJk4 c5J6bEbdkW+hqe6ul2pKx+mC0FknVZBB2BUi7EsC13GNn4PkEX4dBZ7ToEVEnYkR OOMXGI243RdAEeBrv/bkZs6oT41BePwuY6nh9AI6bHySvPes62VDca1dYJUmcLsc a1WJ23FsBdm+fOiLikparMc5jfqjRreDWzYxbQAv5bH6kfRd/egdnU/IYbSTv4bi 5BzvJbRqeVRx+AVEKTvFKs26cs13tj7BpP47gOMSMPiE1qFRjcjMK2Kyyl2bd0yl 70trhjJPjfw7QY0TFKa2wBJFcNJ/+vQTgKYNlD/NP0E4djXRUChHpLap5ZasyI6k Ry6/qDQDCcLZSl8W0clNgmsIzvNF79AJhvrXV9eFAOEW3ACH5d2byS8qzLzQD8hm 0uFsfdjGHvQZQgODCgWT =y+py -----END PGP SIGNATURE----- --=-ITcdQqs6UyvnYCm7USV7-- From dyerbrookme@juno.com Mon Feb 23 17:43:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8A4D3A68E6 for ; Mon, 23 Feb 2009 17:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD0u3begxcKS for ; Mon, 23 Feb 2009 17:43:58 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 05DFD3A68D1 for ; Mon, 23 Feb 2009 17:43:57 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail20.vgs.untd.com [10.181.12.160]) by smtpout06.vgs.untd.com with SMTP id AABE4GWE7AJUKGD2 for (sender ); Mon, 23 Feb 2009 17:42:53 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNDwTu8p8Hm8dMK4BhfUuBeg== Received: (from dyerbrookme@juno.com) by webmail20.vgs.untd.com (jqueuemail) id N95M7HGF; Mon, 23 Feb 2009 17:41:58 PST Received: from [68.161.198.3] by webmail20.vgs.untd.com with HTTP: Tue, 24 Feb 2009 01:41:09 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Tue, 24 Feb 2009 01:41:09 GMT To: jwatte@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.204109.9421.3@webmail20.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 1:1:2986628435 X-UNTD-Peer-Info: 10.181.12.160|webmail20.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:43:58 -0000 But all virtual worlds are a "representation of inventory". For example,= the Second Life central asset server sends the information about an obj= ect stored in its data base to me on my server and I rez out the object.= It's at the level of sniffing packets, scraping parameters with hacks, = etc. etc. that you can then grab that information of a texture UUID or t= he prim facets of furniture, etc. to then make the clone. = ____________________________________________________________ Looking for insurance? Click to compare and save big. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTInoMo75HvoAAXqMdYPKU4= MgEfTEHibVTPXD80YrlmRtL1ExKtapS/ From jwatte@gmail.com Mon Feb 23 17:52:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6797E3A6895 for ; Mon, 23 Feb 2009 17:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfTRz6jlLTDx for ; Mon, 23 Feb 2009 17:52:48 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 873863A657C for ; Mon, 23 Feb 2009 17:52:48 -0800 (PST) Received: by gxk22 with SMTP id 22so6096490gxk.13 for ; Mon, 23 Feb 2009 17:53:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rtggNbkNKyaWYtQ51ICfsjkOjgpt0bfyAm9DGx3zjv4=; b=p28jbptSSQFmHlSYM6IF6hHwGA3sbpp9Kmrvs9nSjkr0JHpL0l/nFIAZCDd5HLkP2G V6FbDVKdJRQMmXJoWzNn9UtLKTFP7ih75ZlKxyvYuzQvO0U5WQv8YhOc8RZu7EKTxYbC JhvENKC6+aHT7o2j90L+uEoXlhlYAET7Jlacg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kNr03Y16AANj0R71Bsd+DOEtExAVMQfxygtaJ2gCYIdSNIIDcd5r+vpImUv1Ei/+++ KqGVC7p8835TwVPX9VPd32xK4rEStWsVepgTJK2EjRdbVNEbda5nGQTD63l6SZPy/I1V yrJYlYMcgQtZNPcNUwT7pWHLjKq+A3nZ9NO8I= Received: by 10.100.125.12 with SMTP id x12mr5232172anc.4.1235440385017; Mon, 23 Feb 2009 17:53:05 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b14sm9928820ana.36.2009.02.23.17.53.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 17:53:04 -0800 (PST) Message-ID: <49A352FD.20908@gmail.com> Date: Mon, 23 Feb 2009 17:53:01 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090223.204109.9421.3@webmail20.vgs.untd.com> In-Reply-To: <20090223.204109.9421.3@webmail20.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:52:49 -0000 dyerbrookme@juno.com wrote: > But all virtual worlds are a "representation of inventory". For example, the Second Life central asset server sends the information about an object stored in its data base to me on my server and I rez out the object. That's not actually the proposal. The proposal is that the second life content repository sends your inventory to a second life sim for "rezzing." No non-second-life server would "rez" your object. I look forward to your interpretation of the actual proposal, as it's currently being discussed. I also recommend you search this list for threads on "DRM" because there is a proposal there, too, that might interest you -- again, comments on the suitability of that proposal encouraged. Btw: nobody has told me what "rez" actually stands for, and why that word would be better to use than just "instantiate." Sincerely, jw From belxjander@gmail.com Mon Feb 23 17:53:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0183A6895 for ; Mon, 23 Feb 2009 17:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYsgdxGlg6m7 for ; Mon, 23 Feb 2009 17:53:54 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by core3.amsl.com (Postfix) with ESMTP id 849C73A657C for ; Mon, 23 Feb 2009 17:53:51 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2074792rvb.49 for ; Mon, 23 Feb 2009 17:54:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=hlhixguCBNTk9WRu41mOglURqkAGkldf1peJv4s0/iI=; b=AWtsdH5jYgJHOn3T8gyIOk/meikg+amv7yB2Zwvg1VchMQ7THySYMJ0iAbduJpcCn4 C6jtWk8cwbfkGhvu6mgRUfxJs4QahCCWVuRHJvCpEjVwUCSt5WaxTSSb2DSBlWEWloAk /vmtqx/f1zfXHh1NNIUekAX2ywdlfOW4+Wm8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=nOfhZI7dWO0VefItR0HH9Uy7PDZdRXay4ULPYSsaRUIohcI0lARwv1P2QiAco2EnHa Z+xNfTVy/3cn20PYeAauYFMT3BiXL1Bz9qPn+FqF4SMyBG120DtsYHdimLCVtMUQXBmy xgJGn6uGPBMH1/JvyDwptE2NlfIVHryuOQOAo= Received: by 10.141.205.11 with SMTP id h11mr2833277rvq.2.1235440449006; Mon, 23 Feb 2009 17:54:09 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id k2sm15080864rvb.4.2009.02.23.17.54.07 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 17:54:08 -0800 (PST) From: Kajikawa Jeremy To: "dyerbrookme@juno.com" In-Reply-To: <20090223.144052.24438.3@webmail03.vgs.untd.com> References: <20090223.144052.24438.3@webmail03.vgs.untd.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JIeTFB+XysMmqpeHjikH" Date: Tue, 24 Feb 2009 01:48:46 +0000 Message-Id: <1235440126.6608.91.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: "mmox@ietf.org" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:53:55 -0000 --=-JIeTFB+XysMmqpeHjikH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Well when it comes to the code... yes it can enable or disable functionality... But from what I see at this point... we arent talking about a single entity here, We are discussing a *layer cake* of parts where each layer of the cake makes a different flavour... There is the "OpenSIM" cake, the LindenLab cake and the Croquet cake along with other recipes as well... What I see for this is list is that we define an open mechanism for serialization of an entity object and also the permissions of access from one system to another. Once we define that using something easily implementable it will become adoptable by the existing virtual worlds and also allow commerce... since the first thing is to make a connection and then define a mechanism for commerce... What happened first? the commercial interest or the roads for it ?... I would say the commercial interest... right now a simple and elegant solution IS presenting itself... Who else is trying to keep an open mind on this list and feeling the flames? Jeremy On Mon, 2009-02-23 at 19:40 +0000, dyerbrookme@juno.com wrote: > Debating various economic systems and business models wouldn't fall into = the purview of this list if it weren't for the very pertinent fact that in= teroperability precludes or allows forms of economic systems by affirming o= r denying intellectual property rights in the code.=20 >=20 > Then the unspoken or espoused economic views of the coders matters a grea= t deal. If they all adhere to the copyleftist mode and claim that inserting= c/m/t "breaks their business model" (although I don't see that it does, as= they can check off "yes" to c/m/t), and they impose that as they only choi= ce articulated in the tools that emerge from the code, then they've foreclo= sed a Metaverse economy based on IP and micropayments. >=20 > Or, not to limit ourselves to virtual worlds because interoperability con= nects not only to VW platforms, let's take a story of how someone really ma= kes a living in the real world of real proprietary code who is not an anecd= ote, but typical of a software business: > http://tech.yahoo.com/blogs/null/124073 >=20 > Whatever the jailbreaks and rips, the i-phone is based on proprietary cod= e. It admit various apps and those apps, too, are proprietary in many cases= . This fellow gives away free games, but they are merely loss-leaders to ge= t customers to buy the closed-code game which is sold by the i-phone as clo= sed close. So the interoperability that enabled all the widgets or apps or = whatever is still based on a proprietary code concept for both the technolo= gy vendor and the user. If those who believed there should be no proprietar= y closed code prevailed on the production of the i-phone and its app econom= y for thousands of developers, there'd be no mobile app economy, now would = there. That's because the option did not get foreclosed in development. >=20 > If there's something I haven't understood about how i-phone and apps work= , enlighten me, but I think the analogy is sound. >=20 > ____________________________________________________________ > Click to compare and save on auto insurance. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTImHYq375zTIrqcaFxHEq6W= 3NklESf7wPUL6Ue0CUnNJLMI3dUHvy/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-JIeTFB+XysMmqpeHjikH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJo1H+AAoJECHrKutFYVwTJsYQAOfzC6Huy+2Y4XFFsGDzmcg5 vdKpPdjzMpeDeBOp/xsaPV7fDo09ckXY3io+nrS/nl5jkmp2Sdec/z17Msl9cOUg AWw/Zi7/BWn8x62o40PEm5ko8odkK2Tz6TfB7bH1a4g1aWX5rpJUISI3vpLOmPS3 1LaLFHxSaTcRh1zh/qLCYZ+HdHFn5wUwvYFQ6mpogG8JpXH3i5ElERylRYUq3Inn 0D90OPGH705nVHBU4jmqGrCMWgVzmN4cifxmp+56SG2Vx7Eh8QsLmpESG+YRQlst TZBuSS3Ijl8p1P1drb2LolyFUmYnxdBqjgQhnZ9cKSwzLQWci6AYPwAfR9RXGDVv GwmTQHj3JyFOHR1ZfG0wYylc9xX+WSQFvLBDlqEp3KJHdrVT5MqivyX404Vj280M xz2KxoRvVJ+Gp9mstuH73rcYUwXWwcD8Q71rSZRub8TV0Sm+/dIbo+2aJtCxHO2u /6+B/GZhwCpZyEt1xbiFLRfB5GXvDC8EeTiNaDqi2y9HXBpk6Ijw1FJea41ADRXZ z9y9s08qVb7Y1D5wZC91O+VAW+TbzhHGNwN01fdsXWGQtDxLpyQ4t937Pp6jyeS6 f4AjvK+nKEhkQ/z5axGWxk6P/D5MSRUg5lSz5NvocOKfB0mEqGbu3IN+wHolmgEU QTTTo3gGZ14k4cyBwvGl =bZmh -----END PGP SIGNATURE----- --=-JIeTFB+XysMmqpeHjikH-- From dyerbrookme@juno.com Mon Feb 23 17:56:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B911C3A68D1 for ; Mon, 23 Feb 2009 17:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iDLBuEyt5Wi for ; Mon, 23 Feb 2009 17:56:02 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 04B043A657C for ; Mon, 23 Feb 2009 17:56:01 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail20.vgs.untd.com [10.181.12.160]) by smtpout02.vgs.untd.com with SMTP id AABE4GW7XARFSMC2 for (sender ); Mon, 23 Feb 2009 17:56:05 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNQjago7ftEzVRoRXNdgOSww== Received: (from dyerbrookme@juno.com) by webmail20.vgs.untd.com (jqueuemail) id N95NXH9Y; Mon, 23 Feb 2009 17:55:05 PST Received: from [68.161.198.3] by webmail20.vgs.untd.com with HTTP: Tue, 24 Feb 2009 01:54:56 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Tue, 24 Feb 2009 01:54:56 GMT To: belxjander@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.205456.9421.5@webmail20.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 1:1:3523078302 X-UNTD-Peer-Info: 10.181.12.160|webmail20.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:56:02 -0000 Em, agnostic? But if you remove c/m/t from the stream, that's not agnost= icism, that's atheism. That means you've taken the option out completely= , and left it to some single server out there who is a subset of other g= rids. Not a solution. This demand for details is puzzling to me. What details? I already said,= my real life name is Catherine A. Fitzpatrick. I'm 52 years old. I live= in New York. I don't like cats. I'm currently reading "The Thin Blue Li= ne" by Colin Ferguson. My favourite colour is blue. = ____________________________________________________________ Surf a world without wires. Click now for great wireless Internet soluti= ons! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTE4hcnIOsZEJlo2mkapxtb= Jtnw3u5zSWIPVgxx9WtCFDGtAxLINEE/ From dyerbrookme@juno.com Mon Feb 23 17:59:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F5E28C229 for ; Mon, 23 Feb 2009 17:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBNlEdax9quY for ; Mon, 23 Feb 2009 17:59:34 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 2CFDD3A657C for ; Mon, 23 Feb 2009 17:59:34 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail20.vgs.untd.com [10.181.12.160]) by smtpout03.vgs.untd.com with SMTP id AABE4GXDPADSQ5C2 for (sender ); Mon, 23 Feb 2009 17:59:09 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNXkuwcnkJ8WXuhc9G8DX/NQ== Received: (from dyerbrookme@juno.com) by webmail20.vgs.untd.com (jqueuemail) id N95N5F68; Mon, 23 Feb 2009 17:58:20 PST Received: from [68.161.198.3] by webmail20.vgs.untd.com with HTTP: Tue, 24 Feb 2009 01:57:43 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Tue, 24 Feb 2009 01:57:43 GMT To: jwatte@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090223.205743.9421.6@webmail20.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:1:281118005 X-UNTD-Peer-Info: 10.181.12.160|webmail20.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 01:59:35 -0000 The information is the same as the object when the object itself was all= made up of information in the first place. The expression "rez" comes from the old science fiction novel Tron from = the 1980s, where there was a concept of a grid and things appearing on i= t, so evidently it comes from the word "to resolve" as in "to come into = view" I believe -- but others might know better. = I don't know why they didn't use the word "instantiate," perhaps because= it isn't an instance but a resolution. ____________________________________________________________ Improve your driving ability with a stop at traffic school. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTMLItIlvinHjvNdh8Lge0b= JScMosX4pDGChGv9Xi7zuSFSaXqs4qU/ From dcolivares@gmail.com Mon Feb 23 18:11:47 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0727428C24D for ; Mon, 23 Feb 2009 18:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCYbd0Tc3elP for ; Mon, 23 Feb 2009 18:11:46 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id B13B228C229 for ; Mon, 23 Feb 2009 18:11:45 -0800 (PST) Received: by fxm11 with SMTP id 11so2399922fxm.13 for ; Mon, 23 Feb 2009 18:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0BXCRzquIEuprViJqiANh80liEWcfJgeTQbb5wU75J0=; b=jTZ62i3VQseVxnMzkZBTltf0NvHBGdyecT+W2qC5GqTYU7iRkAWMgWJms5Hz7yDtKW 8j1AnRGx+Topgr0+YhN+NKh47cQT9MQxlqNRhVlVHKcpkTozojSUK/srGfPnJmj348lK 3ySapLv7aYoyw2ZaRiQh7cTzhR75PXs0wlnh8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QJPUT7Z6s+LPopvI4MecAAofLbZic5yI5BKhw1TIKs4IwSc8Qdn5BMvg9mm58FfjAH DUMbfPeanZGTvV4mYvhFFrmJqCfkLVl1WKpRpUDojAuEolaLO6df8VEMp1T7NH+faHJ6 zjzKdaOnIpCOnocovuv6YSn9MiTgEJhctNpsA= MIME-Version: 1.0 Received: by 10.102.247.4 with SMTP id u4mr3916498muh.128.1235441522638; Mon, 23 Feb 2009 18:12:02 -0800 (PST) In-Reply-To: <1235439425.6608.80.camel@localhost> References: <20090223.140736.24438.0@webmail03.vgs.untd.com> <1235439425.6608.80.camel@localhost> Date: Mon, 23 Feb 2009 21:12:02 -0500 Message-ID: From: Dan Olivares To: Kajikawa Jeremy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmox@ietf.org" , "dyerbrookme@juno.com" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 02:11:47 -0000 Can we avoid personal attacks here Kajikawa? Lets please make our best efforts to discuss the idea and not the person. The fact that you're talking to Prokofy Neva and the reputation of the avatar really has no bearing on the points she's making. Best Regards Dan On Mon, Feb 23, 2009 at 8:37 PM, Kajikawa Jeremy wro= te: > So *you* are this "Prokofy Neva" person Ive heard about... > > I always wondered if the reputation was deserved, ...that question is > now answered > for me at least. > > and I would expect you to put up equally the same as others on this list > when asked > for details... > > Im happy to state full details about myself on this list and invite > anyone to refute me, > but that is also taking conversations out of scope... > > My understanding of this list is to knock out a VW *agnostic* protocol > with means > to support *multiple* ideologies without exclusion and in an extensible > manner. > > do you disagree? > > Jeremy Kajikawa > AKA Belxjander Serechai > AKA Freija Yoshikawa > > On Mon, 2009-02-23 at 19:07 +0000, dyerbrookme@juno.com wrote: >> Dear Dan, >> >> "Ad hominem" ("to the man") refers to people, not software programs or p= latforms. Criticism of software concepts or people's ideas isn't an "ad hom= inem" attack; labelling perjoratively isn't even an "ad hominem" attack. Ev= en if this can somehow be construed as a "violation," there's been any numb= er of such acts already on this list, that met with your silence. Ultimatel= y *you're* the one the characterized OpenSim as "Leninist"; I tend to agree= , given the absence of protections of IP and the rigid conceptions about ho= w the Metaverse must be organized with collectivization. >> >> As for "logical fallicies," yes, there's always the risk of being kicked= off the Latin boys' school debate team for violations of these sorts of ar= cane rhetoric rules. But, commonsense can prevail nevertheless and you can = have a normal conversation urging technologists not to sneak ideological pr= escriptions into the protocols. As for bullying, your effort to invoke the = boys' school rules would be characterized as just that. >> >> It's important not to weld worldviews into the code and into the interop= erability in advance, whether Leninism, militarism, or any "ism". There sho= uld be authentic diversity and choice, and not a forced march to technocomm= unism. Virtual worlds need to be sustained by commerce, and commerce is sus= tained by property rights. Private property rights in general and specifica= lly intellectual property rights are ok; they are not wrong, they enable pe= ople to make a living, including technology vendors. Copyleftism and collec= tivism are only one ideology for the Internet, and can't be the only one. >> >> Since there are a number of "Dan Olivares" on the Internet, could you ex= plain which one you are? >> >> Prokofy Neva >> >> >> ____________________________________________________________ >> Click here to save cash and find low rates on auto loans. >> http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLaW0FYMjWhFUjLaV0gAMu= avgDTXgbYSdN85xrhA3CrEcy6vcRaoQ/ >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From dcolivares@gmail.com Mon Feb 23 18:22:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3A3228C275 for ; Mon, 23 Feb 2009 18:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6OpuNdbPgao for ; Mon, 23 Feb 2009 18:22:11 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id A38E128C274 for ; Mon, 23 Feb 2009 18:22:10 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so1636695fkf.5 for ; Mon, 23 Feb 2009 18:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=a2BBTTI4mGy6acsfYyQDtfQR1dJ1Hg1a6+K6UD5eQus=; b=OK+mXBAVNotGBMt2Op+aRwN4nrIUt2VCzO2eOu2BeSStXkmb/kpBiK22f8dBAlBEZ2 SvpAb41uijem+B/sXmjCmAtoNguArZX6aFFNHtjB9+a1BGjGcSdwI8CdHKk/F01Tef0W QSRJ22u6TorHZWqiQoTpk29ZWFKjAUs3Y6gnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=S8nSQV8MDuvIY8xUlDSgLQPXdPwRtaAx5YxY2PB+IqL0Jed7F8Fn9GQlFuCz9pZlnt PiEdAKg2Aow0awnXSDhOvpcUf0jZ++IyLkJwIdKtQgDYQHtZCedph9mNuHPmtfPxPQtw 4N8pHxNAP8nqIStvcaW5EigAr/DAIMmu+xPvQ= MIME-Version: 1.0 Received: by 10.103.24.11 with SMTP id b11mr3931923muj.76.1235442147917; Mon, 23 Feb 2009 18:22:27 -0800 (PST) In-Reply-To: <20090223.205456.9421.5@webmail20.vgs.untd.com> References: <20090223.205456.9421.5@webmail20.vgs.untd.com> Date: Mon, 23 Feb 2009 21:22:27 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: belxjander@gmail.com, mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 02:22:11 -0000 Interesting analogy here. I guess to me, the use of MAY instead of MUST, in terms of the religious analogy, is more like 'You get to choose if you're Christian, Catholic, Buddhist, atheism, or .. ' instead of 'You have to be Catholic'. However, even that isn't an entirely good analogy because with MAY, you can be Buddhist *and* Catholic at the same time. Some 'religions' may have doctrine(contracts) which limit you from participating in atheism. My 2c Dan On Mon, Feb 23, 2009 at 8:54 PM, dyerbrookme@juno.com wrote: > Em, agnostic? But if you remove c/m/t from the stream, that's not agnosti= cism, that's atheism. That means you've taken the option out completely, an= d left it to some single server out there who is a subset of other grids. N= ot a solution. > > This demand for details is puzzling to me. What details? I already said, = my real life name is Catherine A. Fitzpatrick. I'm 52 years old. I live in = New York. I don't like cats. I'm currently reading "The Thin Blue Line" by = Colin Ferguson. My favourite colour is blue. > > ____________________________________________________________ > Surf a world without wires. Click now for great wireless Internet solutio= ns! > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTE4hcnIOsZEJlo2mkapxtbJ= tnw3u5zSWIPVgxx9WtCFDGtAxLINEE/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From missannotoole@yahoo.com Mon Feb 23 18:22:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C5EC28C277 for ; Mon, 23 Feb 2009 18:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sx0vEOsq35Wg for ; Mon, 23 Feb 2009 18:22:19 -0800 (PST) Received: from web59104.mail.re1.yahoo.com (web59104.mail.re1.yahoo.com [66.196.101.15]) by core3.amsl.com (Postfix) with SMTP id 32A5828C274 for ; Mon, 23 Feb 2009 18:22:19 -0800 (PST) Received: (qmail 64327 invoked by uid 60001); 24 Feb 2009 02:22:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1235442157; bh=gJ4gUth9AEaX68VKPGE0lnRORLOSSOJ2HA6aMb0D6Kk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=YjhkhVp2R2hIM3Ydy7PPC0XxEwhKVqjEx1PcIKMiJnlTpiHIH7EH7Ch5iB6S6JFUK8jTULTZ0ebZz/WD1Wq8qNNb4xcpUkUndhK49uW1Z5rAG/k0sT+r3aHyoV9nSLCn8mThjYAnio+lkh0wNJbLoNONMM1GYt64s2eEBQc59v0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type; b=0tC/23x31avYdyEeANknFabsDl6o1IHPh0FjbWun8SLeGitWvPqK2UDxb4hwag0teqVSBFb6MUnpoSl2xZQ53utRdRaXpLbNvDk6jZhFeRwR4GbU4xrx8HI08RXpxltxUkYVZc9JhOggS4lsMxDD6Mlhd1T38cT5RVWjNxPYE/g=; Message-ID: <586791.64322.qm@web59104.mail.re1.yahoo.com> X-YMail-OSG: dNnwA6sVM1m1afO4g5gQt_eZPsWmXKKiWLInfu_bgwAP08rvrRVDSoCurxT4fAoI.31Cn.e3l9ws4ChLxgVNaMq8WsdWuvwGFMGWez.eAOf9cPOoZSI0YvJPeUJSi4GmjXhQNshkU.PsgBfrimvf8ELy72c2EeYxjCn7FNMm1fvMnp.j8ZVwk4nL2a87 Received: from [97.102.254.236] by web59104.mail.re1.yahoo.com via HTTP; Mon, 23 Feb 2009 18:22:37 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.289.1 References: <20090223.204109.9421.3@webmail20.vgs.untd.com> <49A352FD.20908@gmail.com> Date: Mon, 23 Feb 2009 18:22:37 -0800 (PST) From: Ann Otoole To: mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1645572096-1235442157=:64322" Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 02:22:20 -0000 --0-1645572096-1235442157=:64322 Content-Type: text/plain; charset=us-ascii From: Jon Watte Btw: nobody has told me what "rez" actually stands for, and why that word would be better to use than just "instantiate." We will have to tie you to a chair and force you to watch Tron till you get the idea. :) Odds are excellent that more and more Second Life customers and businesses will begin participating here using the SL jargon as more and more Second Life customers and businesses are made aware of this mailing list. This is a near certainty. Abstraction, which means hiding irrelevant details, is a central theme in Computer Science. "Rez" is an abstraction. "Rez" is one syllable word and is an acronym of sorts related to resolve as in resolve to the graphics card the appearance of an object of some sort. Instantiate is another word with more syllables that has a definition in the dictionary. Invoked is another possible object oriented jargon candidate. Jon will now "rez" a prim that has a script in it and then click the prim to cause the script to trigger it's on_touch() event. Jon will now instantiate a 3D mesh, apply a texture bake, and then invoke it's methods to... Same thing. How is this: There are millions of people that use the colloquial slang word rez to mean what your use of your formal word instantiate means. I'm confident we can tie our efforts up with arguments over acronyms and jargon if that is the purpose of the effort. Nothing stopping anyone from creating an acronym cross reference as one of several necessary appendices though. Bottom Line: Instantiate is in the dictionary. However it is possible "rez" will be in wikipedia before too long thus formalizing it as acceptable to the programmer generation. --0-1645572096-1235442157=:64322 Content-Type: text/html; charset=us-ascii
From: Jon Watte <jwatte@gmail.com> Btw: nobody has told me what "rez" actually stands for, and why that word would be better to use than just "instantiate."

We will have to tie you to a chair and force you to watch Tron till you get the idea.
:)

Odds are excellent that more and more Second Life customers and businesses will begin participating here using the SL jargon as more and more Second Life customers and businesses are made aware of this mailing list. This is a near certainty.

Abstraction, which means hiding irrelevant details, is a central theme in Computer Science.

"Rez" is an abstraction.

"Rez" is one syllable word and is an acronym of sorts related to resolve as in resolve to the graphics card the appearance of an object of some sort.
Instantiate is another word with more syllables that has a definition in the dictionary. Invoked is another possible object oriented jargon candidate.

Jon will now "rez" a prim that has a script in it and then click the prim to cause the script to trigger it's on_touch() event.
Jon will now instantiate a 3D mesh, apply a texture bake, and then invoke it's methods to...

Same thing.

How is this: There are millions of people that use the colloquial slang word rez to mean what your use of your formal word instantiate means.
I'm confident we can tie our efforts up with arguments over acronyms and jargon if that is the purpose of the effort.

Nothing stopping anyone from creating an acronym cross reference as one of several necessary appendices though.

Bottom Line: Instantiate is in the dictionary. However it is possible "rez" will be in wikipedia before too long thus formalizing it as acceptable to the programmer generation.


--0-1645572096-1235442157=:64322-- From tme@multicasttech.com Mon Feb 23 18:25:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B4E28C23A for ; Mon, 23 Feb 2009 18:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.576 X-Spam-Level: X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNDEU3A+z9hC for ; Mon, 23 Feb 2009 18:25:34 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id 44AEE28C27A for ; Mon, 23 Feb 2009 18:25:34 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14758585; Mon, 23 Feb 2009 21:23:51 -0500 Message-Id: From: Marshall Eubanks To: "dyerbrookme@juno.com" In-Reply-To: <20090223.204109.9421.3@webmail20.vgs.untd.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 23 Feb 2009 21:25:51 -0500 References: <20090223.204109.9421.3@webmail20.vgs.untd.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org, jwatte@gmail.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 02:25:35 -0000 Can people please not use "Digest" to label threads ? Regards Marshall On Feb 23, 2009, at 8:41 PM, dyerbrookme@juno.com wrote: > But all virtual worlds are a "representation of inventory". For > example, the Second Life central asset server sends the information > about an object stored in its data base to me on my server and I rez > out the object. It's at the level of sniffing packets, scraping > parameters with hacks, etc. etc. that you can then grab that > information of a texture UUID or the prim facets of furniture, etc. > to then make the clone. > > ____________________________________________________________ > Looking for insurance? Click to compare and save big. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTInoMo75HvoAAXqMdYPKU4MgEfTEHibVTPXD80YrlmRtL1ExKtapS/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From belxjander@gmail.com Mon Feb 23 18:29:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E0D28C27F for ; Mon, 23 Feb 2009 18:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.635 X-Spam-Level: X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dzm4gh52+UZ9 for ; Mon, 23 Feb 2009 18:29:52 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id AA59E28C27E for ; Mon, 23 Feb 2009 18:29:52 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so1176373wag.5 for ; Mon, 23 Feb 2009 18:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=6WztGqadDnWEil/XdCYxBgs95JgDUG45yebji7X9lk0=; b=EdwOQykeoQRVuemiKmae5XxZCp7q6bX8Bm/4SNQRYwfxJhXVwhSDZVsNMPr9CnaLCF vAq6paRsyP39ElCAgOgGBZ10y1f/dPGyZOBqdh0dM78oaIv/xCLGA2VfzRTAyMclGZ7V ykaK9YNEFqo39n/7JG6VvqqXAzRmpISgqi3BM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=Gx3wp9L/yzgNlLjOE/+UbUZtuGeEFUVao/b3aVkg4ZfucjJmfZ03Mgc7RQ5PxxvQS4 eUOAUzAcO1XuQ+T6cAOnUoiEsWpn7nNQX9ViABKpFVHhKScyYCv7s2JAACBhZGGErC5m iiA0x3GBJZcR1BpkXj5lW2y7SsVZTX96uRL7w= Received: by 10.115.110.6 with SMTP id n6mr1920306wam.227.1235442610669; Mon, 23 Feb 2009 18:30:10 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g14sm6723528rvb.0.2009.02.23.18.30.08 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 18:30:10 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <49A30FE2.1010801@gmail.com> References: <20090223.084454.24252.0@webmail09.vgs.untd.com> <53cd6c2e0902230613y6e86f16fyaa841a08db4b86d1@mail.gmail.com> <49A30FE2.1010801@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Zv0Nqg59iuJqKYy/S0Wo" Date: Tue, 24 Feb 2009 02:24:47 +0000 Message-Id: <1235442287.6608.119.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 02:29:54 -0000 --=-Zv0Nqg59iuJqKYy/S0Wo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable and this is why I am wanting any "object" (AV included!) to be a block of extensible attributes to allow provision of DRM and also ignoring DRM sections where the VW in question chooses to do so... the only "common denominator" would be a mandate to not "mangle" the object and attempt to "strip" the DRM or otherwise damage the object data... I recommend for an object to be able to grow but not pruned unless killed. This would be part of the reason why Im wanting to seperate the objects from Identity... That way someone like myself can have a "common name" but have each VW visited either be a re-usable or one-time account access... I might access "OSgrid.org" and show up as a Caveman or Star Trek engineer there and then teleport to "Guild Wars" or another MMORPG... If I want to *visit* WoW and learn about it... I may do that and be allowed a temporary account there with a single-session limitation with lack of some interaction? When making the jump to WoW or GW I would be entering a Swords&Sorcery arena... coming from SecondLife or OSgrid wearing a Star Trek uniform is definitely out... along with any transfer of content... I would *-need* to make a new AV and select to whether I am to become a member or I am only visiting... Im pursuing this based on my knowledge of existing specifications and also my perspective as an end-user on some existing MMO systems. I also dont expect to go beyond Identity being transferable to non-compatible VWs. Changing from SecondLife to OpenSIM they have a compatible architecture... and I would think I would keep only what I was wearing or carrying attached. is there *any* valid reason to go beyond this?... the *only* use cases I am understanding would entail definition of Identity and some mechanism for a chain-of-credentials that the servers can use for Identity and making sure the correct account is used for each login along with a "compatible systems" transfer of AV objects and the vehicle carrying it only when the user chooses to do this. If the User is transferring to a new VW grid or system, and has an existing account, then I would prompt the user with a request to change their AV from the originating systems AV representative to the new systems representative. This would keep the walled Garden... and the only other part of this standard would then become the connection of commerce... Do we permit the SecondLife "Linden" play-money to be valid play-money in OSgrid? do we permit an in-game currency from VW-A to be converted for currency in VW-B? We can define an optional mechanism for supporting such actions (expanding commerce and the area with which content may become served...) as that would keep the walled garden but also allow *wall-less* areas outside the gardens "to grow wild and free" as the dictates of the users permit. THAT is the model with which I am currently imagining as practical AND inside the scope of the MMOX charter (and it also provides a benefit to commercial entities) The value-add for cross-connection is not in an immediate effect... its initially a drain of resources for making it happen... but the value-add result is more users have more access, opening your doors to more foot-traffic... VW foot traffic may be mostly one-time-shoppers... but a LOT of people do return to where they get good service... and time spent making your service available does this not pay back in returns by having loyal customers? personally Im ignorant of the details and this is as simple-minded as I am... Does the above approach work for you? since you can mark an "attribute" for your content objects as being "allowed outside the garden"(GPL/CC) or "this garden only"(*-EULA/Commercial License blah...) Anyway...Im going back to constructing my own VW implimentation toward that vision and I wish everyone else luck with trying to enforce their own opinions on others... I invite you all to only consider that vision and explain to me where you see it having holes or lacking expansion? since I am deliberately leaving whole swathes of items for extensions to the spec, VW Federated Identity / VW Currency Exchange / VW Object Exchange I propose that we define towards compatible systems becoming interlinked first and work out a means of having additional non-compatible systems interconnect in later drafts... We dont need to solve everything now...we jujst need to get the snowball started down the hill and all the bullshit about DRM/commerce and the rest needs a better hearing... On Mon, 2009-02-23 at 13:06 -0800, Jon Watte wrote: > Jesrad wrote: > > I actually wrote that mandating the implementation of DRM on top of > > any permission/copyright metadata transmission mechanism would severly > > reduce the number of grid systems that comply with the protocol. > > =20 >=20 > Note that it would be totally possible for someone to come up with a DRM=20 > scheme, that mandates that content create /under that DRM scheme/ only=20 > be transferred to other trusted implementors of that scheme. That would=20 > mean that, if the content was created on a compliant system, and=20 > properly marked, it could not "escape" into non-DRM systems. I think=20 > that enabling this within the standard is important. >=20 > A world can then compete for attention, by implementing and adhering to=20 > some popular scheme. For example, if creators feel most comfortable with=20 > "Microsoft VW Content DRM" or "MacroMedia ContentSafe(tm)," they could=20 > make sure to create their content in a world certified by one of those=20 > providers, and mark the object as not transferable outside those=20 > domains. Part of the certification would then be to make sure that such=20 > marks are actually adhered to. This neatly splits the interoperability=20 > protocol into the interoperability part, which is free, open, and allows=20 > OpenSim or LeftistWorld to be as open as they want, and the=20 > DRM/enforcement part, which allows the concerned content creators to=20 > stay as locked-up as they want within RightistWorld. >=20 > Sincerely, >=20 > jw >=20 > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-Zv0Nqg59iuJqKYy/S0Wo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJo1pvAAoJECHrKutFYVwTRNEP/0IEajpf8v482Vr4ro3wcgpN hVj0eBwnc84SquKJ6VfWPd93S8XI+PHRf9bWkgmmY1lxLMe5m1/Ij5ABE+OpV7fR WB7q3usTzvlOT0ZUr5/FbM0mqqGTGLUpgpt2FeG3T0U5NlspQBUwn4vic+pHUuQ3 kAXH7Wk1mSykeBB83p5YI8PWtqTMke1k05ExFGpkm0ZOoJ5rF5llXVVfkJzwFI61 3b6tzoiMt0Rzr8QGxtJW9lnvyAuUp+63JDxvV6XTjs7LmfCwUFFhLH3JjiW+9hLM DO8Dxpv0vXgosgwS2zb6IvRQsYSPO2dKC8apYcR6w6uXxmC3a0iFtzfb8IEwAFAV PjQDzFa4dEzeIQlkvc/nSe0z7hioM1SMX22tbhwA8cJ1cYlG3ATZnKTaFtyQtS0v 0OUZ709q4Wr0hRn7q8vbOuayJ7D9cUbCs/wLASsi6tIP+8K//2Mhppm6TEO7y6Fv MAJ5xrriEoVo/JfRlHvPhgOQpM+d2fIVxlJFUnCaVJSLGLJTo+it4wyczPnAYU1J 2Y8yhMmXBgVmgKMTzOG5FmrSnz1AFt9bHWY7A8Uw7hnRKDt/P8TS6l/kQz+YXQe3 y7qwPikN1zCTkHnXubAzztEv6G1lgjBsS+FO5mxaFO/8QOk7EN0NrMHT/bYmdFCo pEimfTYRe9EKL6B90lRB =yuzd -----END PGP SIGNATURE----- --=-Zv0Nqg59iuJqKYy/S0Wo-- From jwatte@gmail.com Mon Feb 23 19:42:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8296D3A6823 for ; Mon, 23 Feb 2009 19:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bXg4zwbVqyB for ; Mon, 23 Feb 2009 19:42:08 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id BF0643A6782 for ; Mon, 23 Feb 2009 19:42:08 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2114615rvb.49 for ; Mon, 23 Feb 2009 19:42:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=7odbboyt6LhueM5YyXvgZlCVnP8z7HAPl7TeQDBf9bE=; b=IHnSyE7Wn/cW3dMzb5NLiBv3faaKObWE/h+gfkedRTdVwrUBn78z+Xb/AfEBGCFyNs 8vcG0JcXU+95myv+ZrAxpWOLjSUg8pensiVDK4m4IbPPVUn6CiXx3x9F/TtaIZhwjxmV cKwsf+RR8M4pvuQ54ze2W78VrVw3OyxNp9/Ck= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=F1Ae7mq7XHzg3CCSj+1JoemQe7LU1rbxeXYYkmGQkDX6Wq7KOgZVB8yACtPpFIW9kw x1Pa2OZF4b1/KJ4uvP5x91cOQI9P1EhxADkGL9asQtgJBciCSS9s1ep8Asvtm9HgOmYm fDkmuFImgkypcc2ik4b6dj1Vd+cx5sMQGOALY= Received: by 10.140.163.12 with SMTP id l12mr2339597rve.41.1235446947095; Mon, 23 Feb 2009 19:42:27 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b8sm15265638rvf.8.2009.02.23.19.42.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 19:42:26 -0800 (PST) Message-ID: <49A36CA1.70607@gmail.com> Date: Mon, 23 Feb 2009 19:42:25 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ann Otoole References: <20090223.204109.9421.3@webmail20.vgs.untd.com> <49A352FD.20908@gmail.com> <586791.64322.qm@web59104.mail.re1.yahoo.com> In-Reply-To: <586791.64322.qm@web59104.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 03:42:09 -0000 Ann Otoole wrote: > **Jon will now "rez" a prim that has a script in it and then click the > prim to cause the script to trigger it's on_touch() event. > Jon will now instantiate a 3D mesh, apply a texture bake, and then > invoke it's methods to... > > Same thing. Once you know the intended meaning of the word, right. To quote a recent internal discussion from OLIVE world: "When the dobrepo sobs the thob, the foreman will activate schema based on path bindings to DPM props." Yes, every word there has a specific and clear meaning to those who work with the OLIVE SDK, but I try to avoid using that kind of language in the external world. I'm not for or against specific words, but I am for clear and unequivocal communication, and if the target audience is unknown, a dictionary tends to be a good starting point. And btw: it's not a "grid," it's a "world instance" running on a "cluster" :-) Sincerely, jw From eh2th-mmox@yahoo.com Mon Feb 23 20:05:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96F1D3A6936 for ; Mon, 23 Feb 2009 20:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMw5p83lryCZ for ; Mon, 23 Feb 2009 20:05:21 -0800 (PST) Received: from web65715.mail.ac4.yahoo.com (web65715.mail.ac4.yahoo.com [76.13.9.107]) by core3.amsl.com (Postfix) with SMTP id A74923A6782 for ; Mon, 23 Feb 2009 20:05:21 -0800 (PST) Received: (qmail 21726 invoked by uid 60001); 24 Feb 2009 04:05:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=temrSSY+tVdGRuIj+LffD7oj+8lH3RYuil7ASt1UlIgBv0H9sWXBiMlxiocC+ggN1JWNYQ9nn9uGEZwib7sXbAoXx7yPChg0JBhx/AYAsKQCuWC8SCbs3TLblo/3dvWtJ7PXT6I3lReCoUTdsob0aIfp+R4SKOurUKl5vdUdtiM=; X-YMail-OSG: pVZb0UYVM1ms8pQ1vudC3_K9AOqbPHT4OvQwRE9b7yzKj2sVGNR9O6_aR7zzjMU7wayp7CMLlkVsq0daTAVPElV3wp9oQwgC8.4xkRCRSCm680T9fZ.5ysb88rIHnCPa0oi3mcG6DwNykYDXnDwfGt5skgIMSoEqnjqcJcp3aKTd2h3pioh5jot4ndg- Received: from [72.220.236.152] by web65715.mail.ac4.yahoo.com via HTTP; Mon, 23 Feb 2009 20:05:39 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 Date: Mon, 23 Feb 2009 20:05:39 -0800 (PST) From: eh2th-mmox@yahoo.com To: MMOX MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <83286.20348.qm@web65715.mail.ac4.yahoo.com> Subject: [mmox] Making the best of content display variability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 04:05:22 -0000 As a content creator, I am often experimenting with various display characteristics of the "world" or system where my content may be displayed. For example, in Second Life, I may create a scripted prim object which behaves in a manner to achieve some unique animation, or I may exploit the "alpha sorting problem", or perhaps the inverted normals of specially twisted sphere prims, and use this to create an uncommon visual effect. Such an effect would be unique to the Second Life viewer, and may even be dependant on a particular version of a simulator or viewer. If none of these dependancies are available, the desired effect may fail and the results could be much different than intended. If this content were confined to the Second Life environment, I should be able to implement some form of control over this content where I could update it and send new copies to my prior customers to maintain the desired effect as the display environment evolves, or I could script it in such a way that it self modifies as instructed by a server object. Now consider the possibility that Linden Lab opens the doors to their grid to interoperability. Suddenly there are several possible scenarios where my content could be rendered in addition to the environment for where it was designed and this could have a detrimental effect on the displayed results. I may not have access to any feedback about how my content performs in these new display environments, and if the results were objectionable, this could affect my reputation as a developer of quality content. As such I would be interested in ways I could collect statistics on the different display scenarios for my content, perhaps similar to a viewer version string passed from the user's web browser back to the server. Of course I understand such feedback mechanisms as they exist if the 2D web are not known for accuracy, but they do exist and could serve as a crude concept model. Another option along the same lines would be to allow multiple versions of content, where high detail content could be tailored to each display scenario and the controlling server could choose which asset to display to each type of viewer. Along the same lines, a high definition specially tailored version could be used in the world which has contracted with the content creator to enable display of the finest results, and a lower quality compromised version could be passed to other "grids" and foreign viewers, reducing the risk of illicit use of the premium content while allowing for a functional shared experience. I'm not certain how this fits into the discussion of the various protocols, but I suspect such an interoperating scenario would impact the designs; hence I feel these concepts to be somewhat applicable and on topic for this forum. Best regards, --Tom Hoff From belxjander@gmail.com Mon Feb 23 22:35:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C58C3A6765 for ; Mon, 23 Feb 2009 22:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CaA7dM7Yi9ee for ; Mon, 23 Feb 2009 22:35:35 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 377F43A6905 for ; Mon, 23 Feb 2009 22:35:35 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2178449rvb.49 for ; Mon, 23 Feb 2009 22:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=n+gJccr2j6g7wSsoAT+93XVKpfOwCMSgQPnBy3ERjzI=; b=qoPCQDWJ5FAyquW61R0+uLXuyZDcCWLOT679JMKDWuRcuBkBbZEKhanL7uVqVFqOhc QeG5NmxgfoUxquNxrUROCMk3OLkM6q56wa1MI95STLu1dQXf69BcnYFJ9pjjUeVEDdbs DsHn/VfTEBNS7duaSr42nri7A/x3m7fLyKH9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=CtQPpehq8t7bJ+rX+Yh6tGtMUN99CNxrs7xOMvbrz19jbV+WLpWOcjbkkYPZW9rZfB 7F/9MuAyu1xr7yIubkks/z9puA1D4KEM9mOBJcLDk+9dhhLMyoMBcWqWx46MGpo0h/Ib sPxgkR7sxox7scZ+pOA1sgAL5+kGCLEj9ws5U= Received: by 10.141.177.2 with SMTP id e2mr2425889rvp.71.1235457352805; Mon, 23 Feb 2009 22:35:52 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g22sm7157860rvb.0.2009.02.23.22.35.50 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 22:35:52 -0800 (PST) From: Kajikawa Jeremy To: eh2th-mmox@yahoo.com In-Reply-To: <83286.20348.qm@web65715.mail.ac4.yahoo.com> References: <83286.20348.qm@web65715.mail.ac4.yahoo.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-t4+0GaPNchXbZf/SumBw" Date: Tue, 24 Feb 2009 06:30:28 +0000 Message-Id: <1235457028.6608.139.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: MMOX Subject: Re: [mmox] Making the best of content display variability X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 06:35:36 -0000 --=-t4+0GaPNchXbZf/SumBw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I agree with the multiple versions option... thats why I proposed the HTML-alike serialization I have written about on this list already... to head towards something usable and extensible without become too "fixed" on what the virtual world implimentations are... allow for creativity to shine... to allow for one or more mesh/prim/ values to be present as part of any content created and implemented in an extensible manner. I don't expect the format itself to be used but the concept of arranging the data so that there is some kind of error checking and component connectivity so that a different VW render can use the correct resources inside the content object Maybe having resources for SL, maybe having resource references for WoW, maybe having resources for Solipsis or another VW...=20 as long as the object is defined or expandable to be usable within the confines set by the content creator and agreed by the end-user/customer. Jeremy On Mon, 2009-02-23 at 20:05 -0800, eh2th-mmox@yahoo.com wrote:=20 > As a content creator, I am often experimenting with various display chara= cteristics of the "world" or system where my content may be displayed. For = example, in Second Life, I may create a scripted prim object which behaves = in a manner to achieve some unique animation, or I may exploit the "alpha s= orting problem", or perhaps the inverted normals of specially twisted spher= e prims, and use this to create an uncommon visual effect. Such an effect w= ould be unique to the Second Life viewer, and may even be dependant on a pa= rticular version of a simulator or viewer. If none of these dependancies ar= e available, the desired effect may fail and the results could be much diff= erent than intended. >=20 > If this content were confined to the Second Life environment, I should be= able to implement some form of control over this content where I could upd= ate it and send new copies to my prior customers to maintain the desired ef= fect as the display environment evolves, or I could script it in such a way= that it self modifies as instructed by a server object. Now consider the p= ossibility that Linden Lab opens the doors to their grid to interoperabilit= y. Suddenly there are several possible scenarios where my content could be = rendered in addition to the environment for where it was designed and this = could have a detrimental effect on the displayed results. I may not have ac= cess to any feedback about how my content performs in these new display env= ironments, and if the results were objectionable, this could affect my repu= tation as a developer of quality content. >=20 > As such I would be interested in ways I could collect statistics on the d= ifferent display scenarios for my content, perhaps similar to a viewer vers= ion string passed from the user's web browser back to the server. Of course= I understand such feedback mechanisms as they exist if the 2D web are not = known for accuracy, but they do exist and could serve as a crude concept mo= del. >=20 > Another option along the same lines would be to allow multiple versions o= f content, where high detail content could be tailored to each display scen= ario and the controlling server could choose which asset to display to each= type of viewer. Along the same lines, a high definition specially tailored= version could be used in the world which has contracted with the content c= reator to enable display of the finest results, and a lower quality comprom= ised version could be passed to other "grids" and foreign viewers, reducing= the risk of illicit use of the premium content while allowing for a functi= onal shared experience. >=20 > I'm not certain how this fits into the discussion of the various protocol= s, but I suspect such an interoperating scenario would impact the designs; = hence I feel these concepts to be somewhat applicable and on topic for this= forum. >=20 > Best regards, > --Tom Hoff > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-t4+0GaPNchXbZf/SumBw Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJo5QEAAoJECHrKutFYVwT+3sP/RhTdTmbeIZjcrEQScLewNcs 4RcK18IM0Dido5Wg3+v3OPSLBj/NKmyEjrb7asFiKrFWjbBbRGNS3ge9uLWpi9N8 4u6MgmveGbE8RA7L+ZUNQxYdnOJAI5rYtTen5xGgA7VLrFhsBNl0kyqGSVsWGeps GW09jADZ3kkGVoa7ZTR/ucMSvRqIpp9cA7ifpga76yCNO5WUtU0U4N7oJ3s1PY7S HVFudUmoxVGXqd9B0zvwIJb38rddXHa1MiR+2+iczlw3bm+UF7xGOQcnmWXCe7EJ y+RcTc1C+m6NHuu1FpZnD2c57wCJ0fu7W6DP+5pPv1F6ACNtVu1tQBxjBFj4g6Dd wRLQlpeeen1aCjrydVdXsQOZWdNaZFS8pc8EsoyDHtZMqx/7yzLf2w38siopdRJc za+c4qHlFyAUvc9IakPXR2LAi8IcQa3ecYDnRJ00y+1qvzQBAjuimOJN+t9tz8Z0 /VPt06kv8KkP8AeZ29cvXl2vLdqtOcrwgN/qNNQkzKEi56q5TsAYKmfqdwcdK6TL 1+nzPC5erYCgVD/yIgi8dGpMk08sjv/tVBC+SGaQMCVXpzGraWB4szmJuJ7ten9W fcfhHnc/zYJkOczIdsOzbpcc7UK63/xKTr088qVcJGQ0xrQrlFt0pQW8Tyx8cDfc csFKsrFtl1YkZFFp9sXs =12uo -----END PGP SIGNATURE----- --=-t4+0GaPNchXbZf/SumBw-- From gareth@litesim.com Mon Feb 23 22:40:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAB923A6839 for ; Mon, 23 Feb 2009 22:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKz9oFEjkul9 for ; Mon, 23 Feb 2009 22:40:32 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.155]) by core3.amsl.com (Postfix) with ESMTP id F05463A657C for ; Mon, 23 Feb 2009 22:40:31 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so7489280poe.4 for ; Mon, 23 Feb 2009 22:40:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.85.13 with SMTP id n13mr2424335rvl.69.1235457649319; Mon, 23 Feb 2009 22:40:49 -0800 (PST) In-Reply-To: <27a487810902231225l6698b519rdc6f1d53ba215024@mail.gmail.com> References: <27a487810902231225l6698b519rdc6f1d53ba215024@mail.gmail.com> Date: Tue, 24 Feb 2009 06:40:49 +0000 Message-ID: <61dbdd7d0902232240v7be93f0dpd6310ecd7db0902a@mail.gmail.com> From: Gareth Nelson To: William George Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Permissions (Gareth Nelson) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 06:40:32 -0000 Essentially, you'd need to look at each sub-component and then evaluate what the restrictions are, applying the restrictions on sub-components to the collected whole (since they're part of the whole). Or you could ignore it. Ask your own sense of ethics and your lawyer what the right thing to do is. I'll restate again that this proposal was NOT aimed at a solid implementation of something which can actually be enforced, but as a very expressive means of indicating the license terms in a machine-readable form. Following discussions, it appears that the general attitude is that there is other previous work in this area so i've actually withdrawn my proposal. On Mon, Feb 23, 2009 at 8:25 PM, William George wrote: > Nice first step, but it's not clear how this would handle composite objects: > objects that have two different creators and/or permissions settings. The SL > convention of using the root prim's permission for the entire object leads > to restrictions concerning the reuse of "no mod" sub assemblies in a larger > assemblies. > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From gareth@litesim.com Mon Feb 23 23:20:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E86563A68FE for ; Mon, 23 Feb 2009 23:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEkEvEunG-dN for ; Mon, 23 Feb 2009 23:20:11 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.153]) by core3.amsl.com (Postfix) with ESMTP id 292D93A67D1 for ; Mon, 23 Feb 2009 23:20:11 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so7519241poe.4 for ; Mon, 23 Feb 2009 23:20:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.193.9 with SMTP id v9mr2441437rvp.120.1235460028711; Mon, 23 Feb 2009 23:20:28 -0800 (PST) In-Reply-To: <49A311BC.90405@gmail.com> References: <49A2500F.3000104@gmail.com> <49A311BC.90405@gmail.com> Date: Tue, 24 Feb 2009 07:20:28 +0000 Message-ID: <61dbdd7d0902232320k5451db6av27dadc81424ca7c2@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mystical Demina , mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 07:20:12 -0000 I have a nice solution to this one, take OGP and build on it :) Add the following: 1 bowl of transport mediums 1 cup of object position update messages 1 cup of geometrical definitions Mix 2 cups until a clean set of messages is defined Skim away SL limits, mix in and retain the basics (i.e web services, agent/region domains split, HTTP capabilities over https:// URLs) Bake for 50 minutes at 1337c and serve with a side portion of win On Mon, Feb 23, 2009 at 9:14 PM, Jon Watte wrote: > Morgaine wrote: >> >> I can't understand why you continue to raise the spectre that we're here >> to rubberstamp SL standards. =A0We aren't. =A0I'm not aware of anybody w= ith that >> agenda. >> > > Because there are several people on this list who say "OpenSim and Second > Life are already trying to do client interoperability; I think we should = run > with it and not worry about something bigger." > Similarly, I find that the current OGP proposal specifies some thing > ("Rezzing" of avatars) that are Second Life centric, while not specifying > other things that would be necessary for an actually useful interoperable > virtual world (like entity telemetry). > > Similarly, if OGP is specified as a mostly empty vessel that can contain > arbitrary negotiated data, what would probably happen would be that OpenS= im > puts OpenSim data in that vessel, and IMVU puts IMVU data in that vessel, > and both claim to support "OGP interoperability" but you can't do anythin= g > useful through that claim. I want to avoid that outcome. >> >> We are working in good faith towards your item 2), while noting that ite= m >> 2) means interop with "all" reasonable worlds, and that includes Linden >> worlds. =A0It's not either/or, it's both. =A0Please grant us that, so th= at we >> can actually make headway. >> >> /(Proviso: your item 2) says /*single ... simulation*/, which is >> incorrect, as we have no remit to straightjacket diverse worlds into a >> single simulation.)/ > > What I mean by "single simulation" is what the user sees when connected t= o a > specific, interoperating instance. I suppose the user could be connected = to > multiple of those, similar to opening multiple video streams in a media > player, but then those generally have "nothing" to do with each other. > > > Okay, so if most of us agree on 2), can we just say we have "rough > consensus" on that, and politely reject any attempt to steer the work > towards 1)? > > > Sincerely, > > jw > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From gareth@litesim.com Mon Feb 23 23:21:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8BF83A68FE for ; Mon, 23 Feb 2009 23:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS6qT3qNjOd4 for ; Mon, 23 Feb 2009 23:21:43 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.154]) by core3.amsl.com (Postfix) with ESMTP id A69F03A657C for ; Mon, 23 Feb 2009 23:21:43 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so7520501poe.4 for ; Mon, 23 Feb 2009 23:22:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.153.16 with SMTP id f16mr2428793rvo.272.1235460121296; Mon, 23 Feb 2009 23:22:01 -0800 (PST) In-Reply-To: References: <49A2500F.3000104@gmail.com> <49A311BC.90405@gmail.com> <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com> Date: Tue, 24 Feb 2009 07:22:01 +0000 Message-ID: <61dbdd7d0902232322q620532f2ga190a28e4f1dac6c@mail.gmail.com> From: Gareth Nelson To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jon Watte , Robert Gehorsam , Mystical Demina , mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 07:21:44 -0000 Not your place to commit them, but whose place is it to at least contact th= em? On Mon, Feb 23, 2009 at 10:10 PM, Meadhbh Hamrick (Infinity) wrote: > yes. the purpose of the upcoming MMOX BoF session is to get people from a > diverse collection of virtual worlds / MMOs in the same room at the same > time to discuss: > > a. is a working group a good idea? > b. if so, how should we constrain the problem domain? > c. if we can't agree on the same problem domain, does it make sense to ha= ve > multiple working groups? > > it is telling that the 74th IETF meeting is held during the same week and > less than a mile away from this year's game developers conference, but it= is > not my place to commit representatives from the companies you mention to > attend. > > -cheers > -meadhbh > > On Feb 23, 2009, at 1:30 PM, Robert Gehorsam wrote: > >> I think part of the issue here with regard to the debate between broad >> and narrow interoperability is that, other than Jon representing >> Forterra's technical efforts, there are no other visibly participating >> technical representatives from any other virtual world technology >> providers or other relevant groups. =A0No one from Sun, Qwaq, Multiverse= , >> HiPiHi, Activeworlds, any of the browser-based folks, Twinity, any of >> the game folks or kids worlds, Makena (the company that, contrary to >> some folks' assertions, is the company that makes and operates >> There.com), Proton Media, Icarus or its various partners, ECS, and so >> forth. =A0 I've seen references to Qwaq but haven't seen Greg or anyone >> else from there participating here. =A0 There are probably two dozen >> companies that would be reasonable candidates for this discussion, not >> to mention companies like Adobe, Google, Intel, Samsung, Sony and, yes, >> even Microsoft, all of which might arguably have some interesting >> contributions to make. >> >> It may be that this lack of broad participation is creating -- fairly or >> unfairly -- the sense that the conversation will naturally drift towards >> an SL-OS orientation -- despite what I see as the best intentions of >> many people here -- simply because, other than Forterra, no one else is >> stepping up to the plate. =A0 I can tell you that *that* is not somethin= g >> that Forterra wants to see, because it's inherent in our view of the >> evolution of the internet that interoperability between diverse virtual >> worlds is essential for all to succeed. =A0So the imbalance in this >> ongoing discussion creates a false dynamic of conflict when none is >> intended. =A0Without broad input, how can we achieve broad >> interoperability? >> >> Is there any outreach going on to these various organizations, or is >> that somehow not part of the policy? =A0Not being really familiar with t= he >> workings of these sorts of technical groups, I just don't know. >> >> Robert >> >> -----Original Message----- >> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >> Jon Watte >> Sent: Monday, February 23, 2009 4:15 PM >> To: Morgaine >> Cc: Mystical Demina; mmox@ietf.org >> Subject: Re: [mmox] Learning from the past; focusing on the future >> >> Morgaine wrote: >>> >>> I can't understand why you continue to raise the spectre that we're >>> here to rubberstamp SL standards. =A0We aren't. =A0I'm not aware of >>> anybody with that agenda. >>> >> >> Because there are several people on this list who say "OpenSim and >> Second Life are already trying to do client interoperability; I think we >> should run with it and not worry about something bigger." >> Similarly, I find that the current OGP proposal specifies some thing >> ("Rezzing" of avatars) that are Second Life centric, while not >> specifying other things that would be necessary for an actually useful >> interoperable virtual world (like entity telemetry). >> >> Similarly, if OGP is specified as a mostly empty vessel that can contain >> arbitrary negotiated data, what would probably happen would be that >> OpenSim puts OpenSim data in that vessel, and IMVU puts IMVU data in >> that vessel, and both claim to support "OGP interoperability" but you >> can't do anything useful through that claim. I want to avoid that >> outcome. >>> >>> We are working in good faith towards your item 2), while noting that >>> item 2) means interop with "all" reasonable worlds, and that includes >>> Linden worlds. =A0It's not either/or, it's both. =A0Please grant us tha= t, >>> so that we can actually make headway. >>> >>> /(Proviso: your item 2) says /*single ... simulation*/, which is >>> incorrect, as we have no remit to straightjacket diverse worlds into a >> >>> single simulation.)/ >> >> What I mean by "single simulation" is what the user sees when connected >> to a specific, interoperating instance. I suppose the user could be >> connected to multiple of those, similar to opening multiple video >> streams in a media player, but then those generally have "nothing" to do >> with each other. >> >> >> Okay, so if most of us agree on 2), can we just say we have "rough >> consensus" on that, and politely reject any attempt to steer the work >> towards 1)? >> >> >> Sincerely, >> >> jw >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From RGehorsam@forterrainc.com Mon Feb 23 23:23:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B0A93A6946 for ; Mon, 23 Feb 2009 23:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3gtp+xzMpRy for ; Mon, 23 Feb 2009 23:23:16 -0800 (PST) Received: from smtp.forterrainc.com (smtp.forterrainc.com [208.64.184.34]) by core3.amsl.com (Postfix) with ESMTP id 123CB3A657C for ; Mon, 23 Feb 2009 23:23:16 -0800 (PST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Feb 2009 23:23:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9A27EF31A4DF2C4C8BB45D661B13BA870535092E@MERCURY.forterrainc.com> In-Reply-To: <61dbdd7d0902232322q620532f2ga190a28e4f1dac6c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mmox] Learning from the past; focusing on the future thread-index: AcmWULi3csGcg7DTQCK2wlrnFzeVsAAAAX+g References: <49A2500F.3000104@gmail.com> <49A311BC.90405@gmail.com> <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com> <61dbdd7d0902232322q620532f2ga190a28e4f1dac6c@mail.gmail.com> From: "Robert Gehorsam" To: "Gareth Nelson" , "Meadhbh Hamrick (Infinity)" Cc: Jon Watte , Mystical Demina , mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 07:23:17 -0000 Anyone who wants to, I think. There are places like Virtual World News = weekly where something could be posted too.=20 -----Original Message----- From: Gareth Nelson [mailto:gareth@litesim.com]=20 Sent: Tuesday, February 24, 2009 2:22 AM To: Meadhbh Hamrick (Infinity) Cc: Robert Gehorsam; mmox@ietf.org; Mystical Demina; Jon Watte Subject: Re: [mmox] Learning from the past; focusing on the future Not your place to commit them, but whose place is it to at least contact = them? On Mon, Feb 23, 2009 at 10:10 PM, Meadhbh Hamrick (Infinity) = wrote: > yes. the purpose of the upcoming MMOX BoF session is to get people=20 > from a diverse collection of virtual worlds / MMOs in the same room at = > the same time to discuss: > > a. is a working group a good idea? > b. if so, how should we constrain the problem domain? > c. if we can't agree on the same problem domain, does it make sense to = > have multiple working groups? > > it is telling that the 74th IETF meeting is held during the same week=20 > and less than a mile away from this year's game developers conference, = > but it is not my place to commit representatives from the companies=20 > you mention to attend. > > -cheers > -meadhbh > > On Feb 23, 2009, at 1:30 PM, Robert Gehorsam wrote: > >> I think part of the issue here with regard to the debate between=20 >> broad and narrow interoperability is that, other than Jon=20 >> representing Forterra's technical efforts, there are no other visibly = >> participating technical representatives from any other virtual world=20 >> technology providers or other relevant groups. =A0No one from Sun,=20 >> Qwaq, Multiverse, HiPiHi, Activeworlds, any of the browser-based=20 >> folks, Twinity, any of the game folks or kids worlds, Makena (the=20 >> company that, contrary to some folks' assertions, is the company that = >> makes and operates There.com), Proton Media, Icarus or its various=20 >> partners, ECS, and so forth. =A0 I've seen references to Qwaq but=20 >> haven't seen Greg or anyone else from there participating here. =A0=20 >> There are probably two dozen companies that would be reasonable=20 >> candidates for this discussion, not to mention companies like Adobe,=20 >> Google, Intel, Samsung, Sony and, yes, even Microsoft, all of which=20 >> might arguably have some interesting contributions to make. >> >> It may be that this lack of broad participation is creating -- fairly = >> or unfairly -- the sense that the conversation will naturally drift=20 >> towards an SL-OS orientation -- despite what I see as the best=20 >> intentions of many people here -- simply because, other than=20 >> Forterra, no one else is stepping up to the plate. =A0 I can tell you = >> that *that* is not something that Forterra wants to see, because it's = >> inherent in our view of the evolution of the internet that=20 >> interoperability between diverse virtual worlds is essential for all=20 >> to succeed. =A0So the imbalance in this ongoing discussion creates a=20 >> false dynamic of conflict when none is intended. =A0Without broad=20 >> input, how can we achieve broad interoperability? >> >> Is there any outreach going on to these various organizations, or is=20 >> that somehow not part of the policy? =A0Not being really familiar = with=20 >> the workings of these sorts of technical groups, I just don't know. >> >> Robert >> >> -----Original Message----- >> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf=20 >> Of Jon Watte >> Sent: Monday, February 23, 2009 4:15 PM >> To: Morgaine >> Cc: Mystical Demina; mmox@ietf.org >> Subject: Re: [mmox] Learning from the past; focusing on the future >> >> Morgaine wrote: >>> >>> I can't understand why you continue to raise the spectre that we're=20 >>> here to rubberstamp SL standards. =A0We aren't. =A0I'm not aware of=20 >>> anybody with that agenda. >>> >> >> Because there are several people on this list who say "OpenSim and=20 >> Second Life are already trying to do client interoperability; I think = >> we should run with it and not worry about something bigger." >> Similarly, I find that the current OGP proposal specifies some thing=20 >> ("Rezzing" of avatars) that are Second Life centric, while not=20 >> specifying other things that would be necessary for an actually=20 >> useful interoperable virtual world (like entity telemetry). >> >> Similarly, if OGP is specified as a mostly empty vessel that can=20 >> contain arbitrary negotiated data, what would probably happen would=20 >> be that OpenSim puts OpenSim data in that vessel, and IMVU puts IMVU=20 >> data in that vessel, and both claim to support "OGP interoperability" = >> but you can't do anything useful through that claim. I want to avoid=20 >> that outcome. >>> >>> We are working in good faith towards your item 2), while noting that = >>> item 2) means interop with "all" reasonable worlds, and that=20 >>> includes Linden worlds. =A0It's not either/or, it's both. =A0Please=20 >>> grant us that, so that we can actually make headway. >>> >>> /(Proviso: your item 2) says /*single ... simulation*/, which is=20 >>> incorrect, as we have no remit to straightjacket diverse worlds into = >>> a >> >>> single simulation.)/ >> >> What I mean by "single simulation" is what the user sees when=20 >> connected to a specific, interoperating instance. I suppose the user=20 >> could be connected to multiple of those, similar to opening multiple=20 >> video streams in a media player, but then those generally have=20 >> "nothing" to do with each other. >> >> >> Okay, so if most of us agree on 2), can we just say we have "rough=20 >> consensus" on that, and politely reject any attempt to steer the work = >> towards 1)? >> >> >> Sincerely, >> >> jw >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From lenglish5@cox.net Mon Feb 23 23:24:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6DC3A6946 for ; Mon, 23 Feb 2009 23:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.833 X-Spam-Level: X-Spam-Status: No, score=0.833 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML1ded49MWY2 for ; Mon, 23 Feb 2009 23:24:03 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 7EDF63A657C for ; Mon, 23 Feb 2009 23:24:03 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090224072422.NZCD10385.fed1rmmtao107.cox.net@fed1rmimpo03.cox.net>; Tue, 24 Feb 2009 02:24:22 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id KjQM1b00G4N6T0Q04jQN3x; Tue, 24 Feb 2009 02:24:22 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=4hUtcV6OAAAA:8 a=WZQOXCl-AE9kOVLghyEA:9 a=OLxjPuCfdPjPpL6Va1UA:7 a=9OwthI5iXRGhjhYW6dC2Zd3Z31QA:4 a=9XSpoOj3B7kA:10 a=F820kooBClukPIvk:21 a=SOhsPgJz7TJFiU2J:21 X-CM-Score: 0.00 Message-ID: <49A3A0A5.2010406@cox.net> Date: Tue, 24 Feb 2009 00:24:21 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] Weekly Groupies meeting X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 07:24:04 -0000 As usual, we (AWG) are meeting at Zha's island (ThornBridgeTown) at 9:30 AM SLT (pacific coast time) for an hour or so to have a general "face to face" about relevant issues. Our discussion-topics range all over the place, but lately we've been keeping focused on MMOX-related issues. We would certainly like to have everyone in MMOX attend our meeting and I think we should have a short-term goal to make our upcoming MMOX in-world/real-world media streaming a regular thing so that people aren't required to attend a single world in order to have a "face to face." E.G., we need to set up regular virtual reality video conferencing with shared-world chat of some kind (and voice if/when we can swing it). Our long term goal should be to figure out how to teleport (or mimic the effects of TP) between participating worlds ***at least*** as well as the minimal OGP TP we've demoed between SL and OPenSim so that we could move from one world to the next to directly discuss world capabilities. That basically means: show up in one virtual world, click a "TP" button and show up in the next, whatever that means to the respective client/server architectures, while at least preserving identity (avatar name and host server) between worlds and able to interact with objects and avatars in the destination world and handle local chat. In the meantime, hope to see you tomorrow morning at the Groupies meeting. IM Zha Ewry, Tree Kyomoon or Saijanai Kuhn in Second Life to get the group membership authorizing you to come to the island at coordinates: http://slurl.com/secondlife/ThorneBridgeTown/156/130/23 Laters, Lawson English Saijanai Kuhn (ISL) From gareth@litesim.com Mon Feb 23 23:24:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D2A3A6969 for ; Mon, 23 Feb 2009 23:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Hhbz4UEnBLc for ; Mon, 23 Feb 2009 23:24:57 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.153]) by core3.amsl.com (Postfix) with ESMTP id 9F5E43A6946 for ; Mon, 23 Feb 2009 23:24:57 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so7522620poe.4 for ; Mon, 23 Feb 2009 23:25:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.105.18 with SMTP id h18mr2444138rvm.109.1235460315287; Mon, 23 Feb 2009 23:25:15 -0800 (PST) In-Reply-To: <9A27EF31A4DF2C4C8BB45D661B13BA870535092E@MERCURY.forterrainc.com> References: <49A2500F.3000104@gmail.com> <49A311BC.90405@gmail.com> <9A27EF31A4DF2C4C8BB45D661B13BA870535083A@MERCURY.forterrainc.com> <61dbdd7d0902232322q620532f2ga190a28e4f1dac6c@mail.gmail.com> <9A27EF31A4DF2C4C8BB45D661B13BA870535092E@MERCURY.forterrainc.com> Date: Tue, 24 Feb 2009 07:25:15 +0000 Message-ID: <61dbdd7d0902232325v85f628ag8bf1dadb148997d0@mail.gmail.com> From: Gareth Nelson To: Robert Gehorsam Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jon Watte , Mystical Demina , mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 07:24:58 -0000 Do we have a chronic case of the bystander problem? :) I think such approaches may be best coming from a "big name", *cough* LL and IBM *cough* On Tue, Feb 24, 2009 at 7:23 AM, Robert Gehorsam wrote: > Anyone who wants to, I think. =A0There are places like Virtual World News= weekly where something could be posted too. > > -----Original Message----- > From: Gareth Nelson [mailto:gareth@litesim.com] > Sent: Tuesday, February 24, 2009 2:22 AM > To: Meadhbh Hamrick (Infinity) > Cc: Robert Gehorsam; mmox@ietf.org; Mystical Demina; Jon Watte > Subject: Re: [mmox] Learning from the past; focusing on the future > > Not your place to commit them, but whose place is it to at least contact = them? > > On Mon, Feb 23, 2009 at 10:10 PM, Meadhbh Hamrick (Infinity) wrote: >> yes. the purpose of the upcoming MMOX BoF session is to get people >> from a diverse collection of virtual worlds / MMOs in the same room at >> the same time to discuss: >> >> a. is a working group a good idea? >> b. if so, how should we constrain the problem domain? >> c. if we can't agree on the same problem domain, does it make sense to >> have multiple working groups? >> >> it is telling that the 74th IETF meeting is held during the same week >> and less than a mile away from this year's game developers conference, >> but it is not my place to commit representatives from the companies >> you mention to attend. >> >> -cheers >> -meadhbh >> >> On Feb 23, 2009, at 1:30 PM, Robert Gehorsam wrote: >> >>> I think part of the issue here with regard to the debate between >>> broad and narrow interoperability is that, other than Jon >>> representing Forterra's technical efforts, there are no other visibly >>> participating technical representatives from any other virtual world >>> technology providers or other relevant groups. =A0No one from Sun, >>> Qwaq, Multiverse, HiPiHi, Activeworlds, any of the browser-based >>> folks, Twinity, any of the game folks or kids worlds, Makena (the >>> company that, contrary to some folks' assertions, is the company that >>> makes and operates There.com), Proton Media, Icarus or its various >>> partners, ECS, and so forth. =A0 I've seen references to Qwaq but >>> haven't seen Greg or anyone else from there participating here. >>> There are probably two dozen companies that would be reasonable >>> candidates for this discussion, not to mention companies like Adobe, >>> Google, Intel, Samsung, Sony and, yes, even Microsoft, all of which >>> might arguably have some interesting contributions to make. >>> >>> It may be that this lack of broad participation is creating -- fairly >>> or unfairly -- the sense that the conversation will naturally drift >>> towards an SL-OS orientation -- despite what I see as the best >>> intentions of many people here -- simply because, other than >>> Forterra, no one else is stepping up to the plate. =A0 I can tell you >>> that *that* is not something that Forterra wants to see, because it's >>> inherent in our view of the evolution of the internet that >>> interoperability between diverse virtual worlds is essential for all >>> to succeed. =A0So the imbalance in this ongoing discussion creates a >>> false dynamic of conflict when none is intended. =A0Without broad >>> input, how can we achieve broad interoperability? >>> >>> Is there any outreach going on to these various organizations, or is >>> that somehow not part of the policy? =A0Not being really familiar with >>> the workings of these sorts of technical groups, I just don't know. >>> >>> Robert >>> >>> -----Original Message----- >>> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf >>> Of Jon Watte >>> Sent: Monday, February 23, 2009 4:15 PM >>> To: Morgaine >>> Cc: Mystical Demina; mmox@ietf.org >>> Subject: Re: [mmox] Learning from the past; focusing on the future >>> >>> Morgaine wrote: >>>> >>>> I can't understand why you continue to raise the spectre that we're >>>> here to rubberstamp SL standards. =A0We aren't. =A0I'm not aware of >>>> anybody with that agenda. >>>> >>> >>> Because there are several people on this list who say "OpenSim and >>> Second Life are already trying to do client interoperability; I think >>> we should run with it and not worry about something bigger." >>> Similarly, I find that the current OGP proposal specifies some thing >>> ("Rezzing" of avatars) that are Second Life centric, while not >>> specifying other things that would be necessary for an actually >>> useful interoperable virtual world (like entity telemetry). >>> >>> Similarly, if OGP is specified as a mostly empty vessel that can >>> contain arbitrary negotiated data, what would probably happen would >>> be that OpenSim puts OpenSim data in that vessel, and IMVU puts IMVU >>> data in that vessel, and both claim to support "OGP interoperability" >>> but you can't do anything useful through that claim. I want to avoid >>> that outcome. >>>> >>>> We are working in good faith towards your item 2), while noting that >>>> item 2) means interop with "all" reasonable worlds, and that >>>> includes Linden worlds. =A0It's not either/or, it's both. =A0Please >>>> grant us that, so that we can actually make headway. >>>> >>>> /(Proviso: your item 2) says /*single ... simulation*/, which is >>>> incorrect, as we have no remit to straightjacket diverse worlds into >>>> a >>> >>>> single simulation.)/ >>> >>> What I mean by "single simulation" is what the user sees when >>> connected to a specific, interoperating instance. I suppose the user >>> could be connected to multiple of those, similar to opening multiple >>> video streams in a media player, but then those generally have >>> "nothing" to do with each other. >>> >>> >>> Okay, so if most of us agree on 2), can we just say we have "rough >>> consensus" on that, and politely reject any attempt to steer the work >>> towards 1)? >>> >>> >>> Sincerely, >>> >>> jw >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > From jwatte@gmail.com Mon Feb 23 23:48:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C58A03A69FC for ; Mon, 23 Feb 2009 23:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEw3B6aM5A1L for ; Mon, 23 Feb 2009 23:48:50 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id E8D913A67D1 for ; Mon, 23 Feb 2009 23:48:49 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2203706rvb.49 for ; Mon, 23 Feb 2009 23:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Optl/lgLaMJclNcx5RbIwbEUSoNpVjb2G0gr6MqT6bg=; b=SiC08Tt4mmCIcK3IuCAUeddv4BBs/k2xbNOFkWd/yjk/hz7/qCOL5s6r3gfDQRAdOq FMSz2knjfjbDhDBd5EX9NN9K4ANwVdvW3QkxzNhtgfkE6JEo6n78p58BD0wGqRcBUBRR iNrOUCSqjqg4r4u+laLE1iaG/BPJ+eZ3pTdtw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FoRJ4eEkNDWnEwTfF88pM+pm8Owa6d14cUMzGP9T5dikLedbq9nuWnRpfTwc+r5+yJ hkTEsqa3F++YRSs7jq+bLHRePzqDkWLfcDLcHcIHQ2WNQo9EJUWVSVarP6KtTAOI+Y4G lzZfSyROVwDhxjz9azdwvuVDieCzxDmXR2CLE= Received: by 10.140.125.19 with SMTP id x19mr2452107rvc.187.1235461747288; Mon, 23 Feb 2009 23:49:07 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b39sm7230343rvf.9.2009.02.23.23.49.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 23:49:05 -0800 (PST) Message-ID: <49A3A66F.2000004@gmail.com> Date: Mon, 23 Feb 2009 23:49:03 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <27a487810902231225l6698b519rdc6f1d53ba215024@mail.gmail.com> <61dbdd7d0902232240v7be93f0dpd6310ecd7db0902a@mail.gmail.com> In-Reply-To: <61dbdd7d0902232240v7be93f0dpd6310ecd7db0902a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, William George Subject: Re: [mmox] Permissions (Gareth Nelson) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 07:48:50 -0000 Gareth Nelson wrote: > Or you could ignore it. Ask your own sense of ethics and your lawyer > what the right thing to do is. > I believe that we can, and should, enable the metadata that allows service providers to provide strong DRM. This means that the acceptable DRM scheme/schemes must be identified in the metadata, and a provider can then choose not to provide a resource to some peer that has not signed on to that DRM scheme. The actual mechanics of how the service verifies that the peer is signed on to that same scheme does not need to be treated by the standard; that's up to each DRM provider to figure out. If we do that, then the DRM worlds and the open worlds will be able to compete for the favor of the content creators and the users. Creators who don't like the open practices of some open provider, will simply gravitate towards the protected practices provided by the protected providers, and vice versa. Meanwhile, I think that the set of bits we've identified (view/copy/use/transfer/modify/derive) and the semantics for each bit (allow-change, deny, allow-once and allow-always) could and should be part of a required minimum schema -- i e, the service providers will publish what they attempt to enforce, and incompatible semantics means that no transfer of assets happen. That's just common sense. Note that this doesn't require the open grids to do or understand about DRM, or even to protect anything, for the benefit of their users. Meanwhile, it allows those who want to operate protected-but-interoperable grids to do so, for the benefit of their creators. Everybody wins. Sincerely, jw From jwatte@gmail.com Mon Feb 23 23:50:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8937F3A6A3A for ; Mon, 23 Feb 2009 23:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkHI0WkBOe0J for ; Mon, 23 Feb 2009 23:50:16 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id B95AC3A67D1 for ; Mon, 23 Feb 2009 23:50:16 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2904160wfd.31 for ; Mon, 23 Feb 2009 23:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=azHPCZNlb5zy76xsoKAgbMsqpyt6Ut66Gicit+Zr5r0=; b=JEw1xRCqvl662yDVsCthqccKg1ZiNRWpv09epVcD05LH9Ul0DUQ7cuSntllW86dW9m /f7i7iDvxKxJVtkNFI3SvXoZ9sPO6zibPpIe4a5wW8KfclQYvfSUKej9VDQckQQTZ9Rl 2z198CF93jGYv8Y06Mzhi/9vyKP85z6R7e2B0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=mHODrONEjjd454Ng3VPx2Xh1b06zegYvR/JM+SWR7x0gUhW6qeE4sWh8/PItt4aYCI mDQWeBFA8jnWc+6HtB3Woi3A4HP3Glc52pQCYLPr84fmhv/bJ4muEeC6Tkj3tLsLpuAz d0o+lwxcz1sIxPwoP+A7tj9SdtYtClFJGlWI8= Received: by 10.142.134.17 with SMTP id h17mr1481632wfd.306.1235461835112; Mon, 23 Feb 2009 23:50:35 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id g14sm3485631rvb.0.2009.02.23.23.50.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 23:50:32 -0800 (PST) Message-ID: <49A3A6C7.8020309@gmail.com> Date: Mon, 23 Feb 2009 23:50:31 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <49A2500F.3000104@gmail.com> <49A311BC.90405@gmail.com> <61dbdd7d0902232320k5451db6av27dadc81424ca7c2@mail.gmail.com> In-Reply-To: <61dbdd7d0902232320k5451db6av27dadc81424ca7c2@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mystical Demina , mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 07:50:17 -0000 Gareth Nelson wrote: > I have a nice solution to this one, take OGP and build on it :) > Once you change what the currently published specification of OGP is to what an interoperable exchange standard is, there won't be much left of the currently published proposal (version 4, is it?) That's a little bit like saying "why don't we take COBOL, and remove everything we don't like, and add everything we know we'll need, and perhaps we'll end up with Java"? Sincerely, jw From gareth@litesim.com Mon Feb 23 23:59:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9103A3A69E9 for ; Mon, 23 Feb 2009 23:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5a1MMseJyHKf for ; Mon, 23 Feb 2009 23:59:30 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.154]) by core3.amsl.com (Postfix) with ESMTP id CD2D53A67D1 for ; Mon, 23 Feb 2009 23:59:27 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so7552709poe.4 for ; Mon, 23 Feb 2009 23:59:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.62.9 with SMTP id p9mr2460670rvk.80.1235462385372; Mon, 23 Feb 2009 23:59:45 -0800 (PST) In-Reply-To: <49A3A66F.2000004@gmail.com> References: <27a487810902231225l6698b519rdc6f1d53ba215024@mail.gmail.com> <61dbdd7d0902232240v7be93f0dpd6310ecd7db0902a@mail.gmail.com> <49A3A66F.2000004@gmail.com> Date: Tue, 24 Feb 2009 07:59:45 +0000 Message-ID: <61dbdd7d0902232359u13ae8a0bqfee5e64ff8366699@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, William George Subject: Re: [mmox] Permissions (Gareth Nelson) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 07:59:31 -0000 "Strong DRM" of the kind that involves silly schemes such as sending the content in an encrypted form AND the encryption key should not be part of any standard. "Machine-readable licenses" are a reasonable thing, and this can all be lumped into a field in the metadata. On Tue, Feb 24, 2009 at 7:49 AM, Jon Watte wrote: > Gareth Nelson wrote: >> >> Or you could ignore it. Ask your own sense of ethics and your lawyer >> what the right thing to do is. >> > > I believe that we can, and should, enable the metadata that allows service > providers to provide strong DRM. This means that the acceptable DRM > scheme/schemes must be identified in the metadata, and a provider can then > choose not to provide a resource to some peer that has not signed on to that > DRM scheme. The actual mechanics of how the service verifies that the peer > is signed on to that same scheme does not need to be treated by the > standard; that's up to each DRM provider to figure out. > > If we do that, then the DRM worlds and the open worlds will be able to > compete for the favor of the content creators and the users. Creators who > don't like the open practices of some open provider, will simply gravitate > towards the protected practices provided by the protected providers, and > vice versa. > > Meanwhile, I think that the set of bits we've identified > (view/copy/use/transfer/modify/derive) and the semantics for each bit > (allow-change, deny, allow-once and allow-always) could and should be part > of a required minimum schema -- i e, the service providers will publish what > they attempt to enforce, and incompatible semantics means that no transfer > of assets happen. That's just common sense. > > Note that this doesn't require the open grids to do or understand about DRM, > or even to protect anything, for the benefit of their users. Meanwhile, it > allows those who want to operate protected-but-interoperable grids to do so, > for the benefit of their creators. Everybody wins. > > Sincerely, > > jw > > From gareth@litesim.com Tue Feb 24 00:00:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C693D3A6A21 for ; Tue, 24 Feb 2009 00:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.865 X-Spam-Level: X-Spam-Status: No, score=-1.865 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Pjop32cI4B5 for ; Tue, 24 Feb 2009 00:00:57 -0800 (PST) Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.158]) by core3.amsl.com (Postfix) with ESMTP id 2BE333A67D1 for ; Tue, 24 Feb 2009 00:00:57 -0800 (PST) Received: by po-out-1718.google.com with SMTP id b23so7553903poe.4 for ; Tue, 24 Feb 2009 00:01:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.162.5 with SMTP id p5mr2457499rvo.193.1235462475480; Tue, 24 Feb 2009 00:01:15 -0800 (PST) In-Reply-To: <49A3A6C7.8020309@gmail.com> References: <49A2500F.3000104@gmail.com> <49A311BC.90405@gmail.com> <61dbdd7d0902232320k5451db6av27dadc81424ca7c2@mail.gmail.com> <49A3A6C7.8020309@gmail.com> Date: Tue, 24 Feb 2009 08:01:15 +0000 Message-ID: <61dbdd7d0902240001y26e80d3g450fa29fa6df8572@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mystical Demina , mmox@ietf.org Subject: Re: [mmox] Learning from the past; focusing on the future X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 08:00:57 -0000 Ok, I should say "take some concepts from OGP", but basic idea remains the same On Tue, Feb 24, 2009 at 7:50 AM, Jon Watte wrote: > Gareth Nelson wrote: >> >> I have a nice solution to this one, take OGP and build on it :) >> > > Once you change what the currently published specification of OGP is to what > an interoperable exchange standard is, there won't be much left of the > currently published proposal (version 4, is it?) > That's a little bit like saying "why don't we take COBOL, and remove > everything we don't like, and add everything we know we'll need, and perhaps > we'll end up with Java"? > > Sincerely, > > jw > > From infinity@lindenlab.com Tue Feb 24 01:13:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165463A6A8A for ; Tue, 24 Feb 2009 01:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qygCi7oS8ggF for ; Tue, 24 Feb 2009 01:13:21 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 56DD33A67FD for ; Tue, 24 Feb 2009 01:13:18 -0800 (PST) Received: from [192.168.1.10] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 72BAF3DBC099; Tue, 24 Feb 2009 01:13:36 -0800 (PST) Message-Id: <56A0F753-5C79-42D8-8063-913A0C70121C@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: "dyerbrookme@juno.com" In-Reply-To: <20090223.205743.9421.6@webmail20.vgs.untd.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 01:13:34 -0800 References: <20090223.205743.9421.6@webmail20.vgs.untd.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org, jwatte@gmail.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 09:13:23 -0000 i think jon might have been asking what does "rez" mean in the context of this discussion. it is the term we (second life and open sim) use to describe the process of placing a task into a region. unlike Entropia Universe and other prototype-based systems, second life and open sim "place" the item itself into a region. unlike nanocosm and other similar virtual worlds, copy restrictions are enforced not my instantiation limits but by moving an object from one's inventory to the simulator. the "rezzing" process is the bit of protocol that makes sure the simulator has properly instantiated the object in the simulator and potentially removes it from another (another sim or an inventory description.) -cheers -m On Feb 23, 2009, at 5:57 PM, dyerbrookme@juno.com wrote: > The information is the same as the object when the object itself was > all made up of information in the first place. > > The expression "rez" comes from the old science fiction novel Tron > from the 1980s, where there was a concept of a grid and things > appearing on it, so evidently it comes from the word "to resolve" as > in "to come into view" I believe -- but others might know better. > > I don't know why they didn't use the word "instantiate," perhaps > because it isn't an instance but a resolution. > > ____________________________________________________________ > Improve your driving ability with a stop at traffic school. Click now! > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTMLItIlvinHjvNdh8Lge0bJScMosX4pDGChGv9Xi7zuSFSaXqs4qU/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From cathypfeffer@gmail.com Tue Feb 24 05:02:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E86E3A6837 for ; Tue, 24 Feb 2009 05:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpa11avKyqFU for ; Tue, 24 Feb 2009 05:02:14 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by core3.amsl.com (Postfix) with ESMTP id 09BBE3A69B8 for ; Tue, 24 Feb 2009 05:02:13 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id j40so243592ugd.15 for ; Tue, 24 Feb 2009 05:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=bSlzWUF+JR3jlW42g6BjcwJuf/gJQRC4y6tTBxjApco=; b=HJMcc/mozsePQZR217s1njx/m9ZxFMeY3vbaX2AzPAY2J5wuO2HJmKB4pZ/0pV4HMO juaneOh9IJKF9bUtC+0WTxa5+lPl4Q3qCojR0i2+Jvc5yYzGi5Pk/oqUIbsX2VveB4rI vmEAwlsRwF2dKXX3atdw+WOwRPtU+mOsP0YV8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=umXQ73iZDUM2+pEUAClB40dfcM0ZRVV8gVCZUV385sxdjzfrIgWOqo8/XJhsFvA+is 4dpoRvPNlWMBT5VA+cxU8r62ZyX+t2WOntBu4rPYKZr6cSeDew6KT+h+24jcn9BynpgP 0l+Am/9etQK9pEjepHoxLVOg6ZI7OpclfPT/8= MIME-Version: 1.0 Received: by 10.210.19.7 with SMTP id 7mr4391005ebs.15.1235480551215; Tue, 24 Feb 2009 05:02:31 -0800 (PST) Date: Tue, 24 Feb 2009 14:02:31 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c34a261d5680463a9bbf9 Subject: [mmox] Saying correct things does not exempt from saying them in a correct way X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 13:02:15 -0000 --0015174c34a261d5680463a9bbf9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Prokofy Neva wrote; > There should be authentic diversity and choice, and not a forced march to technocommunism. > Copyleftism and collectivism are only one ideology for the Internet, and can't be the only one. I deeply dislike the false association between copyleft and communism. What a bad troll. > Virtual worlds need to be sustained by commerce, and commerce is sustained by property rights. Well, gaming virtual worlds (for example) are not sustained by commerce and they still make a living. In the reverse direction, Open Source too is sustained by intellectual property. See how much we care about licences. For the rest, I agree with what you say. There is more than one world view, and we should not let business models get into a standard. Proprietary, Open Source, Creative Commons, Shareware, Freeware, there's room for everyone and these approaches can coexist in parallel. Could we just avoid starting useless polemics? -- Cathy --0015174c34a261d5680463a9bbf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Prokofy Neva wrote;
> There should be authentic diversity and choice,= and not a forced march to technocommunism.
> Copyleftism and collect= ivism are only one ideology for the Internet, and can't be the only one= .

I deeply dislike the false association between copyleft and communism. = What a bad troll.

> Virtual worlds need to be sustained by commerce, and commerce is s= ustained by property rights.

Well, gaming virtual worlds (for exampl= e) are not sustained by commerce and they still make a living.

In the reverse direction, Open Source too is sustained by intellectual prop= erty. See how much we care about licences.

For the rest, I agree wit= h what you say. There is more than one world view, and we should not let bu= siness models get into a standard. Proprietary, Open Source, Creative Commo= ns, Shareware, Freeware, there's room for everyone and these approaches= can coexist in parallel.

Could we just avoid starting useless polemics?

-- =
Cathy
--0015174c34a261d5680463a9bbf9-- From cathypfeffer@gmail.com Tue Feb 24 05:50:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BC33A6950 for ; Tue, 24 Feb 2009 05:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id draDgN9Mt4l4 for ; Tue, 24 Feb 2009 05:50:48 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by core3.amsl.com (Postfix) with ESMTP id C43563A68B2 for ; Tue, 24 Feb 2009 05:50:47 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id j40so245462ugd.15 for ; Tue, 24 Feb 2009 05:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=GIV60L51GpIy8GeEodITOlKQcNk1D6tv/RfMWu3ix2Y=; b=uHA/ie30l27x+dpoR8BQP8B/obQuZQMZHI757cS9mDMThWdNuhTlvQVuazoKO4+BtK uDR+W0HICC4k4OlB9Rg70Kx0gqjiI+7LsMnwpqyY2hx0yye+nr/coo33RsdMvppaN33u NQtwLBhOjCVsN1uGmKxuVsBUA/h8nPgTFaiVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NiqHjslaDjrqeMiJxjKmxLRdQCxdU0zdDncLj+NqYDBfEN06coJKE3U/8RGNkEcf+0 s28N1SUdmUmVTHNT024yGPaNkJ/A30V+RCuNndiZjoMAnjlnLEKWPa0g4aux6M31cIfe rm6TJAuaiz+IPYkE4YJgI9NisrGCW8z4+PXzY= MIME-Version: 1.0 Received: by 10.210.35.10 with SMTP id i10mr4393868ebi.151.1235483465728; Tue, 24 Feb 2009 05:51:05 -0800 (PST) Date: Tue, 24 Feb 2009 14:51:05 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c37b419c4da0463aa69c7 Subject: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 13:50:49 -0000 --0015174c37b419c4da0463aa69c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit (Infinity: there is a question for you at the end of this message) Jon said: > A better way is > > > true > key="something_i_like_to_eat_on_sundays">bananas > > > natural way to express it.This has less of the angle bracket tax, and it > has a VERY straight-forward parsing style. In fact, in my opinion it's > the most In XPath, it's now trivial: "value[@key=success]" Yes. I had thought at this solution too, but I had hesitated to propose it straight away to the mailing list... This solution has fewer angle bracket tax, but it also has hidden implications. I assumed (perharps wrongly) that the authors of the XML serialization had seen these implications, and rejected this solution because of these implications. Moving tags (, , and so on) to attribute names or values is not an innocent operation. Here are the consequences I can see: 1) To allow validation of the allowed types, the new "type" attribute would need to be declared as an enumeration in the DTD or schema. No big deal so far. 2) More of a problem: if using XML schema for validation, it is more straightforward to check that 3.14 and 42 are correct, than to check that 3.14 42 are correct. (XML schema allows for checking that the data inside the tags conform to a certain syntax, for example that floats are made of digts and possibly of a decimal dot and a minus sign). 3) The key ("success" or "something_i_like_to_eat_on_sundays") is not part of the data flow anymore, but part of the markup. There are half-religious wars inside the XML world according to what should be an attribute and what should be text ;-). Personally, in this case, I would say that an attribute is more suited to this kind of data, because then we could enumerate all the allowed values for the virtual world context ("name", "taper_x", "socks", "notecard_encoding", whatever is normalized on top of VWSD), so I see this as an advantage of your solution. On the other hand, if I understand well, LLSD has been defined to allow keys to evolve rapidely and to be supported differently across various implementations, so validating the key values is perharps a bad idea. 4) Other advantages of your solution, Jon: default values for attributes could be omitted, and we could address size and signed-ness of the scalars in separate attributes. Examples: 42 would be synonymous of 42 3.14159265353238 would be synonymous of 3.14159265353238 Of course, there is a lot to spare on the angle bracket tax here, since most data is probably integer, 32 bits,, and signed). It is also more future-proof, since 'size="128"' could be added afterward easily, even if not planned initially. > I'm working on a list of the things I think are wrong with the current > proposal, of which this is one thing (there are about six). If we're > open to change on those things (including this), then I could get behind > the LLSD. Stay tuned :-) I have a similar list too ;-). Someone here has proposed a VWSD working group to separate high level concerns (like meshes versus prims) from low level concerns (like data types and serializations). If we are sure that xxSD is the way to go (and not ASN or whatever), I would volunteer to be part of such a group, and so would you, Jon, I guess ;-). Infinity, how was the XML serialization thought? Have several alternatives been compared and considered carefully? Or is it just the result of the inspiration of the person who made it at a given time? -- Cathy --0015174c37b419c4da0463aa69c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (Infinity: there is a question for you at the end of this message)

J= on said:
> A better way is
>
> <map>
> =C2=A0= =C2=A0 <value type=3D"boolean" key=3D"success">tr= ue</value>
> =C2=A0=C2=A0 <value type=3D"string"
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key=3D"something_i_like_to_eat_on= _sundays">bananas</value>
> </map>
>
>= ; natural way to express it.This has less of the angle bracket tax, and it =
> has a VERY straight-forward parsing style. In fact, in my opinion it&#= 39;s
> the most In XPath, it's now trivial: "value[@key=3Ds= uccess]"

Yes. I had thought at this solution too, but I had hes= itated to propose it straight away to the mailing list...

This solution has fewer angle bracket tax, but it also has hidden impli= cations. I assumed (perharps wrongly) that the authors of the XML serializa= tion had seen these implications, and rejected this solution because of the= se implications.

Moving tags (<key>, <boolean>, <string> and so on) to= attribute names or values is not an innocent operation. Here are the conse= quences I can see:


1) To allow validation of the allowed types, = the new "type" attribute would need to be declared as an enumerat= ion in the DTD or schema.

No big deal so far.


2) More of a problem: if using XML schem= a for validation, it is more straightforward to check that
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 <float>3.14</float>
and
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 <integer>42</integer>
are correct, than to check that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <value= type=3D"float">3.14</value>
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 <value type=3D"integer">42</value>
are correct.

(XML schema allows for checking that the data inside th= e tags conform to a certain syntax, for example that floats are made of dig= ts and possibly of a decimal dot and a minus sign).


3) The key (= "success" or "something_i_like_to_eat_on_sundays") is n= ot part of the data flow anymore, but part of the markup.

There are half-religious wars inside the XML world according to what sh= ould be an attribute and what should be text ;-). Personally, in this case,= I would say that an attribute is more suited to this kind of data, because= then we could enumerate all the allowed values for the virtual world conte= xt ("name", "taper_x", "socks", "notecar= d_encoding", whatever is normalized on top of VWSD), so I see this as = an advantage of your solution.

On the other hand, if I understand well, LLSD has been defined to allow= keys to evolve rapidely and to be supported differently across various imp= lementations, so validating the key values is perharps a bad idea.


4) Other advantages of your solution, Jon: default values for attribute= s could be omitted, and we could address size and signed-ness of the scalar= s in separate attributes.

Examples:
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 <value>42</value>
would be synonymous of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = <value type=3D"integer" size=3D"32" signed=3D"y= es">42</value>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <value type=3D"= ;float" size=3D"64">3.14159265353238</value>
wou= ld be synonymous of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <= ;value type=3D"float" size=3D"64" signed=3D"yes&qu= ot;>3.14159265353238</value>

Of course, there is a lot to spare on the angle bracket tax here, since= most data is probably integer, 32 bits,, and signed).

It is also mo= re future-proof, since 'size=3D"128"' could be added afte= rward easily, even if not planned initially.


> I'm working on a list of the things I think are wrong with= the current
> proposal, of which this is one thing (there are about= six). If we're
> open to change on those things (including this= ), then I could get behind
> the LLSD. Stay tuned :-)

I have a similar list too ;-). Someone= here has proposed a VWSD working group to separate high level concerns (li= ke meshes versus prims) from low level concerns (like data types and serial= izations). If we are sure that xxSD is the way to go (and not ASN or whatev= er), I would volunteer to be part of such a group, and so would you, Jon, I= guess ;-).

Infinity, how was the XML serialization thought? Have several alternati= ves been compared and considered carefully? Or is it just the result of the= inspiration of the person who made it at a given time?

--
Cathy=
--0015174c37b419c4da0463aa69c7-- From cathypfeffer@gmail.com Tue Feb 24 06:40:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B993A69A0 for ; Tue, 24 Feb 2009 06:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bbs2gsZVosEz for ; Tue, 24 Feb 2009 06:40:42 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by core3.amsl.com (Postfix) with ESMTP id F16C53A6887 for ; Tue, 24 Feb 2009 06:40:41 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id j40so247513ugd.15 for ; Tue, 24 Feb 2009 06:40:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=PJQZSLkdvw+2zevJl/h5JA7BI0njKsFP6L4IS44jXpw=; b=jUWoLeWkkA5Q6hx5GTtaT0RW3UskvLmZuLrjtR2pdyrgqHiRricVp0FcVK5P6ndEER q1l6cRGz4FlaTlD2FfaZFJDEVHVfFaFT73ZXRLd4H6pDwpA1lxApNN7l5aZnXwe7xyxd DQPz9IsA6eNg4vV+7QAsFEZ7pmgYyVw4NWFGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=dW2zxdRmIi5lIosyzP/3M65Iv+X58ViM/JcmyIUNcW20G5EWgtFyOX1LHXctW3pKLW 9o5LACRl5kRo9iO2CpR+Anm6V/9BTAwZR/rYYRy25An1Zrh3VSXynXEdwsOqrnwRmEvX xAvDpZzEeRX/HWq10g6RcqCaHWg9X4mgOk0OE= MIME-Version: 1.0 Received: by 10.210.129.19 with SMTP id b19mr4418774ebd.190.1235486459105; Tue, 24 Feb 2009 06:40:59 -0800 (PST) Date: Tue, 24 Feb 2009 15:40:58 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174be96685136e0463ab1bfa Subject: [mmox] xxSD working group? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 14:40:46 -0000 --0015174be96685136e0463ab1bfa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Infinity wrote: > Catherine... Jon... > > can you create a proposal for a next generation XML serialization? Yes I can. > the existing serialization is in current use by SL, OpenSim and PyOGP, Really? I am surprised to hear that, because I had once the curiosity to run Wireshark to sniff packets exchanged by my Second Life client with the simulators, and I saw that the binary serialization was used all the time, even when using the new capacities system. Could you please point me to a situation where I could test the existing XML serialization? > so there's probably going to be a lot of resistance to changing > something that currently works and is deployed. Infinity, we need to make once for all clear whether this is just a Linden Lab existing technologies rubber stamping work group, or if we are designing vendor independent protocols for the 3 dimensional web of the future. While I agree there is no reason to throw away existing stuff (like LLSD's simplicity) when it is cool, I think that every bit of the technology should be evaluated, and replaced when it has conceptual flaws in it. If you disagree with this position, please state it clearly, and I would be happy to withdraw from this mailing list and to go to other projects where I might be more useful. Similarly, if Linden Lab's position is "let them speak and then enforce our own stuff at the end", please also spare my time. > keep in mind, however, that OGP does not use XML to represent it's > PDUs, it uses LLSD. XML is one of three defined serializations of > LLSD. it's a subtle difference, but important. I have it in mind, even though the rationale for using three different serializations is far from being clear to me. > for instance... is there a benefit to explicitly adding support for > namespaces to the XML serialization? That's a very good question. What would be the purposes of such namespaces? > there was a bit of discussion > about this amongst some AWG members, and the consensus was... "why > bother? the XML (presentation layer) is not the place where you want > to extend the PDU... you want to extend it in the LLSD / LLIDL > definition of the interaction." Makes sense. But this reasoning apparently assumes that the namespaces would be used to extend the interoperability standard. Normally, namespaces are rather used to mix data from different standards. That could be *very useful* if we want to mix LLSD for example with a mesh description expressed in another standard. Or to be able to include SVG graphics. Etc. While this would be very powerful, that would not scale back to the two other serializations, because it's pure XML mechanisms. (That's not the only point where needing support for three serializations has drawbacks. For example, LLIDL would become unnecessary if using only XML, because the names and types of the fields could be stored in schema or DTD fragments, or even in a WSDL dictionary. But never mind.) > but, i still think it's an interesting idea as it might allow systems > that use XML serialization exclusively to extend display and > distribution options of various PDUs. -- Cathy --0015174be96685136e0463ab1bfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Infinity wrote:
> Catherine... Jon...
>
> can you create = a proposal for a next generation XML serialization?

Yes I can.
> the existing serialization is in current use by SL, OpenSim and PyOG= P,=C2=A0

Really? I am surprised to hear that, because I had once the curiosity t= o run Wireshark to sniff packets exchanged by my Second Life client with th= e simulators, and I saw that the binary serialization was used all the time= , even when using the new capacities system. Could you please point me to a= situation where I could test the existing XML serialization?

> so there's probably going to be a lot of resistance to changin= g =C2=A0
> something that currently works and is deployed.

Inf= inity, we need to make once for all clear whether this is just a Linden Lab= existing technologies rubber stamping work group, or if we are designing v= endor independent protocols for the 3 dimensional web of the future.

While I agree there is no reason to throw away existing stuff (like LLS= D's simplicity) when it is cool, I think that every bit of the technolo= gy should be evaluated, and replaced when it has conceptual flaws in it.
If you disagree with this position, please state it clearly, and I woul= d be happy to withdraw from this mailing list and to go to other projects w= here I might be more useful. Similarly, if Linden Lab's position is &qu= ot;let them speak and then enforce our own stuff at the end", please a= lso spare my time.

> keep in mind, however, that OGP does not use XML to represent it&#= 39;s =C2=A0
> PDUs, it uses LLSD. XML is one of three defined seriali= zations of =C2=A0
> LLSD. it's a subtle difference, but important= .

I have it in mind, even though the rationale for using three different seri= alizations is far from being clear to me.

> for instance... is th= ere a benefit to explicitly adding support for =C2=A0
> namespaces to= the XML serialization?

That's a very good question. What would be the purposes of such nam= espaces?

> there was a bit of discussion =C2=A0
> about thi= s amongst some AWG members, and the consensus was... "why =C2=A0
&g= t; bother? the XML (presentation layer) is not the place where you want =C2= =A0
> to extend the PDU... you want to extend it in the LLSD / LLIDL =C2=A0<= br>> definition of the interaction."

Makes sense.

But= this reasoning apparently assumes that the namespaces would be used to ext= end the interoperability standard.

Normally, namespaces are rather used to mix data from different standar= ds.

That could be *very useful* if we want to mix LLSD for example w= ith a mesh description expressed in another standard. Or to be able to incl= ude SVG graphics. Etc. While this would be very powerful, that would not sc= ale back to the two other serializations, because it's pure XML mechani= sms.

(That's not the only point where needing support for three serializ= ations has drawbacks. For example, LLIDL would become unnecessary if using = only XML, because the names and types of the fields could be stored in sche= ma or DTD fragments, or even in a WSDL dictionary. But never mind.)

> but, i still think it's an interesting idea as it might allow = systems =C2=A0
> that use XML serialization exclusively to extend dis= play and =C2=A0
> distribution options of various PDUs.


--=
Cathy
--0015174be96685136e0463ab1bfa-- From cs@comlounge.net Tue Feb 24 06:57:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9746D3A6AA5 for ; Tue, 24 Feb 2009 06:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le5gfdMOYCEp for ; Tue, 24 Feb 2009 06:57:18 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 0118D3A67A2 for ; Tue, 24 Feb 2009 06:57:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 912C91CE028B; Tue, 24 Feb 2009 15:57:36 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32HmZGwBU6mr; Tue, 24 Feb 2009 15:57:35 +0100 (CET) Received: from [192.168.1.20] (p5B395609.dip.t-dialin.net [91.57.86.9]) by post.comlounge.net (Postfix) with ESMTP id A8EAB1CE00CD; Tue, 24 Feb 2009 15:57:33 +0100 (CET) Message-ID: <49A40ADA.2080309@comlounge.net> Date: Tue, 24 Feb 2009 15:57:30 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] xxSD working group? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 14:57:19 -0000 Catherine Pfeffer wrote: > Infinity wrote: >> Catherine... Jon... >> >> can you create a proposal for a next generation XML serialization? > > Yes I can. > >> the existing serialization is in current use by SL, OpenSim and PyOGP, > > Really? I am surprised to hear that, because I had once the curiosity to > run Wireshark to sniff packets exchanged by my Second Life client with > the simulators, and I saw that the binary serialization was used all the > time, even when using the new capacities system. Could you please point > me to a situation where I could test the existing XML serialization? > >> so there's probably going to be a lot of resistance to changing >> something that currently works and is deployed. > > Infinity, we need to make once for all clear whether this is just a > Linden Lab existing technologies rubber stamping work group, or if we > are designing vendor independent protocols for the 3 dimensional web of > the future. > > While I agree there is no reason to throw away existing stuff (like > LLSD's simplicity) when it is cool, I think that every bit of the > technology should be evaluated, and replaced when it has conceptual > flaws in it. I also wonder if we not first should think about a general architecture and then check all the fields if we can use existing formats or not and if not, what the requirements are our inventions need to fulfil. > If you disagree with this position, please state it clearly, and I would > be happy to withdraw from this mailing list and to go to other projects > where I might be more useful. Similarly, if Linden Lab's position is > "let them speak and then enforce our own stuff at the end", please also > spare my time. > >> keep in mind, however, that OGP does not use XML to represent it's >> PDUs, it uses LLSD. XML is one of three defined serializations of >> LLSD. it's a subtle difference, but important. > > I have it in mind, even though the rationale for using three different > serializations is far from being clear to me. I also wonder how much the "normal" programmer will understand this. Most likely they will skip the LLSD step and directly output the XML or parse that. It might not be good but if this thing gets widespread it will certainly happen. >> for instance... is there a benefit to explicitly adding support for >> namespaces to the XML serialization? > > That's a very good question. What would be the purposes of such namespaces? I wonder this, too. Especially if this is just a serialization layer. What do you do with namespaces if you deserialize to LLSD? What happens to them if you then serialize again into a different format? Maybe some XML representation is really all which is needed. One might also look at OpenSocial where they have two formats, ATOM and JSON and rules for translating one to the other. Maybe even ATOM is usable as a base here. Also remember that adding new concepts/terms/names to something will make it more difficulty to understand. If it's just XML or JSON or whatever is in use already, it's easier to understand and it might get more adoption. >> there was a bit of discussion >> about this amongst some AWG members, and the consensus was... "why >> bother? the XML (presentation layer) is not the place where you want >> to extend the PDU... you want to extend it in the LLSD / LLIDL >> definition of the interaction." > > Makes sense. > > But this reasoning apparently assumes that the namespaces would be used > to extend the interoperability standard. > > Normally, namespaces are rather used to mix data from different standards. Well, I know a lot of places where it's used to add additional attributes etc. > That could be *very useful* if we want to mix LLSD for example with a > mesh description expressed in another standard. Or to be able to include > SVG graphics. Etc. While this would be very powerful, that would not > scale back to the two other serializations, because it's pure XML > mechanisms. Right. But you might say that such a mesh is stored in one field (tag then) and you can simply copy the whole XML part over to this field in e.g. a JSON structure. But that might be somewhat messy ;-) But actually I really would first think about a more global approach towards a general architecture and then defined the more details protocols and formats needed. -- 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 cs@comlounge.net 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 cathypfeffer@gmail.com Tue Feb 24 07:10:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 049243A68AD for ; Tue, 24 Feb 2009 07:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASgptjQMCIQv for ; Tue, 24 Feb 2009 07:10:30 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id B28EC3A6805 for ; Tue, 24 Feb 2009 07:10:29 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so512076eya.31 for ; Tue, 24 Feb 2009 07:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=htaSbR1/zFVj1jwl8ATwpWbb4BWPaq4j39BHtuzrDRc=; b=MzxNKhVXHRlCcKyikqkAQXFdC7bTpUjFFxcuw8a160aWVzxCwU8atjxy3mYZd/nStN iF84cps0chXyFfoZbLtjQ0rCJt7P5y+aPiHrzimhclEjWiLwR3eaYBT4uCXpGfMO5G3I a1x5E2ZmgL2vk6vC36M6Hy+UpJVB8R9IzPB08= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ye+P2qRTWa78cc8GIz6xdCx/YCjfYI9haRK2pKP+3PDubE8EOjPfTsCjw4p3oDMvzx umyY+q4FWgVZ9hUE9kHxtOS22RRKMl1coyUNfGHG2El7Zemx3iHHrhk0X+8PgeLaPtud nr1qBbWC7jut+xKx5AW0EOky4lQm5R7fhfUZU= MIME-Version: 1.0 Received: by 10.210.17.14 with SMTP id 14mr4441289ebq.181.1235488247291; Tue, 24 Feb 2009 07:10:47 -0800 (PST) Date: Tue, 24 Feb 2009 16:10:47 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174be6ea1a9ea90463ab869d Subject: [mmox] xxSD XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 15:10:31 -0000 --0015174be6ea1a9ea90463ab869d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Zero wrote: > Jon Watte wrote: > > > > > key="something_i_like_to_eat_on_sundays">bananas > > > > This format is notably more difficult for schemas (from XMLSchema to > RelaxNG) to support, since value now has a key attribute that is only > valid if it is tested in a map element. Yes. Jon should have named it "entry" and not "value", so it would have been clear that it can appear only in a map. Moving the data type to a "type" attribute could be generalized outside of a map for all values. That's a separate problem that raises its own concerns, and also has advantages, which I have discussed in my previous mail. (Side note: both XML schema and Relax NG have provisions for context-dependant validation, expressed in "Russian doll" style. So it would not be that difficult. It would only be ugly from a conceptual point of view...) > Second, you have left out > the top element, which needs to be something fixed, rather than being > map or array or value depending on the structure of the data. Omitting was probably just a way for Jon to get quickly to the point. -- Cathy --0015174be6ea1a9ea90463ab869d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Zero wrote:
> Jon Watte wrote:
> > <map>
> > = <value type=3D"boolean" key=3D"success>true</value&= gt;
> > <value type=3D"string" =C2=A0
> > ke= y=3D"something_i_like_to_eat_on_sundays">bananas</value>=
> > </map>
>
> This format is notably more difficul= t for schemas (from XMLSchema to =C2=A0
> RelaxNG) to support, since = value now has a key attribute that is only =C2=A0
> valid if it is te= sted in a map element.

Yes. Jon should have named it "entry" and not "value&quo= t;, so it would have been clear that it can appear only in a map.

Mo= ving the data type to a "type" attribute could be generalized out= side of a map for all values. That's a separate problem that raises its= own concerns, and also has advantages, which I have discussed in my previo= us mail.

(Side note: both XML schema and Relax NG have provisions for context-de= pendant validation, expressed in "Russian doll" style. So it woul= d not be that difficult. It would only be ugly from a conceptual point of v= iew...)

>=C2=A0 Second, you have left out =C2=A0
> the top element, wh= ich needs to be something fixed, rather than being =C2=A0
> map or ar= ray or value depending on the structure of the data.

Omitting <ll= sd> was probably just a way for Jon to get quickly to the point.

--
Cathy
--0015174be6ea1a9ea90463ab869d-- From cathypfeffer@gmail.com Tue Feb 24 07:29:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3AD73A6836 for ; Tue, 24 Feb 2009 07:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6MC62pLi7GN for ; Tue, 24 Feb 2009 07:29:26 -0800 (PST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by core3.amsl.com (Postfix) with ESMTP id B83273A6820 for ; Tue, 24 Feb 2009 07:29:25 -0800 (PST) Received: by ug-out-1314.google.com with SMTP id j40so252045ugd.15 for ; Tue, 24 Feb 2009 07:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=MISq53lEo0rLBsnI7MBaW+23dspi1jg85Cv91J6U+Rs=; b=dud3nR0QzLIWit9RTSzgNKTTf/lUOYjfq3E0+KdagiUCLgIigcIIBX/aVoNTIVDAPZ IGPqyR0BQdU5QAPFUBFXxu/llUjQyU7nEfLIGOyOL2oyomUn9SY6pm937dQfaDsptXat zbjFgcDW9tNX9J9pIN575LM6MNQClrJdGNX+s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VOdvMMEr3BuWnqouLBbVmQWAXAFgKiW/LG00nU0K7tIWmtkNKeBJPWxpF38krksfTB JE06m4ZeDKFPvIB1gMCqBWqV9+KhE9o7TB5JQxCpw+wW4QGFGfUSSLyBKzl8J2XJUaZk bbTd4kPpyfZ1zws41mqj0M1/v2omZqRWcSvXQ= MIME-Version: 1.0 Received: by 10.210.54.15 with SMTP id c15mr4471257eba.139.1235489383479; Tue, 24 Feb 2009 07:29:43 -0800 (PST) Date: Tue, 24 Feb 2009 16:29:43 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174beb3ad379f60463abc986 Subject: [mmox] Requirements for new xxSD specification X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 15:29:27 -0000 --0015174beb3ad379f60463abc986 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Infinity wrote: > so my response would be: > 1.a. can we look at the effect before making this change? my > suspicion is that message sizes will be much more affected by turning > on compressed content encoding than with the change from one DTD to > another. Of course. Whatever we come up with, it must meet the following requirements : 1 - be easy to validate with a schema or DTD 2 - be easy to parse and transform with XSLT and XPath 3 - have low "angle bracket tax" price to pay (and that should be expressed as a precise "bloat ratio" relative to the binary serialization for the same set of data) 4 - be future-proof, i.e. allow for things that have been identified as missing, like lack of alternative sizes for integers and floats, and lack of unsigned. I also have a detail question/concern about the current LLSD serialization. What is the intention on how to serialize big amounts of data, like an avatar mesh or a PNG picture? Are they supposed to go into a big ... blob? Because, if that is true, the binary data encoded so will have to be base64-encoded inside of the tags, and that's a point that might make the whole XML serialization almost unusable, because the angle bracket tax would probably become unacceptable in typical data exchanges. -- Cathy --0015174beb3ad379f60463abc986 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Infinity wrote:
> so my response would be:
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 1.a. can we look at the effect before making this = change? my =C2=A0
> suspicion is that message sizes will be much more= affected by turning =C2=A0
> on compressed content encoding than wit= h the change from one DTD to =C2=A0
> another.

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

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

--
Cathy
--0015174beb3ad379f60463abc986-- From wjgeorge@dceo.rutgers.edu Tue Feb 24 07:56:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35D533A69FE for ; Tue, 24 Feb 2009 07:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpOndIwNGvjH for ; Tue, 24 Feb 2009 07:56:10 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 350703A67AE for ; Tue, 24 Feb 2009 07:56:09 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2347386yxm.49 for ; Tue, 24 Feb 2009 07:56:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.106.12 with SMTP id e12mr6013521anc.18.1235490988283; Tue, 24 Feb 2009 07:56:28 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2009 10:56:28 -0500 Message-ID: <27a487810902240756y708e667arb965dc7b1e17c987@mail.gmail.com> From: William George To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016e642d3a47ad91b0463ac29f5 Subject: Re: [mmox] mmox Digest, Vol 1, Issue 127 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 15:56:11 -0000 --0016e642d3a47ad91b0463ac29f5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit jw wrote: > :Btw: nobody has told me what "rez" actually stands for, and why that word would be better to use than just "instantiate." its the opposite of de-rezzed (de -resolved). And it sounds cool: "i just rezzed in" googled: http://catb.org/~esr/jargon/html/D/de-rezz.html Waka --0016e642d3a47ad91b0463ac29f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable jw wrote:
> :Btw: nobody has told me what "rez" actually st= ands for, and why that
word would be better to use than just "instantiate."

its the opposite of de-rezzed (de -resolved). And it sounds cool:=A0 &q= uot;i just rezzed in"

googled:

http://catb.org/~esr/jargon/html/D/de-re= zz.html

Waka

--0016e642d3a47ad91b0463ac29f5-- From dwl@us.ibm.com Tue Feb 24 08:04:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846743A6A3A; Tue, 24 Feb 2009 08:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.994 X-Spam-Level: X-Spam-Status: No, score=-5.994 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSf2x+o126kg; Tue, 24 Feb 2009 08:04:33 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 763A43A68DB; Tue, 24 Feb 2009 08:04:29 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1OG5hDc005583; Tue, 24 Feb 2009 11:05:43 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n1OG4l2w194420; Tue, 24 Feb 2009 11:04:47 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n1OG4l5L024039; Tue, 24 Feb 2009 11:04:47 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n1OG4lND024036; Tue, 24 Feb 2009 11:04:47 -0500 In-Reply-To: To: mmox@ietf.org, mmox-bounces@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Tue, 24 Feb 2009 11:04:45 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/24/2009 11:04:46 Content-Type: multipart/mixed; boundary="=_mixed 0058541F85257567_=" Subject: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:04:37 -0000 --=_mixed 0058541F85257567_= Content-Type: multipart/alternative; boundary="=_alternative 0058541F85257567_=" --=_alternative 0058541F85257567_= Content-Type: text/plain; charset="US-ASCII" After chewing through the entire mailing list the past week, I've banged out something which *might* help structure our discussions a bit. I offer the following as an attempt to distill and focus some of our thinking. We are roughly 4 weeks from a face to face, and while i do not expect a charter to emerge directly from that BOF, I think we need to end the face to face with enough of an agreed broad framework, that we can imagine generating a consensus charter on the mailing list prior to the next IETF face to face in July. I am posting this as a complete document. I am looking for broad consensus and proposed revisions, and will take them and spin back subsequent versions on a hopefully daily turn around. I don't expect the document to survive close to unchanged, but I'd like to try and manage it as a series of successive drafts, so we can have something consistent to talk about. I look at this as "If we can get rough consensus on this" then we can use it as a basis for driving forward on a set of charter level tasks. I am attaching the input as a .txt and a (sigh) Microsoft word document. I am also posting it in line as plan text. (tho ugly, I'll work on that for future versions) There has been a fair bit of discussion on the MMOX mailing list, and in casual discussions about what we are actually trying to achieve. In service of a better answer, I am going to try and summarize: 1. The problem space we are tackling 2. An Enumeration of interoperability goals in the problem space 3. Some approaches to solving these goals 4. How to both make concrete progress within the IETF approach and end up with a solution that people will actually want to adopt. 5. Some things which fall out of scope I will try to cast both the problems and solutions separately from any specific virtual worlds or MMOS and instead draw on several underlying models as I describe things. Please view this as a strawman intended to provoke discussion, but also think of it as intended to evolve into something we can actually use to structure our work going forward. v I am taking as a given that we are all professionals, engaged in a respectful, and thoughtful exercise to generate good engineering solutions. I welcome engaged, constructive, on topic discussion. Please read the IETF NOTEWELL notice: http://www.ietf.org/NOTEWELL.html Our goal, is a code driven, process, anchored in the ability to prove that specifications we create actually interoperate and work as described. Specifications do not advance in the IETF in the absence of demonstrated interoperability based on running code. - David W. Levine ~ Zha Ewry (In Second Life) ------------------------------------------- The Problem Space: I take MMOX as Massively MultiParty Online eXperiences (Since Meadbh didn't define X, we all get a shot at it) Lets take this one bit at a time. Massively, as in experiences intended to be shared by tens, hundreds, thousands, and over time, a significant fraction of the interne community. Online, focusing our attention on the concurrent shared portion of the experiences and eXperience as a shorthand for (Games, Applications and shared experiences.) The group's name and remit is intentionally broad, focused on a general set of Games and Applications, not any single game, application or experience. The group's roots, and interests are largely, but not exclusively shaped by Virtual Worlds, including MMO games, Virtual worlds, Collaboration and Simulation Environments and shared online streaming environments. Examples of these platforms include, but are not limited to World Of Warcaft, ProtonSphere, Eve Online, Forterra's OLIVE platform, Club Penguin, Linden Lab's Second Life, IMVU, There.com, Croquet, OpenSimulator.org, Weblins. The common thread across all of these environments is a concurrent shared experience, often, but not exclusively rendered in a three dimensional space. Here's one attempt to scope what these environment share: 1. One or more virtual spaces 2. A set of users 3. A representation of the users projected into the space 4. A shared experience of the events in the space projected back to all the users currently in the space. (Text, Voice, and the results of actions) Many of these environments will also include one or more of: 5. Objects which can be dynamically created and modified to form part of the space's setting 6. Persistent state in the virtual space(s) 7. Mechanisms to associate external streams of media with portions of the immersive space 8. Mechanisms to run scripted behaviors in the space 9. Simulated physics and behavior of objects and projected users in the spaace 10. Mechanisms for users to move from one virtual space to another (by hand off between regions implicitly, or by explicit user request (teleport) 11. Libraries of material the users can add to the space 12. Mechanisms for users which are not in a common virtual space to interact with each other in some form (be aware of each other's locations and online status, message each other, etc) Note I've very carefully avoided using most of the common words for the shared experience. We often speak of Simulators, Avatars, Regions, Assets and so forth, for the moment, I'm going to keep those terms off the table to think about the problem in its more general form. Note that I'm also very consciously taking a minimal base with optional features approach to describing the space. This allows us to focus on the core overlapping features, and then a set of services which add to this core. Think about how these goals and solutions could be applied to collaborative spaces such as Wikis, Micro blogging streams and collaborative desktop and application environments. Interoperability is not about defining the one true system which satisfies these goals. Interoperability is about making multiple existing implementation interoperate by the use of standards we define. Goals: What sort of interoperability do we desire out of these spaces? I will start with some statements from the perspective of user experience, and then talk about the technical implications of these use cases. I will also start with the broadest, most expansive goals and then look at how to break these apart into a series of sub goals. These goals are structured with the intent of listing a range of experiences we hope to enable. There sometimes seems to be a strong desire to think about the ultimate end state, where there is one uber-client, and every single virtual space implements every single capability in super grid spanning the world. I think that, its important to think of interoperability as happening over time, and in clusters of increasingly integrated services and spaces. Some low hanging fruit will come early. Some worlds, which are close in design will get deeper benefits sooner, others will only gradually become more tightly integrated. There are many important, useful, and desirable states between "nothing shares" and "Its one single model of everything." Note: These goals are not use cases. Ideally, each goal will, over time, spawn a set of use cases to help define them, and additionally some "cross goal" use cases will be generated which will show how multiple goals work together to provide valuable results. 1. The ability to manage one's identity when interacting in multiple MMOX spaces. a. Allowing presence information to be shared and coordinated across MMOX spaces b. Permitting friends lists, and IMs to be shared across spaces c. Permitting MMOX spaces to share naming d. Simple ways of allowing a consistent name, managed by the user, and verifiable by other users e. Single sign on, mediated by multiple spaces, within the policy constraints of the spaces f. A consistent appearance, within the constraints of the various systems g. The ability to manage the degree of visibility / coupling between identities in MMOX spaces Note that for all of these, there is no requirement to couple the systems together beyond managing identity, and share presence and IM information. These use cases don't speak to how you move between spaces. You may have to shutdown your client on one system and start another. This also is not a "You must enable this" this is very much a "Make it easy for spaces which want to enable this to do it." Also, note that "presence and messaging" speak to user needs, and consitent appearance and name (when desired by users) again speeks to meeting user's desires. 2. The ability for the services in an MMOX world to be named, and authenticated a. Services to associate virtual places and the services which support them with authentication and administrative domains b. Services to permit a service to validate the membership of a remote service in one or more authentication and administrative domains This is needed so that we can do essentially any of the interoperability work. Without some framework which lets us know who we are talking to, it is impossible to trust the behavior of distributed systems. 3. The ability to share content between MMOX spaces a. Import and Export of content and models (This may well leverage off of existing work such as Collada) Static, import/export of content while not terribly dramatic is an important part of the value chain of interoperability b. Mark up schemes which recognize the existence of multiple presentation environments, but permit the sharing of content i. Shared "type" information for the various types of graphical content which MMOX spaces contain ii. Extensible, with a common registry, so that we can understand the types of contents a client can accept, and a virtual space, or virtual asset store can be asked to provide c. A MMOX based, system independent asset addressing scheme which includes i. Content negotiation based on 2b ii. Access Management based on (1) and (2) This is, to my mind, the key mid term deliverable 4. The affordances in MMOX to permit the creation of micro-payment economies a. Appropriate spots defined in MMOX protocols for cost information b. Appropriate spots defined in MMOX protocols for reference to micropayment systems 5. The ability to share "non immersive streams" between spaces a. Markup to permit the consistent sharing of stream media such as voice, and video, with shared start and synchronization information to permit "parallel" events between MMOX space 6. The ability to express Policy intent between MMOX services and virtual spaces a. Places in reserved in the MOX protocols for expressing policy intent b. One or more policy languages for expressing policy The solution space: Most of the deployed solutions partition the software problem into the following chunks. 1. Some form of a client which permits a user to interact with the shared experience 2. Virtual space servers which manage the state of a portion of virtual space 3. A set of supporting services used by the virtual space servers Note that exactly how these three large chunks are assembled and the granular nature of the services can vary radically, even when serving very similar environments. Some environments push a large amount of rendering and management onto complex clients, others perform the bulk of rendering in the server portion of the deployment. Some implementations combine client and simulation into a single entity which does some simulation and some user presentation. Some distribute the simulation, some centralize it. The heart of most of the solutions is managing to accept and merge a stream of updates, and then distribute the merged updates back to users. This can happen at a range of granularities. The two ends of the spectrum, are, roughly, sending updates as a fully merged audio visual stream, which the client merely displays, and sending low level changes to a underlying mode, which the client uses to assemble a complete visual representation of the scene. Variations include croquet and qwaq which use an underlying distributed object model to pass large amounts of updates, and approaches such as used by SecondLife and Protonsphere, where voice is managed in a separate service, with the merged state service merely letting the voice service know where the users are located. Closely related, are issues of representation and format of content. This takes several, separable forms. Import and Export of material to the core environment, and, more problematically, run time representations Approach Our overall approach should be web centric, and web services oriented. We can, and should think of sets of related services which can be composed as part of different solutions which will enable varying degrees of interoperability. We can, and should attempt to provide as web like an approach to function as possible. Content negotiation, separation of protocol from security, separation of interface from implementation and other techniques. Our goal is not to enshrine any single virtual world as the standard for all MMOX spaces, but rather create a flexible, extensible set of services which will allow us to grow larger and large overlapping sets of capabilities. My expectation is that we will see a lot of low hanging fruit in the area of identity, authentication, authorization and presence management (Where a user is, and allowing messaging to them across MMOX spaeces) and initially, we will find a lot of format and content area addressed by gateways, markup, and content negotiation. I see nothing wrong with having a URI which refers to "A pretty maple tree with fall colors" which provides a way to fetch the "Collada Style version" the "3dMax Mesh version" the "Linden Lab 1.2 sculpty spec version" such that a virtual space can select, through content negotiation the one most useful to it. We get value, when we have consistent ways of referring to all the various forms of content, and we get more value when we have ways of using existing content negotiation to allow a web light selection of an appropriate form. It is equally possible to imagine negotiating between a client and a virtual space, the desired form of objects. There are some deep challenges lurking, such as when two different approaches have radically different What I would encourage us, as a mailing list to do, is look through the problem statement, and interoperability goals I've put together here. They are an attempt to capture the various sentiments in the ongoing discussion. I am sure I have missed points, and I am sure some people will disagree with some of the points I have made. I would ask people to look for "No, you missed X" and "Hey, I don't think Y" is true. I will attempt to capture all of those, and revise the document, until we think it represents something close to the general group consensus. (I am not looking for 100% consensus, but a "Yeah, this captures most of what we're trying to do." With that in hand, I would suggest we could then begin to enumerate the specific services and markups we need to support our goals, and begin to flesh out use cases to help us understand the goals and services. I do not expect this to yield a set of specs which Linden Lab, or OpenSim, Or any one virtual world vendor or project would implement whole. What I expect it to yield is a set of specs, which can be combined with existing projects and code bases to drive us towards a more interoperable future. Out of scope I also want to begin to accumulate a short list of "No, this is out of scope" assertions 1. We will provide all the affordances necessary to permit a broad range of interaction policies. Appropriate policies for various deployed solutions and future deployed solutions is out of scope, beyond providing us use cases which highlight specific affordances we may wish to consider 2. Whether or not immersive multi-party spaces are useful and which specific capabilities are required is out of scope. We aspire to support a broad range of possible capabilities, and we respect that different organizations will have different perspectives on what is required. Our goal is to define broad, interoperable frameworks which will enable a range of deployments, not to define the one true model for this space 3. Propose additional statements here Closing comments I don't think our collective goal can be to take any one existing spec or solution and simply declare it the basis for our work going forward. At the same time, we must base our work in actually running code, showing real interoperability. Our goal must be to build supersets of function, based on existing products and solutions which demonstrate real interoperability. The IETF favors working code and growing consensus over blank paper and blue sky efforts. This is based in a history of success and failure in the industry when it comes to building, promoting and succeeding at standards work. Work at the IETF is grounded in working code. One way forward is to focus on several clusters of work. One: a clear, broad framework, which forms the basis for long term broad interoperation. Two: Capturing the current set of incompatible and overlapping formats and protocols in use, so that we can create a extensible and shared catalog of artifacts for sharing. (eg. "Here is the canonical, extensible list of graphic content types you might want to move on a MMOX transport" Three grow out proposed solutions such as LLSD, OGP, and others, as they are contributed towards a common superset which can be used to as the basis for demonstrating concrete progress towards interop goals. Four, Identify places where we simply want to use existing work, such as OpenID, OAuth, X.509 and create a shared profile for how we can use these protocols to further interoperability. --=_alternative 0058541F85257567_= Content-Type: text/html; charset="US-ASCII"
After chewing through the entire mailing list the past week, I've banged out something which *might* help structure our discussions a bit. I offer the following as an attempt to distill and focus some of our thinking.  We are roughly 4 weeks from a face to face, and while i do not expect a charter to emerge directly from that BOF, I think we need to end the face to face with enough of an agreed broad framework, that we can imagine generating a consensus charter on the mailing list prior to the next IETF face to face in July.

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


I am attaching the input as a .txt and a (sigh) Microsoft  word document. I am also posting it in line as plan text. (tho ugly, I'll work on that for future versions)

There has been a fair bit of discussion on the MMOX mailing list, and in casual
discussions about what we are actually trying to achieve. In service of a better answer, I
am going to try and summarize:

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

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

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


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

The Problem Space:

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

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

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

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

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

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

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

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

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

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

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

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

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



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

 Note that for all of these, there is no requirement to couple the systems together
beyond managing identity, and share presence and IM information. These use
cases don't speak to how you move between spaces. You may have to shutdown
your client on one system and start another. This also is not a "You must enable
this" this is very much a "Make it easy for spaces which want to enable this to do
it." Also, note that "presence and messaging" speak to user needs, and consitent
appearance and name (when desired by users) again speeks to meeting user's
desires.

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

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

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

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

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

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

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


The solution space:

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

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

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

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

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

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

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

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

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

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

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

Out of scope

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

1.        We will provide all the affordances necessary to permit a broad range of
interaction policies. Appropriate policies for various deployed solutions and
future deployed solutions is out of scope, beyond providing us use cases which
highlight specific affordances we may wish to consider
2.        Whether or not immersive multi-party spaces are useful and which specific
capabilities are required is out of scope. We aspire to support a broad range of
possible capabilities, and we respect that different organizations will have
different perspectives on what is required. Our goal is to define broad,
interoperable frameworks which will enable a range of deployments, not to define
the one true model for this space
3.        Propose additional statements here
Closing comments
I don't think our collective goal can be to take any one existing spec or solution and
simply declare it the basis for our work going forward. At the same time, we must base
our work in actually running code, showing real interoperability. Our goal must be to
build supersets of function, based on existing products and solutions which demonstrate
real interoperability.

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

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







--=_alternative 0058541F85257567_=-- --=_mixed 0058541F85257567_= Content-Type: text/plain; name="Scope01C.txt" Content-Disposition: attachment; filename="Scope01C.txt" Content-Transfer-Encoding: quoted-printable There has been a fair bit of discussion on the MMOX mailing list, and in ca= sual=20 discussions about what we are actually trying to achieve. In service of a b= etter answer, I=20 am going to try and summarize: 1. The problem space we are tackling 2. An Enumeration of interoperability goals in the problem space 3. Some approaches to solving these goals 4. How to both make concrete progress within the IETF approach and end up w= ith a=20 solution that people wil actually want to adopt.=20 5. Some things which fall out of scope=20 I will try to cast both the problems and solutions separately from any spec= ific virtual=20 worlds or MMOS and instead draw on several underlying models as I describe = things. =20 Please view this as a strawman intended to provoke discussion, but also thi= nk of it as=20 intended to evolve into something we can actually use to structure our work= going=20 forward.=20 I am taking as a given that we are all professionals, engaged in a respectf= ul, and=20 thoughtful exercise to generate good engineering solutions. I welcome engag= ed,=20 constructive, on topic discussion. Please read the IETF NOTEWELL notice:=20 http://www.ietf.org/NOTEWELL.html Our goal, is a code driven, process, anc= hored in=20 the ability to prove that specifications we create actually interoperate an= d work as=20 described. Specifications do not advance in the IETF in the absence of dem= onstrated=20 interoperability based on running code.=20 The Problem Space: I take MMOX as Massively MultiParty Online eXperiences (Since Meadbh didn't= define=20 X, we all get a shot at it) Lets take this one bit at a time. Massively, as= in experiences=20 intended to be shared by tens, hundreds, thousands, and over time, a signif= icant fraction=20 of the interne community. Online, focusing our attention on the concurrent = shared portion=20 of the experiences and eXperience as a shorthand for (Games, Applications a= nd shared=20 experiences.)=20 The group's name and remit is intentionally broad, focused on a general set= of Games and=20 Applications, not any single game, application or experience. The group's = roots, and=20 interests are largely, but not exclusively shaped by Virtual Worlds, includ= ing MMO=20 games, Virtual worlds, Collaboration and Simulation Environments and shared= online=20 streaming environments. Examples of these platforms include, but are not li= mited to=20 World Of Warcaft, ProtonSphere, Eve Online, Forterra's OLIVE platform, Clu= b=20 Penguin, Linden Lab's Second Life, IMVU, There.com, Croquet, OpenSimulato= r.org,=20 Weblins.=20 The common thread across all of these environments is a concurrent shared e= xperience,=20 often, but not exclusively rendered in a three dimensional space. Here's o= ne attempt to=20 scope what these environment share: 1. One or more virtual spaces 2. A set of users 3. A representation of the users projected into the space 4. A shared experience of the events in the space projected back to all the= users=20 currently in the space. (Text, Voice, and the results of actions)=20 Many of these environments will also include one or more of: 5. Objects which can be dynamically created and modified to form part of th= e=20 space's setting 6. Persistent state in the virtual space(s) 7. Mechanisms to associate external streams of media with portions of the=20 immersive space=20 8. Mechanisms to run scripted behaviors in the space 9. Simulated physics and behavior of objects and projected users in the spa= ace 10. Mechanisms for users to move from one virtual space to another (by han= d off=20 between regions implicitly, or by explicit user request (teleport)=20 11. Libraries of material the users can add to the space 12. Mechanisms for users which are not in a common virtual space to interac= t with=20 each other in some form (be aware of each other's locations and online stat= us,=20 message each other, etc)=20 Note I've very carefully avoided using most of the common words for the sha= red=20 experience. We often speak of Simulators, Avatars, Regions, Assets and so f= orth, for the=20 moment, I'm going to keep those terms off the table to think about the prob= lem in its=20 more general form.=20 Note that I'm also very consciously taking a minimal base with optional fea= tures=20 approach to describing the space. This allows us to focus on the core overl= apping=20 features, and then a set of services which add to this core. Think about ho= w these goals=20 and solutions could be applied to collaborative spaces such as Wikis, Micro= blogging=20 streams and collaborative desktop and application environments.=20 Interoperability is not about defining the one true system which satisfies = these goals.=20 Interoperability is about making multiple existing implementation interoper= ate by the use=20 of standards we define.=20 Goals:=20 What sort of interoperability do we desire out of these spaces?=20 I will start with some statements from the perspective of user experience, = and then talk=20 about the technical implications of these use cases. I will also start with= the broadest,=20 most expansive goals and then look at how to break these apart into a serie= s of sub goals.=20 These goals are structured with the intent of listing a range of experience= s we hope to=20 enable. There sometimes seems to be a strong desire to think about the ult= imate end=20 state, where there is one uber-client, and every single virtual space imple= ments every=20 single capability in super grid spanning the world. I think that, its impor= tant to think of=20 interoperability as happening over time, and in clusters of increasingly in= tegrated services=20 and spaces. Some low hanging fruit will come early. Some worlds, which are = close in=20 design will get deeper benefits sooner, others will only gradually become m= ore tightly=20 integrated. There are many important, useful, and desirable states between = "nothing=20 shares" and "Its one single model of everything." Note: These goals are not use cases. Ideally, each goal will, over time, sp= awn a set of use=20 cases to help define them, and additionally some "cross goal" use cases wi= ll be generated=20 which will show how multiple goals work together to provide valuable result= s.=20 1. The ability to manage one's identity when interacting in multiple MMOX s= paces.=20 a. Allowing presence information to be shared and coordinated across=20 MMOX spaces b. Permitting friends lists, and IMs to be shared across spaces c. Permitting MMOX spaces to share naming=20 d. Simple ways of allowing a consistent name, managed by the user, and=20 verifiable by other users e. Single sign on, mediated by multiple spaces, within the policy constrain= ts=20 of the spaces f. A consistent appearance, within the constraints of the various systems g. The ability to manage the degree of visibility / coupling between identi= ties=20 in MMOX spaces Note that for all of these, there is no requirement to couple the systems = together=20 beyond managing identity, and share presence and IM information. These use = cases don't speak to how you move between spaces. You may have to shutdown = your client on one system and start another. This also is not a "You must e= nable=20 this" this is very much a "Make it easy for spaces which want to enable thi= s to do=20 it." Also, note that "presence and messaging" speak to user needs, and cons= itent=20 appearance and name (when desired by users) again speeks to meeting user's = desires.=20 2. The ability for the services in an MMOX world to be named, and authentic= ated a. Services to associate virtual places and the services which support them= =20 with authentication and administrative domains b. Services to permit a service to validate the membership of a remote=20 service in one or more authentication and administrative domains This is needed so that we can do essentially any of the interoperability wo= rk.=20 Without some framework which lets us know who we are talking to, it is=20 impossible to trust the behavior of distributed systems.=20 3. The ability to share content between MMOX spaces a. Import and Export of content and models (This may well leverage off of=20 existing work such as Collada) Static, import/export of content while not=20 terribly dramatic is an important part of the value chain of interoperabili= ty b. Mark up schemes which recognize the existence of multiple presentation=20 environments, but permit the sharing of content i. Shared "type" information for the various types of graphical=20 content which MMOX spaces contain ii. Extensible, with a common registry, so that we can understand the=20 types of contents a client can accept, and a virtual space, or virtual=20 asset store can be asked to provide c. A MMOX based, system independent asset addressing scheme which=20 includes i. Content negotiation based on 2b ii. Access Management based on (1) and (2) This is, to my mind, the key mid term deliverable=20 4. The affordances in MMOX to permit the creation of micro-payment economies a. Appropriate spots defined in MMOX protocols for cost information b. Appropriate spots defined in MMOX protocols for reference to=20 micropayment systems 5. The ability to share "non immersive streams" between spaces=20 a. Markup to permit the consistent sharing of stream media such as voice,=20 and video, with shared start and synchronization information to permit=20 "parallel" events between MMOX space 6. The ability to express Policy intent between MMOX services and virtual s= paces a. Places in reserved in the MOX protocols for expressing policy intent b. One or more policy languages for expressing policy The solution space: Most of the deployed solutions partition the software problem into the foll= owing chunks. 1. Some form of a client which permits a user to interact with the shared e= xperience 2. Virtual space servers which manage the state of a portion of virtual spa= ce 3. A set of supporting services used by the virtual space servers=20 Note that exactly how these three large chunks are assembled and the granul= ar nature of=20 the services can vary radically, even when serving very similar environment= s. Some=20 environments push a large amount of rendering and management onto complex c= lients,=20 others perform the bulk of rendering in the server portion of the deploymen= t. Some=20 implementations combine client and simulation into a single entity which do= es some=20 simulation and some user presentation. Some distribute the simulation, some= centralize it.=20 The heart of most of the solutions is managing to accept and merge a stream= of updates,=20 and then distribute the merged updates back to users. This can happen at a = range of=20 granularities. The two ends of the spectrum, are, roughly, sending updates = as a fully=20 merged audio visual stream, which the client merely displays, and sending l= ow level=20 changes to a underlying mode, which the client uses to assemble a complete = visual=20 representation of the scene. Variations include croquet and qwaq which use= an=20 underlying distributed object model to pass large amounts of updates, and a= pproaches=20 such as used by SecondLife and Protonsphere, where voice is managed in a se= parate=20 service, with the merged state service merely letting the voice service kno= w where the=20 users are located.=20 Closely related, are issues of representation and format of content. This t= akes several,=20 separable forms. Import and Export of material to the core environment, and= , more=20 problematically, run time representations Approach Our overall approach should be web centric, and web services oriented. We c= an, and=20 should think of sets of related services which can be composed as part of d= ifferent=20 solutions which will enable varying degrees of interoperability. We can, an= d should=20 attempt to provide as web like an approach to function as possible. Content= negotiation,=20 separation of protocol from security, separation of interface from implemen= tation and=20 other techniques.=20 Our goal is not to enshrine any single virtual world as the standard for al= l MMOX spaces,=20 but rather create a flexible, extensible set of services which will allow u= s to grow larger=20 and large overlapping sets of capabilities. My expectation is that we will = see a lot of low=20 hanging fruit in the area of identity, authentication, authorization and pr= esence=20 management (Where a user is, and allowing messaging to them across MMOX spa= eces)=20 and initially, we will find a lot of format and content area addressed by g= ateways,=20 markup, and content negotiation. I see nothing wrong with having a URI whic= h refers to=20 "A pretty maple tree with fall colors" which provides a way to fetch the "C= ollada Style=20 version" the "3dMax Mesh version" the "Linden Lab 1.2 sculpty spec version"= such that=20 a virtual space can select, through content negotiation the one most useful= to it.=20 We get value, when we have consistent ways of referring to all the various = forms of=20 content, and we get more value when we have ways of using existing content = negotiation=20 to allow a web light selection of an appropriate form. It is equally possib= le to imagine=20 negotiating between a client and a virtual space, the desired form of objec= ts. There are=20 some deep challenges lurking, such as when two different approaches have ra= dically=20 different=20 What I would encourage us, as a mailing list to do, is look through the pro= blem=20 statement, and interoperability goals I've put together here. They are an a= ttempt to=20 capture the various sentiments in the ongoing discussion. I am sure I have = missed points,=20 and I am sure some people will disagree with some of the points I have made= .=20 I would ask people to look for "No, you missed X" and "Hey, I don't think Y= " is true. I=20 will attempt to capture all of those, and revise the document, until we thi= nk it represents=20 something close to the general group consensus. (I am not looking for 100% = consensus,=20 but a "Yeah, this captures most of what we're trying to do." With that in h= and, I would=20 suggest we could then begin to enumerate the specific services and markups = we need to=20 support our goals, and begin to flesh out use cases to help us understand t= he goals and=20 services.=20 I do not expect this to yield a set of specs which Linden Lab, or OpenSim, = Or any one=20 virtual world vendor or project would implement whole. What I expect it to = yield is a set=20 of specs, which can be combined with existing projects and code bases to dr= ive us=20 towards a more interoperable future.=20 Out of scope I also want to begin to accumulate a short list of "No, this is out of scop= e" assertions 1. We will provide all the affordances necessary to permit a broad range of= =20 interaction policies. Appropriate policies for various deployed solutions a= nd=20 future deployed solutions is out of scope, beyond providing us use cases wh= ich=20 highlight specific affordances we may wish to consider 2. Whether or not immersive multi-party spaces are useful and which specifi= c=20 capabilities are required is out of scope. We aspire to support a broad ran= ge of=20 possible capabilities, and we respect that different organizations will hav= e=20 different perspectives on what is required. Our goal is to define broad,=20 interoperable frameworks which will enable a range of deployments, not to d= efine=20 the one true model for this space 3. Propose additional statements here Closing comments I don't think our collective goal can be to take any one existing spec or s= olution and=20 simply declare it the basis for our work going forward. At the same time, w= e must base=20 our work in actually running code, showing real interoperability. Our goal = must be to=20 build supersets of function, based on existing products and solutions which= demonstrate=20 real interoperability.=20 The IETF favors working code and growing consensus over blank paper and blu= e sky=20 efforts. This is based in a history of success and failure in the industry = when it comes to=20 building, promoting and succeeding at standards work. Work at the IETF is g= rounded in=20 working code.=20 One way forward is to focus on several clusters of work. One: a clear, broa= d framework,=20 which forms the basis for long term broad interoperation. Two: Capturing th= e current set=20 of incompatible and overlapping formats and protocols in use, so that we ca= n create a=20 extensible and shared catalog of artifacts for sharing. (eg. "Here is the c= anonical,=20 extensible list of graphic content types you might want to move on a MMOX = transport"=20 Three grow out proposed solutions such as LLSD, OGP, and others, as they a= re=20 contributed towards a common superset which can be used to as the basis for= =20 demonstrating concrete progress towards interop goals. Four, Identify place= s where we=20 simply want to use existing work, such as OpenID, OAuth, X.509 and create= a shared=20 profile for how we can use these protocols to further interoperability.=20 --=_mixed 0058541F85257567_= Content-Type: application/octet-stream; name="Scope01C.doc" Content-Disposition: attachment; filename="Scope01C.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAWwAAAAAAAAAA EAAAXQAAAAEAAAD+////AAAAAFoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAJWAJBAAA8BK/AAAAAAAAEAAAAAAABgAA1kcAAA4AYmpiak7gTuAAAAAAAAAAAAAAAAAAAAAA AAAJBBYALlwAACyKAQAsigEA1j8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAFIFAAAAAAAAUgUAAFIF AAAAAAAAUgUAAAAAAABSBQAAAAAAAFIFAAAAAAAAUgUAABQAAAAAAAAAAAAAAGYFAAAAAAAAjhYA AAAAAACOFgAAAAAAAI4WAAAAAAAAjhYAABwAAACqFgAANAAAAGYFAAAAAAAAdzAAAOwAAADqFgAA FgAAAAAXAAAAAAAAABcAAAAAAAAAFwAAAAAAAAAXAAAAAAAA2xcAAAAAAADbFwAAAAAAANsXAAAA AAAA9i8AAAIAAAD4LwAAAAAAAPgvAAAAAAAA+C8AAAAAAAD4LwAAAAAAAPgvAAAAAAAA+C8AACQA AABjMQAAaAIAAMszAAByAQAAHDAAABUAAAAAAAAAAAAAAAAAAAAAAAAAUgUAAAAAAADbFwAAAAAA AAAAAAAAAAAAAAAAAAAAAADbFwAAAAAAANsXAAAAAAAA2xcAAAAAAADbFwAAAAAAABwwAAAAAAAA AAAAAAAAAABSBQAAAAAAAFIFAAAAAAAAABcAAAAAAAAAAAAAAAAAAAAXAADbAAAAMTAAABYAAAA3 GgAAAAAAADcaAAAAAAAANxoAAAAAAADbFwAAQgEAAFIFAAAAAAAAABcAAAAAAABSBQAAAAAAAAAX AAAAAAAA9i8AAAAAAAAAAAAAAAAAADcaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA2xcAAAAAAAD2LwAAAAAAAAAAAAAAAAAANxoAAAAAAAA3GgAA wgEAAMIsAABEAQAAUgUAAAAAAABSBQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKi8AAAAAAAAAFwAAAAAAAN4WAAAMAAAAMIpqAZaW yQEAAAAAAAAAAI4WAAAAAAAAHRkAAJoAAAAGLgAAJgAAAAAAAAAAAAAA9i8AAAAAAABHMAAAMAAA AHcwAAAAAAAALC4AAP4AAAA9NQAAAAAAALcZAAB2AAAAPTUAAEwAAAAqLwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAD01AAAAAAAAAAAAAAAAAABSBQAAAAAAACovAADMAAAA2xcAAAAAAADbFwAAAAAAADca AAAAAAAA2xcAAAAAAADbFwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2xcA AAAAAADbFwAAAAAAANsXAAAAAAAAHDAAAAAAAAAcMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAALRoAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANsXAAAA AAAA2xcAAAAAAADbFwAAAAAAAHcwAAAAAAAA2xcAAAAAAADbFwAAAAAAANsXAAAAAAAA2xcAAAAA AAAAAAAAAAAAAGYFAAAAAAAAZgUAAAAAAABmBQAApBAAAAoWAACEAAAAZgUAAAAAAABmBQAAAAAA AGYFAAAAAAAAChYAAAAAAABmBQAAAAAAAGYFAAAAAAAAZgUAAAAAAABSBQAAAAAAAFIFAAAAAAAA UgUAAAAAAABSBQAAAAAAAFIFAAAAAAAAUgUAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRoZXJl IGhhcyBiZWVuIGEgZmFpciBiaXQgb2YgZGlzY3Vzc2lvbiBvbiB0aGUgTU1PWCBtYWlsaW5nIGxp c3QsIGFuZCBpbiBjYXN1YWwgZGlzY3Vzc2lvbnMgYWJvdXQgd2hhdCB3ZSBhcmUgYWN0dWFsbHkg dHJ5aW5nIHRvIGFjaGlldmUuIEluIHNlcnZpY2Ugb2YgYSBiZXR0ZXIgYW5zd2VyLCBJIGFtIGdv aW5nIHRvIHRyeSBhbmQgc3VtbWFyaXplOg0NVGhlIHByb2JsZW0gc3BhY2Ugd2UgYXJlIHRhY2ts aW5nDUFuIEVudW1lcmF0aW9uIG9mIGludGVyb3BlcmFiaWxpdHkgZ29hbHMgaW4gdGhlIHByb2Js ZW0gc3BhY2UNU29tZSBhcHByb2FjaGVzIHRvIHNvbHZpbmcgdGhlc2UgZ29hbHMNSG93IHRvIGJv dGggbWFrZSBjb25jcmV0ZSBwcm9ncmVzcyB3aXRoaW4gdGhlIElFVEYgYXBwcm9hY2ggYW5kIGVu ZCB1cCB3aXRoIGEgc29sdXRpb24gdGhhdCBwZW9wbGUgd2lsIGFjdHVhbGx5IHdhbnQgdG8gYWRv cHQuIA1Tb21lIHRoaW5ncyB3aGljaCBmYWxsIG91dCBvZiBzY29wZSANDUkgd2lsbCB0cnkgdG8g Y2FzdCBib3RoIHRoZSBwcm9ibGVtcyBhbmQgc29sdXRpb25zIHNlcGFyYXRlbHkgZnJvbSBhbnkg c3BlY2lmaWMgdmlydHVhbCB3b3JsZHMgb3IgTU1PUyBhbmQgaW5zdGVhZCBkcmF3IG9uIHNldmVy YWwgdW5kZXJseWluZyBtb2RlbHMgYXMgSSBkZXNjcmliZSB0aGluZ3MuICBQbGVhc2UgdmlldyB0 aGlzIGFzIGEgc3RyYXdtYW4gaW50ZW5kZWQgdG8gcHJvdm9rZSBkaXNjdXNzaW9uLCBidXQgYWxz byB0aGluayBvZiBpdCBhcyBpbnRlbmRlZCB0byBldm9sdmUgaW50byBzb21ldGhpbmcgd2UgY2Fu IGFjdHVhbGx5IHVzZSB0byBzdHJ1Y3R1cmUgb3VyIHdvcmsgZ29pbmcgZm9yd2FyZC4gDQ1JIGFt IHRha2luZyBhcyBhIGdpdmVuIHRoYXQgd2UgYXJlIGFsbCBwcm9mZXNzaW9uYWxzLCBlbmdhZ2Vk IGluIGEgcmVzcGVjdGZ1bCwgYW5kIHRob3VnaHRmdWwgZXhlcmNpc2UgdG8gZ2VuZXJhdGUgZ29v ZCBlbmdpbmVlcmluZyBzb2x1dGlvbnMuIEkgd2VsY29tZSBlbmdhZ2VkLCBjb25zdHJ1Y3RpdmUs IG9uIHRvcGljIGRpc2N1c3Npb24uIFBsZWFzZSByZWFkIHRoZSBJRVRGIE5PVEVXRUxMIG5vdGlj ZTogEyBIWVBFUkxJTksgImh0dHA6Ly93d3cuaWV0Zi5vcmcvTk9URVdFTEwuaHRtbCIgFGh0dHA6 Ly93d3cuaWV0Zi5vcmcvTk9URVdFTEwuaHRtbBUgIE91ciBnb2FsLCBpcyBhIGNvZGUgZHJpdmVu LCBwcm9jZXNzLCBhbmNob3JlZCBpbiB0aGUgYWJpbGl0eSB0byBwcm92ZSB0aGF0IHNwZWNpZmlj YXRpb25zIHdlIGNyZWF0ZSBhY3R1YWxseSBpbnRlcm9wZXJhdGUgYW5kIHdvcmsgYXMgZGVzY3Jp YmVkLiAgU3BlY2lmaWNhdGlvbnMgZG8gbm90IGFkdmFuY2UgaW4gdGhlIElFVEYgaW4gdGhlIGFi c2VuY2Ugb2YgZGVtb25zdHJhdGVkIGludGVyb3BlcmFiaWxpdHkgYmFzZWQgb24gcnVubmluZyBj b2RlLiANVGhlIFByb2JsZW0gU3BhY2U6DQ1JIHRha2UgTU1PWCBhcyBNYXNzaXZlbHkgTXVsdGlQ YXJ0eSBPbmxpbmUgZVhwZXJpZW5jZXMgKFNpbmNlIE1lYWRiaCBkaWRuknQgZGVmaW5lIFgsIHdl IGFsbCBnZXQgYSBzaG90IGF0IGl0KSBMZXRzIHRha2UgdGhpcyBvbmUgYml0IGF0IGEgdGltZS4g TWFzc2l2ZWx5LCBhcyBpbiBleHBlcmllbmNlcyBpbnRlbmRlZCB0byBiZSBzaGFyZWQgYnkgdGVu cywgaHVuZHJlZHMsIHRob3VzYW5kcywgYW5kIG92ZXIgdGltZSwgYSBzaWduaWZpY2FudCBmcmFj dGlvbiBvZiB0aGUgaW50ZXJuZSBjb21tdW5pdHkuIE9ubGluZSwgZm9jdXNpbmcgb3VyIGF0dGVu dGlvbiBvbiB0aGUgY29uY3VycmVudCBzaGFyZWQgcG9ydGlvbiBvZiB0aGUgZXhwZXJpZW5jZXMg YW5kIGVYcGVyaWVuY2UgYXMgYSBzaG9ydGhhbmQgZm9yIChHYW1lcywgQXBwbGljYXRpb25zIGFu ZCBzaGFyZWQgZXhwZXJpZW5jZXMuKSANDVRoZSBncm91cJJzIG5hbWUgYW5kIHJlbWl0IGlzIGlu dGVudGlvbmFsbHkgYnJvYWQsIGZvY3VzZWQgb24gYSBnZW5lcmFsIHNldCBvZiBHYW1lcyBhbmQg QXBwbGljYXRpb25zLCBub3QgYW55IHNpbmdsZSBnYW1lLCBhcHBsaWNhdGlvbiBvciBleHBlcmll bmNlLiAgVGhlIGdyb3VwknMgcm9vdHMsIGFuZCBpbnRlcmVzdHMgYXJlIGxhcmdlbHksIGJ1dCBu b3QgZXhjbHVzaXZlbHkgc2hhcGVkIGJ5IFZpcnR1YWwgV29ybGRzLCBpbmNsdWRpbmcgTU1PIGdh bWVzLCBWaXJ0dWFsIHdvcmxkcywgQ29sbGFib3JhdGlvbiBhbmQgU2ltdWxhdGlvbiBFbnZpcm9u bWVudHMgYW5kIHNoYXJlZCBvbmxpbmUgc3RyZWFtaW5nIGVudmlyb25tZW50cy4gRXhhbXBsZXMg b2YgdGhlc2UgcGxhdGZvcm1zIGluY2x1ZGUsIGJ1dCBhcmUgbm90IGxpbWl0ZWQgdG8gDVdvcmxk IE9mIFdhcmNhZnQsIFByb3RvblNwaGVyZSwgRXZlIE9ubGluZSwgRm9ydGVycmGScyAgT0xJVkUg cGxhdGZvcm0sIENsdWIgUGVuZ3VpbiwgIExpbmRlbiBMYWKScyBTZWNvbmQgTGlmZSwgIElNVlUs IFRoZXJlLmNvbSwgQ3JvcXVldCwgT3BlblNpbXVsYXRvci5vcmcsIFdlYmxpbnMuIA0NVGhlIGNv bW1vbiB0aHJlYWQgYWNyb3NzIGFsbCBvZiB0aGVzZSBlbnZpcm9ubWVudHMgaXMgYSBjb25jdXJy ZW50IHNoYXJlZCBleHBlcmllbmNlLCBvZnRlbiwgYnV0IG5vdCBleGNsdXNpdmVseSByZW5kZXJl ZCBpbiBhIHRocmVlIGRpbWVuc2lvbmFsIHNwYWNlLiAgSGVyZZJzIG9uZSBhdHRlbXB0IHRvIHNj b3BlIHdoYXQgdGhlc2UgZW52aXJvbm1lbnQgc2hhcmU6DQ1PbmUgb3IgbW9yZSB2aXJ0dWFsIHNw YWNlcw1BIHNldCBvZiB1c2Vycw1BIHJlcHJlc2VudGF0aW9uIG9mIHRoZSB1c2VycyBwcm9qZWN0 ZWQgaW50byB0aGUgc3BhY2UNQSBzaGFyZWQgZXhwZXJpZW5jZSBvZiB0aGUgZXZlbnRzIGluIHRo ZSBzcGFjZSBwcm9qZWN0ZWQgYmFjayB0byBhbGwgdGhlIHVzZXJzIGN1cnJlbnRseSBpbiB0aGUg c3BhY2UuIChUZXh0LCBWb2ljZSwgYW5kIHRoZSByZXN1bHRzIG9mIGFjdGlvbnMpIA0NTWFueSBv ZiB0aGVzZSBlbnZpcm9ubWVudHMgd2lsbCBhbHNvIGluY2x1ZGUgb25lIG9yIG1vcmUgb2Y6DQ1P YmplY3RzIHdoaWNoIGNhbiBiZSBkeW5hbWljYWxseSBjcmVhdGVkIGFuZCBtb2RpZmllZCB0byBm b3JtIHBhcnQgb2YgdGhlIHNwYWNlknMgc2V0dGluZw1QZXJzaXN0ZW50IHN0YXRlIGluIHRoZSB2 aXJ0dWFsIHNwYWNlKHMpDU1lY2hhbmlzbXMgdG8gYXNzb2NpYXRlIGV4dGVybmFsIHN0cmVhbXMg b2YgbWVkaWEgd2l0aCBwb3J0aW9ucyBvZiB0aGUgaW1tZXJzaXZlIHNwYWNlIA1NZWNoYW5pc21z IHRvIHJ1biBzY3JpcHRlZCBiZWhhdmlvcnMgaW4gdGhlIHNwYWNlDVNpbXVsYXRlZCBwaHlzaWNz IGFuZCBiZWhhdmlvciBvZiBvYmplY3RzIGFuZCBwcm9qZWN0ZWQgdXNlcnMgaW4gdGhlIHNwYWFj ZQ1NZWNoYW5pc21zIGZvciB1c2VycyB0byAgbW92ZSBmcm9tIG9uZSB2aXJ0dWFsIHNwYWNlIHRv IGFub3RoZXIgKGJ5IGhhbmQgb2ZmIGJldHdlZW4gcmVnaW9ucyBpbXBsaWNpdGx5LCBvciBieSBl eHBsaWNpdCB1c2VyIHJlcXVlc3QgKHRlbGVwb3J0KSANTGlicmFyaWVzIG9mIG1hdGVyaWFsIHRo ZSB1c2VycyBjYW4gYWRkIHRvIHRoZSBzcGFjZQ1NZWNoYW5pc21zIGZvciB1c2VycyB3aGljaCBh cmUgbm90IGluIGEgY29tbW9uIHZpcnR1YWwgc3BhY2UgdG8gaW50ZXJhY3Qgd2l0aCBlYWNoIG90 aGVyIGluIHNvbWUgZm9ybSAoYmUgYXdhcmUgb2YgZWFjaCBvdGhlcpJzIGxvY2F0aW9ucyBhbmQg b25saW5lIHN0YXR1cywgbWVzc2FnZSBlYWNoIG90aGVyLCBldGMpIA0NTm90ZSBJknZlIHZlcnkg Y2FyZWZ1bGx5IGF2b2lkZWQgdXNpbmcgbW9zdCBvZiB0aGUgY29tbW9uIHdvcmRzIGZvciB0aGUg c2hhcmVkIGV4cGVyaWVuY2UuIFdlIG9mdGVuIHNwZWFrIG9mIFNpbXVsYXRvcnMsIEF2YXRhcnMs IFJlZ2lvbnMsIEFzc2V0cyBhbmQgc28gZm9ydGgsIGZvciB0aGUgbW9tZW50LCBJkm0gZ29pbmcg dG8ga2VlcCB0aG9zZSB0ZXJtcyBvZmYgdGhlIHRhYmxlIHRvIHRoaW5rIGFib3V0IHRoZSBwcm9i bGVtIGluIGl0cyBtb3JlIGdlbmVyYWwgZm9ybS4gDQ1Ob3RlIHRoYXQgSZJtIGFsc28gdmVyeSBj b25zY2lvdXNseSB0YWtpbmcgYSBtaW5pbWFsIGJhc2Ugd2l0aCBvcHRpb25hbCBmZWF0dXJlcyBh cHByb2FjaCB0byBkZXNjcmliaW5nIHRoZSBzcGFjZS4gVGhpcyBhbGxvd3MgdXMgdG8gZm9jdXMg b24gdGhlIGNvcmUgb3ZlcmxhcHBpbmcgZmVhdHVyZXMsIGFuZCB0aGVuIGEgc2V0IG9mIHNlcnZp Y2VzIHdoaWNoIGFkZCB0byB0aGlzIGNvcmUuIFRoaW5rIGFib3V0IGhvdyB0aGVzZSBnb2FscyBh bmQgc29sdXRpb25zIGNvdWxkIGJlIGFwcGxpZWQgdG8gY29sbGFib3JhdGl2ZSBzcGFjZXMgc3Vj aCBhcyBXaWtpcywgTWljcm8gYmxvZ2dpbmcgc3RyZWFtcyBhbmQgY29sbGFib3JhdGl2ZSBkZXNr dG9wIGFuZCBhcHBsaWNhdGlvbiBlbnZpcm9ubWVudHMuIA0NSW50ZXJvcGVyYWJpbGl0eSBpcyBu b3QgYWJvdXQgZGVmaW5pbmcgdGhlIG9uZSB0cnVlIHN5c3RlbSB3aGljaCBzYXRpc2ZpZXMgdGhl c2UgZ29hbHMuIEludGVyb3BlcmFiaWxpdHkgaXMgYWJvdXQgbWFraW5nIG11bHRpcGxlIGV4aXN0 aW5nIGltcGxlbWVudGF0aW9uIGludGVyb3BlcmF0ZSBieSB0aGUgdXNlIG9mIHN0YW5kYXJkcyB3 ZSBkZWZpbmUuIA1Hb2FsczogDQ1XaGF0IHNvcnQgb2YgaW50ZXJvcGVyYWJpbGl0eSBkbyB3ZSBk ZXNpcmUgb3V0IG9mIHRoZXNlIHNwYWNlcz8gDQ1JIHdpbGwgc3RhcnQgd2l0aCBzb21lIHN0YXRl bWVudHMgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgdXNlciBleHBlcmllbmNlLCBhbmQgdGhlbiB0 YWxrIGFib3V0IHRoZSB0ZWNobmljYWwgaW1wbGljYXRpb25zIG9mIHRoZXNlIHVzZSBjYXNlcy4g SSB3aWxsIGFsc28gc3RhcnQgd2l0aCB0aGUgYnJvYWRlc3QsIG1vc3QgZXhwYW5zaXZlIGdvYWxz IGFuZCB0aGVuIGxvb2sgYXQgaG93IHRvIGJyZWFrIHRoZXNlIGFwYXJ0IGludG8gYSBzZXJpZXMg b2Ygc3ViIGdvYWxzLiANDVRoZXNlIGdvYWxzIGFyZSBzdHJ1Y3R1cmVkIHdpdGggdGhlIGludGVu dCBvZiBsaXN0aW5nIGEgcmFuZ2Ugb2YgZXhwZXJpZW5jZXMgd2UgaG9wZSB0byBlbmFibGUuICBU aGVyZSBzb21ldGltZXMgc2VlbXMgdG8gYmUgYSBzdHJvbmcgZGVzaXJlIHRvIHRoaW5rIGFib3V0 IHRoZSB1bHRpbWF0ZSBlbmQgc3RhdGUsIHdoZXJlIHRoZXJlIGlzIG9uZSB1YmVyLWNsaWVudCwg YW5kIGV2ZXJ5IHNpbmdsZSB2aXJ0dWFsIHNwYWNlIGltcGxlbWVudHMgZXZlcnkgc2luZ2xlIGNh cGFiaWxpdHkgaW4gc3VwZXIgZ3JpZCBzcGFubmluZyB0aGUgd29ybGQuIEkgdGhpbmsgdGhhdCwg aXRzIGltcG9ydGFudCB0byB0aGluayBvZiBpbnRlcm9wZXJhYmlsaXR5IGFzIGhhcHBlbmluZyBv dmVyIHRpbWUsIGFuZCBpbiBjbHVzdGVycyBvZiBpbmNyZWFzaW5nbHkgaW50ZWdyYXRlZCBzZXJ2 aWNlcyBhbmQgc3BhY2VzLiBTb21lIGxvdyBoYW5naW5nIGZydWl0IHdpbGwgY29tZSBlYXJseS4g U29tZSB3b3JsZHMsIHdoaWNoIGFyZSBjbG9zZSBpbiBkZXNpZ24gd2lsbCBnZXQgZGVlcGVyIGJl bmVmaXRzIHNvb25lciwgb3RoZXJzIHdpbGwgb25seSBncmFkdWFsbHkgYmVjb21lIG1vcmUgdGln aHRseSBpbnRlZ3JhdGVkLiBUaGVyZSBhcmUgbWFueSBpbXBvcnRhbnQsIHVzZWZ1bCwgYW5kIGRl c2lyYWJsZSBzdGF0ZXMgYmV0d2VlbiCTbm90aGluZyBzaGFyZXOUIGFuZCCTSXRzIG9uZSBzaW5n bGUgbW9kZWwgb2YgZXZlcnl0aGluZy6UDQ1Ob3RlOiBUaGVzZSBnb2FscyBhcmUgbm90IHVzZSBj YXNlcy4gSWRlYWxseSwgZWFjaCBnb2FsIHdpbGwsIG92ZXIgdGltZSwgc3Bhd24gYSBzZXQgb2Yg dXNlIGNhc2VzIHRvIGhlbHAgZGVmaW5lIHRoZW0sIGFuZCAgYWRkaXRpb25hbGx5IHNvbWUgk2Ny b3NzIGdvYWyUIHVzZSBjYXNlcyB3aWxsIGJlIGdlbmVyYXRlZCB3aGljaCB3aWxsIHNob3cgaG93 IG11bHRpcGxlIGdvYWxzIHdvcmsgdG9nZXRoZXIgdG8gcHJvdmlkZSB2YWx1YWJsZSByZXN1bHRz LiANDQ0NVGhlIGFiaWxpdHkgdG8gbWFuYWdlIG9uZZJzIGlkZW50aXR5IHdoZW4gaW50ZXJhY3Rp bmcgaW4gbXVsdGlwbGUgTU1PWCBzcGFjZXMuIA1BbGxvd2luZyBwcmVzZW5jZSBpbmZvcm1hdGlv biB0byBiZSBzaGFyZWQgYW5kIGNvb3JkaW5hdGVkIGFjcm9zcyBNTU9YIHNwYWNlcw1QZXJtaXR0 aW5nIGZyaWVuZHMgbGlzdHMsIGFuZCBJTXMgdG8gYmUgc2hhcmVkIGFjcm9zcyBzcGFjZXMNUGVy bWl0dGluZyBNTU9YIHNwYWNlcyB0byBzaGFyZSBuYW1pbmcgDVNpbXBsZSB3YXlzIG9mIGFsbG93 aW5nIGEgY29uc2lzdGVudCBuYW1lLCBtYW5hZ2VkIGJ5IHRoZSB1c2VyLCBhbmQgdmVyaWZpYWJs ZSBieSBvdGhlciB1c2Vycw1TaW5nbGUgc2lnbiBvbiwgbWVkaWF0ZWQgYnkgbXVsdGlwbGUgc3Bh Y2VzLCB3aXRoaW4gdGhlIHBvbGljeSBjb25zdHJhaW50cyBvZiB0aGUgc3BhY2VzDUEgY29uc2lz dGVudCBhcHBlYXJhbmNlLCB3aXRoaW4gdGhlIGNvbnN0cmFpbnRzIG9mIHRoZSB2YXJpb3VzIHN5 c3RlbXMNVGhlIGFiaWxpdHkgdG8gbWFuYWdlIHRoZSBkZWdyZWUgb2YgdmlzaWJpbGl0eSAvIGNv dXBsaW5nIGJldHdlZW4gaWRlbnRpdGllcyBpbiBNTU9YIHNwYWNlcw0NIE5vdGUgdGhhdCBmb3Ig YWxsIG9mIHRoZXNlLCB0aGVyZSBpcyBubyByZXF1aXJlbWVudCB0byBjb3VwbGUgdGhlIHN5c3Rl bXMgdG9nZXRoZXIgYmV5b25kIG1hbmFnaW5nIGlkZW50aXR5LCBhbmQgc2hhcmUgcHJlc2VuY2Ug YW5kIElNIGluZm9ybWF0aW9uLiBUaGVzZSB1c2UgY2FzZXMgZG9uknQgc3BlYWsgdG8gaG93IHlv dSBtb3ZlIGJldHdlZW4gc3BhY2VzLiBZb3UgbWF5IGhhdmUgdG8gc2h1dGRvd24geW91ciBjbGll bnQgb24gb25lIHN5c3RlbSBhbmQgc3RhcnQgYW5vdGhlci4gVGhpcyBhbHNvIGlzIG5vdCBhIJNZ b3UgbXVzdCBlbmFibGUgdGhpc5QgdGhpcyBpcyB2ZXJ5IG11Y2ggYSCTTWFrZSBpdCBlYXN5IGZv ciBzcGFjZXMgd2hpY2ggd2FudCB0byBlbmFibGUgdGhpcyB0byBkbyBpdC6UIEFsc28sIG5vdGUg dGhhdCCTcHJlc2VuY2UgYW5kIG1lc3NhZ2luZ5Qgc3BlYWsgdG8gdXNlciBuZWVkcywgYW5kIGNv bnNpdGVudCBhcHBlYXJhbmNlIGFuZCBuYW1lICh3aGVuIGRlc2lyZWQgYnkgdXNlcnMpIGFnYWlu IHNwZWVrcyB0byBtZWV0aW5nIHVzZXKScyBkZXNpcmVzLiANVGhlIGFiaWxpdHkgZm9yIHRoZSBz ZXJ2aWNlcyBpbiBhbiBNTU9YIHdvcmxkIHRvIGJlIG5hbWVkLCBhbmQgYXV0aGVudGljYXRlZA1T ZXJ2aWNlcyB0byBhc3NvY2lhdGUgdmlydHVhbCBwbGFjZXMgYW5kIHRoZSBzZXJ2aWNlcyB3aGlj aCBzdXBwb3J0IHRoZW0gd2l0aCBhdXRoZW50aWNhdGlvbiBhbmQgYWRtaW5pc3RyYXRpdmUgZG9t YWlucw1TZXJ2aWNlcyB0byBwZXJtaXQgYSBzZXJ2aWNlIHRvIHZhbGlkYXRlIHRoZSBtZW1iZXJz aGlwIG9mIGEgcmVtb3RlIHNlcnZpY2UgaW4gb25lIG9yIG1vcmUgYXV0aGVudGljYXRpb24gYW5k IGFkbWluaXN0cmF0aXZlIGRvbWFpbnMNDVRoaXMgaXMgbmVlZGVkIHNvIHRoYXQgd2UgY2FuIGRv IGVzc2VudGlhbGx5IGFueSBvZiB0aGUgaW50ZXJvcGVyYWJpbGl0eSB3b3JrLiBXaXRob3V0IHNv bWUgZnJhbWV3b3JrIHdoaWNoIGxldHMgdXMga25vdyB3aG8gd2UgYXJlIHRhbGtpbmcgdG8sIGl0 IGlzIGltcG9zc2libGUgdG8gdHJ1c3QgdGhlIGJlaGF2aW9yIG9mIGRpc3RyaWJ1dGVkIHN5c3Rl bXMuIA0NVGhlIGFiaWxpdHkgdG8gc2hhcmUgY29udGVudCBiZXR3ZWVuIE1NT1ggc3BhY2VzDUlt cG9ydCBhbmQgRXhwb3J0IG9mIGNvbnRlbnQgYW5kIG1vZGVscyAoVGhpcyBtYXkgd2VsbCBsZXZl cmFnZSBvZmYgb2YgZXhpc3Rpbmcgd29yayBzdWNoIGFzIENvbGxhZGEpIFN0YXRpYywgaW1wb3J0 L2V4cG9ydCBvZiBjb250ZW50IHdoaWxlIG5vdCB0ZXJyaWJseSBkcmFtYXRpYyBpcyBhbiBpbXBv cnRhbnQgcGFydCBvZiB0aGUgdmFsdWUgY2hhaW4gb2YgaW50ZXJvcGVyYWJpbGl0eQ1NYXJrIHVw IHNjaGVtZXMgd2hpY2ggcmVjb2duaXplIHRoZSBleGlzdGVuY2Ugb2YgbXVsdGlwbGUgcHJlc2Vu dGF0aW9uIGVudmlyb25tZW50cywgYnV0IHBlcm1pdCB0aGUgc2hhcmluZyBvZiBjb250ZW50DVNo YXJlZCCTdHlwZZQgaW5mb3JtYXRpb24gZm9yIHRoZSB2YXJpb3VzIHR5cGVzIG9mIGdyYXBoaWNh bCBjb250ZW50IHdoaWNoIE1NT1ggc3BhY2VzIGNvbnRhaW4NRXh0ZW5zaWJsZSwgd2l0aCBhIGNv bW1vbiByZWdpc3RyeSwgc28gdGhhdCB3ZSBjYW4gdW5kZXJzdGFuZCB0aGUgdHlwZXMgb2YgY29u dGVudHMgYSBjbGllbnQgY2FuIGFjY2VwdCwgYW5kIGEgdmlydHVhbCBzcGFjZSwgb3IgdmlydHVh bCBhc3NldCBzdG9yZSBjYW4gYmUgYXNrZWQgdG8gcHJvdmlkZQ1BIE1NT1ggYmFzZWQsIHN5c3Rl bSBpbmRlcGVuZGVudCBhc3NldCBhZGRyZXNzaW5nIHNjaGVtZSB3aGljaCBpbmNsdWRlcw1Db250 ZW50IG5lZ290aWF0aW9uIGJhc2VkIG9uIDJiDUFjY2VzcyBNYW5hZ2VtZW50IGJhc2VkIG9uICgx KSBhbmQgKDIpDQ1UaGlzIGlzLCB0byBteSBtaW5kLCB0aGUga2V5IG1pZCB0ZXJtIGRlbGl2ZXJh YmxlIA0NVGhlIGFmZm9yZGFuY2VzIGluIE1NT1ggdG8gcGVybWl0IHRoZSBjcmVhdGlvbiBvZiBt aWNyby1wYXltZW50IGVjb25vbWllcw1BcHByb3ByaWF0ZSBzcG90cyBkZWZpbmVkIGluIE1NT1gg cHJvdG9jb2xzIGZvciBjb3N0IGluZm9ybWF0aW9uDUFwcHJvcHJpYXRlIHNwb3RzIGRlZmluZWQg aW4gTU1PWCBwcm90b2NvbHMgZm9yIHJlZmVyZW5jZSB0byBtaWNyb3BheW1lbnQgc3lzdGVtcw0N VGhlIGFiaWxpdHkgdG8gc2hhcmUgk25vbiBpbW1lcnNpdmUgc3RyZWFtc5QgYmV0d2VlbiBzcGFj ZXMgDU1hcmt1cCB0byBwZXJtaXQgdGhlIGNvbnNpc3RlbnQgc2hhcmluZyBvZiBzdHJlYW0gbWVk aWEgc3VjaCBhcyB2b2ljZSwgYW5kIHZpZGVvLCB3aXRoIHNoYXJlZCBzdGFydCBhbmQgc3luY2hy b25pemF0aW9uIGluZm9ybWF0aW9uIHRvIHBlcm1pdCCTcGFyYWxsZWyUIGV2ZW50cyBiZXR3ZWVu IE1NT1ggc3BhY2UNDVRoZSBhYmlsaXR5IHRvIGV4cHJlc3MgUG9saWN5IGludGVudCBiZXR3ZWVu IE1NT1ggc2VydmljZXMgYW5kIHZpcnR1YWwgc3BhY2VzDVBsYWNlcyBpbiByZXNlcnZlZCBpbiB0 aGUgTU9YIHByb3RvY29scyBmb3IgZXhwcmVzc2luZyBwb2xpY3kgaW50ZW50DU9uZSBvciBtb3Jl IHBvbGljeSBsYW5ndWFnZXMgZm9yIGV4cHJlc3NpbmcgcG9saWN5DQ0NVGhlIHNvbHV0aW9uIHNw YWNlOg0NTW9zdCBvZiB0aGUgZGVwbG95ZWQgc29sdXRpb25zIHBhcnRpdGlvbiB0aGUgc29mdHdh cmUgcHJvYmxlbSBpbnRvIHRoZSBmb2xsb3dpbmcgY2h1bmtzLg0NU29tZSBmb3JtIG9mIGEgY2xp ZW50IHdoaWNoIHBlcm1pdHMgYSB1c2VyIHRvIGludGVyYWN0IHdpdGggdGhlIHNoYXJlZCBleHBl cmllbmNlDVZpcnR1YWwgc3BhY2Ugc2VydmVycyB3aGljaCBtYW5hZ2UgdGhlIHN0YXRlIG9mIGEg cG9ydGlvbiBvZiB2aXJ0dWFsIHNwYWNlDUEgc2V0IG9mIHN1cHBvcnRpbmcgc2VydmljZXMgdXNl ZCBieSB0aGUgdmlydHVhbCBzcGFjZSBzZXJ2ZXJzIA0NTm90ZSB0aGF0IGV4YWN0bHkgaG93IHRo ZXNlIHRocmVlIGxhcmdlIGNodW5rcyBhcmUgYXNzZW1ibGVkIGFuZCB0aGUgZ3JhbnVsYXIgbmF0 dXJlIG9mIHRoZSBzZXJ2aWNlcyBjYW4gdmFyeSByYWRpY2FsbHksIGV2ZW4gd2hlbiBzZXJ2aW5n IHZlcnkgc2ltaWxhciBlbnZpcm9ubWVudHMuIFNvbWUgZW52aXJvbm1lbnRzIHB1c2ggYSBsYXJn ZSBhbW91bnQgb2YgcmVuZGVyaW5nIGFuZCBtYW5hZ2VtZW50IG9udG8gY29tcGxleCBjbGllbnRz LCBvdGhlcnMgcGVyZm9ybSB0aGUgYnVsayBvZiByZW5kZXJpbmcgaW4gdGhlIHNlcnZlciBwb3J0 aW9uIG9mIHRoZSBkZXBsb3ltZW50LiBTb21lIGltcGxlbWVudGF0aW9ucyBjb21iaW5lIGNsaWVu dCBhbmQgc2ltdWxhdGlvbiBpbnRvIGEgc2luZ2xlIGVudGl0eSB3aGljaCBkb2VzIHNvbWUgc2lt dWxhdGlvbiBhbmQgc29tZSB1c2VyIHByZXNlbnRhdGlvbi4gU29tZSBkaXN0cmlidXRlIHRoZSBz aW11bGF0aW9uLCBzb21lIGNlbnRyYWxpemUgaXQuIA0NVGhlIGhlYXJ0IG9mIG1vc3Qgb2YgdGhl IHNvbHV0aW9ucyBpcyBtYW5hZ2luZyB0byBhY2NlcHQgYW5kIG1lcmdlIGEgc3RyZWFtIG9mIHVw ZGF0ZXMsIGFuZCB0aGVuIGRpc3RyaWJ1dGUgdGhlIG1lcmdlZCB1cGRhdGVzIGJhY2sgdG8gdXNl cnMuIFRoaXMgY2FuIGhhcHBlbiBhdCBhIHJhbmdlIG9mIGdyYW51bGFyaXRpZXMuIFRoZSB0d28g ZW5kcyBvZiB0aGUgc3BlY3RydW0sIGFyZSwgcm91Z2hseSwgc2VuZGluZyB1cGRhdGVzIGFzIGEg ZnVsbHkgbWVyZ2VkIGF1ZGlvIHZpc3VhbCBzdHJlYW0sIHdoaWNoIHRoZSBjbGllbnQgbWVyZWx5 IGRpc3BsYXlzLCBhbmQgc2VuZGluZyBsb3cgbGV2ZWwgY2hhbmdlcyB0byBhIHVuZGVybHlpbmcg bW9kZSwgd2hpY2ggdGhlIGNsaWVudCB1c2VzIHRvIGFzc2VtYmxlIGEgY29tcGxldGUgdmlzdWFs IHJlcHJlc2VudGF0aW9uIG9mIHRoZSBzY2VuZS4gIFZhcmlhdGlvbnMgaW5jbHVkZSBjcm9xdWV0 IGFuZCBxd2FxIHdoaWNoIHVzZSBhbiB1bmRlcmx5aW5nIGRpc3RyaWJ1dGVkIG9iamVjdCBtb2Rl bCB0byBwYXNzIGxhcmdlIGFtb3VudHMgb2YgdXBkYXRlcywgYW5kIGFwcHJvYWNoZXMgc3VjaCBh cyB1c2VkIGJ5IFNlY29uZExpZmUgYW5kIFByb3RvbnNwaGVyZSwgd2hlcmUgdm9pY2UgaXMgbWFu YWdlZCBpbiBhIHNlcGFyYXRlIHNlcnZpY2UsIHdpdGggdGhlIG1lcmdlZCBzdGF0ZSBzZXJ2aWNl IG1lcmVseSBsZXR0aW5nIHRoZSB2b2ljZSBzZXJ2aWNlIGtub3cgd2hlcmUgdGhlIHVzZXJzIGFy ZSBsb2NhdGVkLiANDUNsb3NlbHkgcmVsYXRlZCwgYXJlIGlzc3VlcyBvZiByZXByZXNlbnRhdGlv biBhbmQgZm9ybWF0IG9mIGNvbnRlbnQuIFRoaXMgdGFrZXMgc2V2ZXJhbCwgc2VwYXJhYmxlIGZv cm1zLiBJbXBvcnQgYW5kIEV4cG9ydCBvZiBtYXRlcmlhbCB0byB0aGUgY29yZSBlbnZpcm9ubWVu dCwgYW5kLCBtb3JlIHByb2JsZW1hdGljYWxseSwgcnVuIHRpbWUgcmVwcmVzZW50YXRpb25zDQ1B cHByb2FjaA1PdXIgb3ZlcmFsbCBhcHByb2FjaCBzaG91bGQgYmUgd2ViIGNlbnRyaWMsIGFuZCB3 ZWIgc2VydmljZXMgb3JpZW50ZWQuIFdlIGNhbiwgYW5kIHNob3VsZCB0aGluayBvZiBzZXRzIG9m IHJlbGF0ZWQgc2VydmljZXMgd2hpY2ggY2FuIGJlIGNvbXBvc2VkIGFzIHBhcnQgb2YgZGlmZmVy ZW50IHNvbHV0aW9ucyB3aGljaCB3aWxsIGVuYWJsZSB2YXJ5aW5nIGRlZ3JlZXMgb2YgaW50ZXJv cGVyYWJpbGl0eS4gV2UgY2FuLCBhbmQgc2hvdWxkIGF0dGVtcHQgdG8gcHJvdmlkZSBhcyB3ZWIg bGlrZSBhbiBhcHByb2FjaCB0byBmdW5jdGlvbiBhcyBwb3NzaWJsZS4gQ29udGVudCBuZWdvdGlh dGlvbiwgc2VwYXJhdGlvbiBvZiBwcm90b2NvbCBmcm9tIHNlY3VyaXR5LCBzZXBhcmF0aW9uIG9m IGludGVyZmFjZSBmcm9tIGltcGxlbWVudGF0aW9uIGFuZCBvdGhlciB0ZWNobmlxdWVzLiANDU91 ciBnb2FsIGlzIG5vdCB0byBlbnNocmluZSBhbnkgc2luZ2xlIHZpcnR1YWwgd29ybGQgYXMgdGhl IHN0YW5kYXJkIGZvciBhbGwgTU1PWCBzcGFjZXMsIGJ1dCByYXRoZXIgY3JlYXRlIGEgZmxleGli bGUsIGV4dGVuc2libGUgc2V0IG9mIHNlcnZpY2VzIHdoaWNoIHdpbGwgYWxsb3cgdXMgdG8gZ3Jv dyBsYXJnZXIgYW5kIGxhcmdlIG92ZXJsYXBwaW5nIHNldHMgb2YgY2FwYWJpbGl0aWVzLiBNeSBl eHBlY3RhdGlvbiBpcyB0aGF0IHdlIHdpbGwgc2VlIGEgbG90IG9mIGxvdyBoYW5naW5nIGZydWl0 IGluIHRoZSBhcmVhIG9mIGlkZW50aXR5LCBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiBh bmQgcHJlc2VuY2UgbWFuYWdlbWVudCAoV2hlcmUgYSB1c2VyIGlzLCBhbmQgYWxsb3dpbmcgbWVz c2FnaW5nIHRvIHRoZW0gYWNyb3NzIE1NT1ggc3BhZWNlcykgYW5kIGluaXRpYWxseSwgd2Ugd2ls bCBmaW5kIGEgbG90IG9mIGZvcm1hdCBhbmQgY29udGVudCBhcmVhIGFkZHJlc3NlZCBieSBnYXRl d2F5cywgbWFya3VwLCBhbmQgY29udGVudCBuZWdvdGlhdGlvbi4gSSBzZWUgbm90aGluZyB3cm9u ZyB3aXRoIGhhdmluZyBhIFVSSSB3aGljaCByZWZlcnMgdG8gk0EgcHJldHR5IG1hcGxlIHRyZWUg d2l0aCBmYWxsIGNvbG9yc5Qgd2hpY2ggcHJvdmlkZXMgYSB3YXkgdG8gZmV0Y2ggdGhlIJNDb2xs YWRhIFN0eWxlIHZlcnNpb26UIHRoZSCTM2RNYXggTWVzaCB2ZXJzaW9ulCB0aGUgk0xpbmRlbiBM YWIgMS4yIHNjdWxwdHkgc3BlYyB2ZXJzaW9ulCAgc3VjaCB0aGF0IGEgdmlydHVhbCBzcGFjZSBj YW4gc2VsZWN0LCB0aHJvdWdoIGNvbnRlbnQgbmVnb3RpYXRpb24gdGhlIG9uZSBtb3N0IHVzZWZ1 bCB0byBpdC4gDQ1XZSBnZXQgdmFsdWUsIHdoZW4gd2UgaGF2ZSBjb25zaXN0ZW50IHdheXMgb2Yg cmVmZXJyaW5nIHRvIGFsbCB0aGUgdmFyaW91cyBmb3JtcyBvZiBjb250ZW50LCBhbmQgd2UgZ2V0 IG1vcmUgdmFsdWUgd2hlbiB3ZSBoYXZlIHdheXMgb2YgdXNpbmcgZXhpc3RpbmcgY29udGVudCBu ZWdvdGlhdGlvbiB0byBhbGxvdyBhIHdlYiBsaWdodCBzZWxlY3Rpb24gb2YgYW4gYXBwcm9wcmlh dGUgZm9ybS4gSXQgaXMgZXF1YWxseSBwb3NzaWJsZSB0byBpbWFnaW5lIG5lZ290aWF0aW5nIGJl dHdlZW4gYSBjbGllbnQgYW5kIGEgdmlydHVhbCBzcGFjZSwgdGhlIGRlc2lyZWQgZm9ybSBvZiBv YmplY3RzLiBUaGVyZSBhcmUgc29tZSBkZWVwIGNoYWxsZW5nZXMgbHVya2luZywgc3VjaCBhcyB3 aGVuIHR3byBkaWZmZXJlbnQgYXBwcm9hY2hlcyBoYXZlIHJhZGljYWxseSBkaWZmZXJlbnQgDQ1X aGF0IEkgd291bGQgZW5jb3VyYWdlIHVzLCBhcyBhIG1haWxpbmcgbGlzdCB0byBkbywgaXMgbG9v ayB0aHJvdWdoIHRoZSBwcm9ibGVtIHN0YXRlbWVudCwgYW5kIGludGVyb3BlcmFiaWxpdHkgZ29h bHMgSZJ2ZSBwdXQgdG9nZXRoZXIgaGVyZS4gVGhleSBhcmUgYW4gYXR0ZW1wdCB0byBjYXB0dXJl IHRoZSB2YXJpb3VzIHNlbnRpbWVudHMgaW4gdGhlIG9uZ29pbmcgZGlzY3Vzc2lvbi4gSSBhbSBz dXJlIEkgaGF2ZSBtaXNzZWQgcG9pbnRzLCBhbmQgSSBhbSBzdXJlIHNvbWUgcGVvcGxlIHdpbGwg ZGlzYWdyZWUgd2l0aCBzb21lIG9mIHRoZSBwb2ludHMgSSBoYXZlIG1hZGUuIA0NSSB3b3VsZCBh c2sgcGVvcGxlIHRvIGxvb2sgZm9yIJNObywgeW91IG1pc3NlZCBYlCBhbmQgk0hleSwgSSBkb26S dCB0aGluayBZlCBpcyB0cnVlLiBJIHdpbGwgYXR0ZW1wdCB0byBjYXB0dXJlIGFsbCBvZiB0aG9z ZSwgYW5kIHJldmlzZSB0aGUgZG9jdW1lbnQsIHVudGlsIHdlIHRoaW5rIGl0IHJlcHJlc2VudHMg c29tZXRoaW5nIGNsb3NlIHRvIHRoZSBnZW5lcmFsIGdyb3VwIGNvbnNlbnN1cy4gKEkgYW0gbm90 IGxvb2tpbmcgZm9yIDEwMCUgY29uc2Vuc3VzLCBidXQgYSCTWWVhaCwgdGhpcyBjYXB0dXJlcyBt b3N0IG9mIHdoYXQgd2WScmUgdHJ5aW5nIHRvIGRvLpQgV2l0aCB0aGF0IGluIGhhbmQsIEkgd291 bGQgc3VnZ2VzdCB3ZSBjb3VsZCB0aGVuIGJlZ2luIHRvIGVudW1lcmF0ZSB0aGUgc3BlY2lmaWMg c2VydmljZXMgYW5kIG1hcmt1cHMgd2UgbmVlZCB0byBzdXBwb3J0IG91ciBnb2FscywgYW5kIGJl Z2luIHRvIGZsZXNoIG91dCB1c2UgY2FzZXMgdG8gaGVscCB1cyB1bmRlcnN0YW5kIHRoZSBnb2Fs cyBhbmQgc2VydmljZXMuIA0NSSBkbyBub3QgZXhwZWN0IHRoaXMgdG8geWllbGQgYSBzZXQgb2Yg c3BlY3Mgd2hpY2ggTGluZGVuIExhYiwgb3IgT3BlblNpbSwgT3IgYW55IG9uZSB2aXJ0dWFsIHdv cmxkIHZlbmRvciBvciBwcm9qZWN0IHdvdWxkIGltcGxlbWVudCB3aG9sZS4gV2hhdCBJIGV4cGVj dCBpdCB0byB5aWVsZCBpcyBhIHNldCBvZiBzcGVjcywgd2hpY2ggY2FuIGJlIGNvbWJpbmVkIHdp dGggZXhpc3RpbmcgcHJvamVjdHMgYW5kIGNvZGUgYmFzZXMgdG8gZHJpdmUgdXMgdG93YXJkcyBh IG1vcmUgaW50ZXJvcGVyYWJsZSBmdXR1cmUuIA0NT3V0IG9mIHNjb3BlDQ1JIGFsc28gd2FudCB0 byBiZWdpbiB0byBhY2N1bXVsYXRlIGEgc2hvcnQgbGlzdCBvZiCTTm8sIHRoaXMgaXMgb3V0IG9m IHNjb3BllCBhc3NlcnRpb25zDQ1XZSB3aWxsIHByb3ZpZGUgYWxsIHRoZSBhZmZvcmRhbmNlcyBu ZWNlc3NhcnkgdG8gcGVybWl0IGEgYnJvYWQgcmFuZ2Ugb2YgaW50ZXJhY3Rpb24gcG9saWNpZXMu IEFwcHJvcHJpYXRlIHBvbGljaWVzIGZvciB2YXJpb3VzIGRlcGxveWVkIHNvbHV0aW9ucyBhbmQg ZnV0dXJlIGRlcGxveWVkIHNvbHV0aW9ucyBpcyBvdXQgb2Ygc2NvcGUsIGJleW9uZCBwcm92aWRp bmcgdXMgdXNlIGNhc2VzIHdoaWNoIGhpZ2hsaWdodCBzcGVjaWZpYyBhZmZvcmRhbmNlcyB3ZSBt YXkgd2lzaCB0byBjb25zaWRlcg1XaGV0aGVyIG9yIG5vdCBpbW1lcnNpdmUgbXVsdGktcGFydHkg c3BhY2VzIGFyZSB1c2VmdWwgYW5kIHdoaWNoIHNwZWNpZmljIGNhcGFiaWxpdGllcyBhcmUgcmVx dWlyZWQgaXMgb3V0IG9mIHNjb3BlLiBXZSBhc3BpcmUgdG8gc3VwcG9ydCBhIGJyb2FkIHJhbmdl IG9mIHBvc3NpYmxlIGNhcGFiaWxpdGllcywgYW5kIHdlIHJlc3BlY3QgdGhhdCBkaWZmZXJlbnQg b3JnYW5pemF0aW9ucyB3aWxsIGhhdmUgZGlmZmVyZW50IHBlcnNwZWN0aXZlcyBvbiB3aGF0IGlz IHJlcXVpcmVkLiBPdXIgZ29hbCBpcyB0byBkZWZpbmUgYnJvYWQsIGludGVyb3BlcmFibGUgZnJh bWV3b3JrcyB3aGljaCB3aWxsIGVuYWJsZSBhIHJhbmdlIG9mIGRlcGxveW1lbnRzLCBub3QgdG8g ZGVmaW5lIHRoZSBvbmUgdHJ1ZSBtb2RlbCBmb3IgdGhpcyBzcGFjZQ1Qcm9wb3NlIGFkZGl0aW9u YWwgc3RhdGVtZW50cyBoZXJlDUNsb3NpbmcgY29tbWVudHMNSSBkb26SdCB0aGluayBvdXIgY29s bGVjdGl2ZSBnb2FsIGNhbiBiZSB0byB0YWtlIGFueSBvbmUgZXhpc3Rpbmcgc3BlYyBvciBzb2x1 dGlvbiBhbmQgc2ltcGx5IGRlY2xhcmUgaXQgdGhlIGJhc2lzIGZvciBvdXIgd29yayBnb2luZyBm b3J3YXJkLiBBdCB0aGUgc2FtZSB0aW1lLCB3ZSBtdXN0IGJhc2Ugb3VyIHdvcmsgaW4gYWN0dWFs bHkgcnVubmluZyBjb2RlLCBzaG93aW5nIHJlYWwgaW50ZXJvcGVyYWJpbGl0eS4gT3VyIGdvYWwg bXVzdCBiZSB0byBidWlsZCBzdXBlcnNldHMgb2YgZnVuY3Rpb24sIGJhc2VkIG9uIGV4aXN0aW5n IHByb2R1Y3RzIGFuZCBzb2x1dGlvbnMgd2hpY2ggZGVtb25zdHJhdGUgcmVhbCBpbnRlcm9wZXJh YmlsaXR5LiANDVRoZSBJRVRGIGZhdm9ycyB3b3JraW5nIGNvZGUgYW5kIGdyb3dpbmcgY29uc2Vu c3VzIG92ZXIgYmxhbmsgcGFwZXIgYW5kIGJsdWUgc2t5IGVmZm9ydHMuIFRoaXMgaXMgYmFzZWQg aW4gYSBoaXN0b3J5IG9mIHN1Y2Nlc3MgYW5kIGZhaWx1cmUgaW4gdGhlIGluZHVzdHJ5IHdoZW4g aXQgY29tZXMgdG8gYnVpbGRpbmcsIHByb21vdGluZyBhbmQgc3VjY2VlZGluZyBhdCBzdGFuZGFy ZHMgd29yay4gV29yayBhdCB0aGUgSUVURiBpcyBncm91bmRlZCBpbiB3b3JraW5nIGNvZGUuIA0N T25lIHdheSBmb3J3YXJkIGlzIHRvIGZvY3VzIG9uIHNldmVyYWwgY2x1c3RlcnMgb2Ygd29yay4g T25lOiBhIGNsZWFyLCBicm9hZCBmcmFtZXdvcmssIHdoaWNoIGZvcm1zIHRoZSBiYXNpcyBmb3Ig bG9uZyB0ZXJtIGJyb2FkIGludGVyb3BlcmF0aW9uLiBUd286IENhcHR1cmluZyB0aGUgY3VycmVu dCBzZXQgb2YgaW5jb21wYXRpYmxlIGFuZCBvdmVybGFwcGluZyBmb3JtYXRzIGFuZCBwcm90b2Nv bHMgaW4gdXNlLCBzbyB0aGF0IHdlIGNhbiBjcmVhdGUgYSBleHRlbnNpYmxlIGFuZCBzaGFyZWQg Y2F0YWxvZyBvZiBhcnRpZmFjdHMgZm9yIHNoYXJpbmcuIChlZy4gk0hlcmUgaXMgdGhlIGNhbm9u aWNhbCwgZXh0ZW5zaWJsZSAgbGlzdCBvZiBncmFwaGljIGNvbnRlbnQgdHlwZXMgeW91IG1pZ2h0 IHdhbnQgdG8gbW92ZSBvbiBhIE1NT1ggdHJhbnNwb3J0lCBUaHJlZSBncm93IG91dCAgcHJvcG9z ZWQgc29sdXRpb25zIHN1Y2ggYXMgTExTRCwgT0dQLCBhbmQgb3RoZXJzLCBhcyB0aGV5IGFyZSBj b250cmlidXRlZCB0b3dhcmRzIGEgY29tbW9uIHN1cGVyc2V0IHdoaWNoIGNhbiBiZSB1c2VkIHRv IGFzIHRoZSBiYXNpcyBmb3IgZGVtb25zdHJhdGluZyBjb25jcmV0ZSBwcm9ncmVzcyB0b3dhcmRz IGludGVyb3AgZ29hbHMuIEZvdXIsIElkZW50aWZ5IHBsYWNlcyB3aGVyZSB3ZSBzaW1wbHkgd2Fu dCB0byB1c2UgZXhpc3Rpbmcgd29yaywgc3VjaCBhcyBPcGVuSUQsIE9BdXRoLCAgWC41MDkgIGFu ZCBjcmVhdGUgYSBzaGFyZWQgcHJvZmlsZSBmb3IgaG93IHdlIGNhbiB1c2UgdGhlc2UgcHJvdG9j b2xzIHRvIGZ1cnRoZXIgaW50ZXJvcGVyYWJpbGl0eS4gDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAXQgAAIoIAACOCAAAvwgAAMkIAADKCAAAywgAAO0IAAAq CQAAUgkAAFoJAADRCQAA0gkAAPcJAAD4CQAAGwoAABwKAAApCgAAKgoAADkKAABeCgAAegoAAIUK AADLCgAA9woAAD8LAABNCwAAVwsAAEMMAABEDAAAcwwAAHQMAACVDAAAlgwAAJgMAAApDQAAmw0A AJwNAACuDQAArw0AAKEOAADSDgAAPg8AAHUPAAB3DwAAiA8AAAIQAAAMEAAAdRAAAMIQAADjEAAA 9hAAAP8QAABUEQAAWBEAAHcRAACFEQAAkhEAAKQRAADJEQAAyhEAAMsRAABjEgAAZBIAAJ0SAACe EgAAnxIAALkSAADNEgAAABMAAPz49Pjw7Ojw6PDk6OTo8Pjg+OD44Pjg+OD43Pjc1NzUztTcyujc 9Pj04PTG9OD04PTgwuDC4MLgwvTgwr7gvrrGvraytrIAAAYWaL46jgAABhZowB1pAAAGFmi4czkA AAYWaAIVEwAABhZoHlVDAAAGFmhNXY4AAAYWaDo5HwAAChZolSZLADBKEwAADwNqAAAAABZolSZL AFUIAQYWaJUmSwAABhZoIzC/AAAGFmjUbKcAAAYWaAspugAABhZozWTXAAAGFmh9W4cAAAYWaLBC SwAABhZolASvAAAGFmjqb3oARgAGAADKCAAAywgAAO0IAAArCQAAUgkAANIJAAD3CQAA+AkAAFcL AABYCwAAnA0AAK8NAACwDQAAdg8AAHcPAAAhEQAAyhEAAMsRAACeEgAAnxIAALoSAADJEgAAABMA AJITAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA 9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAN8AAAAAAAAAAAAAAADfAAAAAAAA AAAAAAAA1wAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAKJgAL RgEAZ2S+Oo4ACAAACiYAC0YBAGdkwB1pAAAEAwBnZMAdaQAACAAAD4RoAV6EaAFnZH1bhwAIAAAK JgALRgsAZ2R9W4cAAAEAAAAYAAYAANZHAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAEBAABAQEAEwAAAhMAAGcTAACREwAAkhMAAJMTAACXEwAAoBMAAM8TAADREwAA KxQAAFQUAAAqFQAAQhUAAGoVAAC6FQAAqBYAALoXAAC7FwAAzhcAAJsYAABMGQAATRkAABkaAABi GgAAcxsAAGIeAABpHwAAax8AAGwfAACIHwAAvB8AAIggAABtIQAAyiEAAMshAAATIgAAFCIAAOAi AAD9IwAASCUAABkmAAAaJgAAKSYAAEomAABLJgAAKScAAConAAA8KQAAcSkAAD8rAABAKwAABiwA AAcsAAAILAAAHSwAAHUsAAB2LAAAkywAAMksAADKLAAAMS0AAFMtAABULQAA+y0AAFQvAABVLwAA GzEAAKUyAAD8+PT4/PT89Pzw/PTw/PT8+Oz08Ojk4OTw3OjY8NTQzNDIzMjMyMzoxOjQwNDowOjE 6MTo5Lns/Oz89LX8tfy19LX0sQAAAAAAAAAAAAAGFmhwfWkAAAYWaDRJJgAADBVosl1OABZosl1O AAAGFmhXc28AAAYWaCpNnQAABhZo2BC5AAAGFmjiNPgAAAYWaJlQQgAABhZonVeqAAAGFmgbHA8A AAYWaK0LbAAABhZoCym6AAAGFmiyXU4AAAYWaH1bhwAABhZoPUiKAAAGFmgeVUMAAAYWaE1djgAA BhZovjqOAAAGFmjAHWkARJITAACTEwAA0BMAANETAAArFAAAVBQAAKwUAADeFAAAKhUAALsVAADw FQAApxYAAKgWAAC6FwAAuxcAAE0ZAABOGQAAGRoAACEaAAAiGgAAYxoAAGQaAABzGwAAdBsAAGIe AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAA AAAAAAAAAAAAAPIAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA 3AAAAAAAAAAAAAAAANwAAAAAAAAAAAAAAADcAAAAAAAAAAAAAAAA3AAAAAAAAAAAAAAAANcAAAAA AAAAAAAAAADSAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAADSAAAAAAAAAAAA AAAA0gAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABnZLJdTgAABAMAZ2SyXU4A AAQAAGdkvjqOAAAIAAAPhGgBXoRoAWdkwB1pAAgAAAomAAtGAQBnZE1djgAIAAAKJgALRgEAZ2S+ Oo4AAAQAAGdkwB1pAAAYYh4AAGMeAABpHwAAah8AAGsfAABsHwAAvB8AAAogAABHIAAAbyAAAM0g AAAmIQAAbSEAAMkhAADKIQAA/iMAAEskAADDJAAASCUAAEklAAAZJgAAGiYAAEsmAAAqJwAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAADyAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA 6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOUAAAAA AAAAAAAAAADgAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAANgAAAAAAAAAAAAAAADYAAAAAAAAAAAA AAAA0wAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADOAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAMYA AAAAAAAAAAAAAAAACAAACiYBC0YEAGdkV3NvAAAEAABnZJ1XqgAABA8AZ2QqTZ0ACAAACiYBC0YE AGdkfVuHAAAEDwBnZH1bhwAABAAAZ2TYELkACAAACiYBC0YEAGdkmVBCAAgAAAomAAtGBABnZJlQ QgAABAAAZ2SyXU4AABcqJwAAoScAAAAoAACtKAAA9SgAABUpAAA8KQAAPSkAAHApAABxKQAAuykA APwpAABOKgAATyoAAIwqAAA/KwAAQCsAAI4rAADTKwAABiwAAAcsAAAILAAAHCwAAB0sAAD3AAAA AAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA7wAAAAAAAAAA AAAAAO8AAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADa AAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA2gAAAAAA AAAAAAAAAOcAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAAOcAAAAAAAAAAAAA AADnAAAAAAAAAAAAAAAA0AAAAAAAAAAAAAAAANAAAAAAAAAAAAAAAADLAAAAAAAAAAAAAAAAxgAA AAAAAAAAAAAAAAAABAAAZ2S+Oo4AAAQDAGdkwB1pAAAEAABnZLJdTgAABAAAZ2R9W4cACAAACiYA C0YEAGdkfVuHAAAEDwBnZCpNnQAIAAAKJgELRgQAZ2R9W4cACAAACiYCC0YEAGdkfVuHAAgAAAom AQtGBABnZFdzbwAAFx0sAAB2LAAAdywAAMksAAAULQAAVC0AAFUtAABVLwAAVi8AAF8yAABgMgAA NTMAADYzAAA/MwAA/DQAAP00AABgOAAAYTgAABw6AAAdOgAAajsAAGs7AACGPQAAhz0AAK8+AACw PgAAvT4AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAA AADyAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAA AAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAOgAAAAAAAAA AAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA 7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAA AAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADjAAAAAAAAAAAA AAAAAAAAAAAAAAAABAMAZ2SVJksAAAQDAGdkpDsDAAAEAABnZDRJJgAIAAAKJgALRgIAZ2TAHWkA AAQAAGdkvjqOAAAapTIAADQzAAA1MwAAsDMAAP00AABfOAAAYDgAAEM5AAAbOgAAHDoAAK8+AADW PwAA7T8AAP4/AAAHQAAACEAAAB1AAAA0QAAANUAAAPxBAAANQgAAU0IAAGBCAACuQgAAgEMAAIFD AACCQwAAk0QAAJZEAACtRAAAvEQAACdFAADxRQAA+0UAANRHAADVRwAA1kcAAPz49PDs/Ozo7Ojk 4OTg5ODc5ODY1NDU0NTQ1MzU3NTc0NzUxQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAwVaJ1XqgAWaNRspwAABhZoKk2dAAAGFmgLKboAAAYWaKBEZwAABhZonVeqAAAGFmjU bKcAAAYWaKEmiAAABhZolSZLAAAGFmiLHp0AAAYWaLJmRQAABhZorQtsAAAGFmikOwMAAAYWaHB9 aQAABhZo/mFYACS9PgAAvj4AABc/AAAYPwAANUAAANlBAAD8QQAADUIAAIFDAACCQwAAlEQAAJVE AADVRwAA1kcAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAADqAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAA 4AAAAAAAAAAAAAAAAOAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAA4AAAAAAAAAAAAAAAAOAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAGdknVeqAAAEAwBnZJ1XqgAIAAAKJgALRhAAZ2TUbKcACAAACiYAC0YQAGdklSZLAAAE AABnZJUmSwAADSwAMZBoAR+w0C8gsOA9IbAIByKwCAcjkKAFJJCgBSWwAAAXsNACGLDQAgyQ0AIA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAhgIUABIAAQCcAA8ABAAAAAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAQPH/AgBAAAwAAAAAAAAAAAAGAE4AbwBy AG0AYQBsAAAAAgAAABgAQ0oYAF9IAQRhShgAbUgJBHNICQR0SAkEAAAAAFYAA0ABAAIAVgAMBAAA wB1pAAAACQBIAGUAYQBkAGkAbgBnACAAMwAAABAAAwAGJAETpPAAFKQ8AEAmAhoANQiBQ0oaAE9K AgBRSgIAXAiBXkoCAGFKGgAAAAAAAAAAAAAAAABEAEFA8v+hAEQADAEAAAAAAAAAABYARABlAGYA YQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAUgBpAPP/swBSAAwBAAAA AAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTWBgABCgNsADTWBgABBQMA AGH2AwAAAgALAAAAKABrQPT/wQAoAAABAAAAAAAAAAAHAE4AbwAgAEwAaQBzAHQAAAACAAAAAAAA AEYARUABAPIARgAMBAAA2BC5AAAADwBMAGkAcwB0ACAAQwBvAG4AdABpAG4AdQBlACAAMgAAAA4A DwAPhNACFKR4AF6E0AIAAEYARkABAAIBRgAMBAAAfVuHAAAADwBMAGkAcwB0ACAAQwBvAG4AdABp AG4AdQBlACAAMwAAAA4AEAAPhDgEFKR4AF6EOAQAAEYASEABABIBRgAMBAAAfVuHAAAADwBMAGkA cwB0ACAAQwBvAG4AdABpAG4AdQBlACAANQAAAA4AEQAPhAgHFKR4AF6ECAcAAEgAmQABACIBSAAM BQAApDsDAAAADABCAGEAbABsAG8AbwBuACAAVABlAHgAdAAAAAIAEgAUAENKEABPSgMAUUoDAF5K AwBhShAANABVQKIAMQE0AAwAAACVJksAAAAJAEgAeQBwAGUAcgBsAGkAbgBrAAAACQA+KgFwaAAA /wAAAAAAANY/AAAHAABcAAAAAP////8AAAAAygAAAMsAAADtAAAAKwEAAFIBAADSAQAA9wEAAPgB AABXAwAAWAMAAJwFAACvBQAAsAUAAHYHAAB3BwAAIQkAAMoJAADLCQAAngoAAJ8KAAC6CgAAyQoA AAALAACSCwAAkwsAANALAADRCwAAKwwAAFQMAACsDAAA3gwAACoNAAC7DQAA8A0AAKcOAACoDgAA ug8AALsPAABNEQAAThEAABkSAAAhEgAAIhIAAGMSAABkEgAAcxMAAHQTAABiFgAAYxYAAGkXAABq FwAAaxcAAGwXAAC8FwAAChgAAEcYAABvGAAAzRgAACYZAABtGQAAyRkAAMoZAAD+GwAASxwAAMMc AABIHQAASR0AABkeAAAaHgAASx4AACofAAChHwAAACAAAK0gAAD1IAAAFSEAADwhAAA9IQAAcCEA AHEhAAC7IQAA/CEAAE4iAABPIgAAjCIAAD8jAABAIwAAjiMAANMjAAAGJAAAByQAAAgkAAAcJAAA HSQAAHYkAAB3JAAAySQAABQlAABUJQAAVSUAAFUnAABWJwAAXyoAAGAqAAA1KwAANisAAD8rAAD8 LAAA/SwAAGAwAABhMAAAHDIAAB0yAABqMwAAazMAAIY1AACHNQAArzYAALA2AAC9NgAAvjYAABc3 AAAYNwAANTgAANk5AAD8OQAADToAAIE7AACCOwAAlDwAAJU8AADVPwAA2D8AAJgAAAAAMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAALIAAwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgACyAAMAEAAAAAAACAAAAAgAAAAAAAAAAAAACYAAsgADACAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAALIAAwAwAAAAAAAIAAAACAAAAAAAAAAAAAAJgACyAAMAQAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAKAAAAAMwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAnAUA AAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgJwFAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAICcBQAA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAnAUAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgJwFAAAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAICcBQAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAnAUAAAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgJwFAAAAAAAAAAAAAAAAmAABIAAwAAAAAAAAAICcBQAAAAAA AAAAAAAAAJgAASAAMAEAAAAAAACAnAUAAAAAAAAAAAAAAACYAAEgADACAAAAAAAAgJwFAAAAAAAA AAAAAAAAmAABIAAwAwAAAAAAAICcBQAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAnAUAAAAAAAAA AAAAAACYAAAAADAAAAAAAAAAgJwFAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAICcBQAAAAAAAAAA AACAAJgAASAAMAQAAAAAAACAnAUAAAAAAAAAAAAAAACYAAEgADAFAAAAAAAAgJwFAAAAAAAAAAAA AIAAmAABIAAwBgAAAAAAAICcBQAAAAAAAAAAAACAAJgAASAAMAcAAAAAAACAnAUAAAAAAAAAAAAA gACYAAEgADAIAAAAAAAAgJwFAAAAAAAAAAAAAIAAmAABIAAwCQAAAAAAAICcBQAAAAAAAAAAAACA AJgAASAAMAoAAAAAAACAnAUAAAAAAAAAAAAAgACYAAEgADALAAAAAAAAgJwFAAAAAAAAAAAAAIAA mAAAAAAwAAAAAAAAAICcBQAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAnAUAAAAAAAAAAAAAgACY AAAAADAAAAAAAAAAgJwFAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAICcBQAAAAAAAAAAAACAAJgA AAAAMAAAAAAAAACAnAUAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgJwFAAAAAAAAAAAAAAAAKAAA AAMwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAGRIAAAAAAAAAAAAAgACYAAAA ADAAAAAAAAAAgBkSAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAZEgAAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACAGRIAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgBkSAAAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAZEgAAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAGRIAAAAAAAAAAAAAgACYAAAAADAA AAAAAAAAgBkSAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIAZEgAAAAAAAAAAAACAAJgAAAAAMAAA AAAAAACAGRIAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgBkSAAAAAAAAAAAAAIAAmAAEIAAwAAAA AAAAAIAZEgAAAAAAAAAAAACAAJgBBCAAMAAAAABsFwAAGRIAAAAAAAAAAAAAAACYAQQgADABAAAA bBcAABkSAAAAAAAAAAAAAAAAmAEEIAAwAgAAAGwXAAAZEgAAAAAAAAAAAAAAAJgBBCAAMAMAAABs FwAAGRIAAAAAAAAAAAAAAACYAQQgADAEAAAAbBcAABkSAAAAAAAAAAAAAIAAmAEEIAAwBQAAAGwX AAAZEgAAAAAAAAAAAACAAJgBBCAAMAYAAABsFwAAGRIAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAA gBkSAAAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAZEgAAAAAAAAAAAAAAAJgABCAAMAEAAAAAAACA GRIAAAAAAAAAAAAAgACYAQQgADAAAAAA/hsAABkSAAAAAAAAAAAAAIAAmAEEIAAwAQAAAP4bAAAZ EgAAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAGRIAAAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgBkS AAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAZEgAAAAAAAAAAAAAAAJgABCAAMAIAAAAAAACAGRIA AAAAAAAAAAAAgACYAQQgADAAAAAAGh4AABkSAAAAAAAAAAAAAIAAmAEEIAAwAQAAABoeAAAZEgAA AAAAAAAAAACAAJgCBCAAMAAAAAAqHwAAGRIAAAAAAAAAAAAAgACYAgQgADABAAAAKh8AABkSAAAA AAAAAAAAAIAAmAEEIAAwAgAAABoeAAAZEgAAAAAAAAAAAACAAJgCBCAAMAAAAACtIAAAGRIAAAAA AAAAAAAAAACYAgQgADABAAAArSAAABkSAAAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAZEgAAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAGRIAAAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgBkSAAAAAAAA AAAAAAAAmAAEIAAwAwAAAAAAAIAZEgAAAAAAAAAAAAAAAJgBBCAAMAAAAABxIQAAGRIAAAAAAAAA AAAAAACYAQQgADABAAAAcSEAABkSAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAZEgAAAAAAAAAA AAAAAJgABCAAMAQAAAAAAACAGRIAAAAAAAAAAAAAAACYAQQgADAAAAAATyIAABkSAAAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAZEgAAAAAAAAAAAAAAAJgABCAAMAUAAAAAAACAGRIAAAAAAAAAAAAA AACYAQQgADAAAAAAQCMAABkSAAAAAAAAAAAAAAAAmAEEIAAwAQAAAEAjAAAZEgAAAAAAAAAAAACA AJgAAAAAMAAAAAAAAACAGRIAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgBkSAAAAAAAAAAAAAIAA KAAAAAMwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACACCQAAAAAAAAAAAAAAACY AAAAADAAAAAAAAAAgAgkAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAIJAAAAAAAAAAAAAAAAJgA AiAAMAAAAAAAAACACCQAAAAAAAAAAAAAgACYAAIgADABAAAAAAAAgAgkAAAAAAAAAAAAAIAAmAAC IAAwAgAAAAAAAIAIJAAAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACACCQAAAAAAAAAAAAAgACYAAAA ADAAAAAAAAAAgAgkAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAIJAAAAAAAAAAAAAAAAJgAAAAA MAAAAAAAAACACCQAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAgkAAAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAIJAAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACACCQAAAAAAAAAAAAAAAAoAAAAAzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIA2KwAAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACANisAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgDYrAAAAAAAAAAAAAAAAmAAAAAAwAAAA AAAAAIA2KwAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACANisAAAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgDYrAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIA2KwAAAAAAAAAAAAAAAJgAAAAAMAAAAAAA AACANisAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgDYrAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIA2KwAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACANisAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAA gDYrAAAAAAAAAAAAAAAAKAAAAAMwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA sDYAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgLA2AAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAICw NgAAAAAAAAAAAAAAAJgAECAAMAAAAAAAAACAsDYAAAAAAAAAAAAAgACYABAgADABAAAAAAAAgLA2 AAAAAAAAAAAAAIAAmAAQIAAwAgAAAAAAAICwNgAAAAAAAAAAAACAACgAAAADMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAAAAAAA+AEAAFcDAABYAwAA2D8AAFqRADAAMAAAAAAAAAEAAAAEAAAAAQAAAAwZEAcT AKACAjAAABAAAAYCAAAAEQAAAAAAAAAAAAAHWJEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAAAAAVqR ADAAMAAAAAAAAAEAAAAAAAAAAAAAAPgEHgcABgAAABMAAKUyAADWRwAAJAAAACcAAAAsAAAAAAYA AJITAABiHgAAKicAAB0sAAC9PgAA1kcAACUAAAAoAAAAKQAAACoAAAArAAAALQAAAAAGAADWRwAA JgAAAEMEAABzBAAAlQQAANY/AAATWBT/FYwPAADwOAAAAAAABvAYAAAAAggAAAIAAAABAAAAAQAA AAEAAAACAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAAAQQA AA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAA DwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/ AwEAAQAAABHwBAAAAAEAAAAAAAAAtQEAALgBAAC6AgAAwgIAAMkFAADTBQAA2wUAAOYFAADuBQAA 9AUAACkHAAAzBwAAKgkAADEJAAAzCQAAPwkAAE0JAABXCQAAwAkAAMcJAAAjDQAAKQ0AADsUAAA/ FAAAKBgAACsYAACfGwAAqBsAANsbAADhGwAAqB4AAK8eAAA7KQAAPykAALIpAAC8KQAAwSkAAM0p AACpLgAAsC4AAKcvAACuLwAA6y8AAPIvAADVPQAA1z0AAAk/AAAQPwAAYT8AAGc/AABpPwAAbj8A ANg/AAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAAAAA ADcHAABCBwAAGwgAACEIAAAzDwAAOQ8AANkRAADnEQAAuhQAAL0UAABKJgAAUiYAALcoAAC4KAAA fiwAAPosAADSNQAA1DUAAJo9AACbPQAA1T0AANc9AABuPwAAdj8AANg/AAAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAAAAACcBQAAsAUAAGQKAADJCgAA ZwsAAJMLAAAZEgAAIhIAAPUgAAAVIQAACCQAAB0kAAAgJwAAVCcAALA2AAC+NgAA2TkAAA06AADY PwAABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAFAAcABQAHAAUABwAAAAAA2D8AAAcAEAB8//// dJ0SB/8P/w//D/8P/w//D/8P/w//DwEAff///8Zz7Jb/D/8P/w//D/8P/w//D/8P/w8BAH7///9I H4bb/w//D/8P/w//D/8P/w//D/8PAQB/////gu/mqP8P/w//D/8P/w//D/8P/w//DwEAgP///xwe Zp7/D/8P/w//D/8P/w//D/8P/w8BAIH////+6kLg/w//D/8P/w//D/8P/w//D/8PAQCC////MCcU zf8P/w//D/8P/w//D/8P/w//DwEAg////yZ4yGD/D/8P/w//D/8P/w//D/8P/w8BAIj///8ygNis /w//D/8P/w//D/8P/w//D/8PAQCJ////2hxy7v8P/w//D/8P/w//D/8P/w//DwEAHRX1Df65jjf/ D/8P/w//D/8P/w//D/8P/w8QABI1zEaOCdpN/w//D/8P/w//D/8P/w//D/8PEABODXBc5Em0R/8P /w//D/8P/w//D/8P/w//DxAACTD1cEajjiT/D/8P/w//D/8P/w//D/8P/w8QAB8nmHGksJIz/w// D/8P/w//D/8P/w//D/8PEAApWul7aFhkRf8P/w//D/8P/w//D/8P/w//DxAAAQAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+ECAcRhJj+FcYFAAEIBwZehAgHYISY/gIAAAAuAAEAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAAALgABAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAGAAAD4Q4BBGEmP4VxgUAATgEBl6EOARghJj+AgAAAC4AAQAAAAAAAQAA AAAAAAAAAAAAAAAAAAAAABgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/gIAAAAuAAEAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAAsYAAAPhAgHEYSY/hXGBQABCAcGXoQIB2CEmP5PSgEAUUoBAG8oAAEA t/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oB AFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EOAQRhJj+FcYFAAE4BAZe hDgEYISY/k9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhNACEYSY /hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAA GAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+AgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA CxgAAA+EaAERhJj+FcYFAAFoAQZehGgBYISY/k9KAQBRSgEAbygAAQC38AEAAAAAEAEAAAAAAAAA AABoAQAAAAAAAAoYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP6HaAAAAACISAAAAgAAAC4AAQAA AASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhI AAACAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhg hEz/h2gAAAAAiEgAAAIAAgAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhEALEYSY/hXG BQABQAsGXoRAC2CEmP6HaAAAAACISAAAAgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgA AA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAApIBAAAAAAAAAAAA aAEAAAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgAAAIABQAuAAEAAAAA kAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP6HaAAAAACISAAA AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY /odoAAAAAIhIAAACAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RQGRGETP8VxgUA AVAZBl6EUBlghEz/h2gAAAAAiEgAAAIACAAuAAEAAAAAEAEAAAAAAAAAAABoAQAAAAAAAAoYAAAP hNACEYSY/hXGBQAB0AIGXoTQAmCEmP6HaAAAAACISAAAAgAAAC4AAQAAAAQQAQAAAAAAAAAAAGgB AAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAACAAEALgABAAAAAhIB AAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/h2gAAAAAiEgAAAIA AgAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP6H aAAAAACISAAAAgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EEA4RhJj+FcYFAAEQ DgZehBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4Tg EBGETP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgAAAIABQAuAAEAAAAAkAEAAAAAAAAAAABoAQAA AAAAAAoYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP6HaAAAAACISAAAAgAGAC4AAQAAAASQAQAA AAAAAAAAAGgBAAAAAAAAChgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/odoAAAAAIhIAAACAAcA LgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gA AAAAiEgAAAIACAAuAAEAAAAAEAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhNACEYSY/hXGBQAB0AIG XoTQAmCEmP6HaAAAAACISAAAAgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EoAUR hJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAACAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAA AAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/h2gAAAAAiEgAAAIAAgAuAAEAAAAAkAEAAAAA AAAAAABoAQAAAAAAAAoYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP6HaAAAAACISAAAAgADAC4A AQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAA AIhIAAACAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E 4BBghEz/h2gAAAAAiEgAAAIABQAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhLATEYSY /hXGBQABsBMGXoSwE2CEmP6HaAAAAACISAAAAgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAA ChgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/odoAAAAAIhIAAACAAcALgABAAAAApIBAAAAAAAA AAAAaAEAAAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gAAAAAiEgAAAIACAAuAAEA AAAAEAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP6HaAAAAACI SAAAAgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAF YISY/odoAAAAAIhIAAACAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RwCBGETP8V xgUAAXAIBl6EcAhghEz/h2gAAAAAiEgAAAIAAgAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoY AAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP6HaAAAAACISAAAAgADAC4AAQAAAASQAQAAAAAAAAAA AGgBAAAAAAAAChgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAAAIhIAAACAAQALgABAAAA ApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgA AAIABQAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CE mP6HaAAAAACISAAAAgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EgBYRhJj+FcYF AAGAFgZehIAWYISY/odoAAAAAIhIAAACAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAA D4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gAAAAAiEgAAAIACAAuAAEAAAAAEAEAAAAAAAAAAABo AQAAAAAAAAoYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP6HaAAAAACISAAAAgAAAC4AAQAAAASQ AQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAAC AAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/ h2gAAAAAiEgAAAIAAgAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhEALEYSY/hXGBQAB QAsGXoRAC2CEmP6HaAAAAACISAAAAgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+E EA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAApIBAAAAAAAAAAAAaAEA AAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgAAAIABQAuAAEAAAAAkAEA AAAAAAAAAABoAQAAAAAAAAoYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP6HaAAAAACISAAAAgAG AC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/odo AAAAAIhIAAACAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZ Bl6EUBlghEz/h2gAAAAAiEgAAAIACAAuAAEAAAAAEAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhNAC EYSY/hXGBQAB0AIGXoTQAmCEmP6HaAAAAACISAAAAgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAA AAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAAAIhIAAACAAEALgABAAAAApIBAAAA AAAAAAAAaAEAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/h2gAAAAAiEgAAAIAAgAu AAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP6HaAAA AACISAAAAgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EEA4RhJj+FcYFAAEQDgZe hBAOYISY/odoAAAAAIhIAAACAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4TgEBGE TP8VxgUAAeAQBl6E4BBghEz/h2gAAAAAiEgAAAIABQAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAA AAoYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP6HaAAAAACISAAAAgAGAC4AAQAAAASQAQAAAAAA AAAAAGgBAAAAAAAAChgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/odoAAAAAIhIAAACAAcALgAB AAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gAAAAA iEgAAAIACAAuABAAAAAfJ5hxAAAAAAAAAAAAAAAAHRX1DQAAAAAAAAAAAAAAAAkw9XAAAAAAAAAA AAAAAAASNcxGAAAAAAAAAAAAAAAAif///wAAAAAAAAAAAAAAAIP///8AAAAAAAAAAAAAAACC//// AAAAAAAAAAAAAAAAgf///wAAAAAAAAAAAAAAAID///8AAAAAAAAAAAAAAACI////AAAAAAAAAAAA AAAATg1wXAAAAAAAAAAAAAAAAH////8AAAAAAAAAAAAAAAB+////AAAAAAAAAAAAAAAAff///wAA AAAAAAAAAAAAAHz///8AAAAAAAAAAAAAAAApWul7AAAAAAAAAAAAAAAA//////////////////// ////////////////////////////////////////////////////////////////////EAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS AA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIADwAJBBkACQQbAAkEDwAJBBkA CQQbAAkEDwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQS AA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIADwAJBBkACQQbAAkEDwAJBBkA CQQbAAkEDwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQt AAAABAAAAAgAAADlAAAAAAAAACwAAACkOwMAGxwPAAIVEwA6OR8AnlUfADRJJgC4czkAbwdAAJlQ QgD0KkMAHlVDALJmRQAueUkAlSZLALBCSwBiDk4Asl1OAP5hWAAXHmAAoERnAMAdaQBwfWkArQts AFdzbwDqb3oAfVuHAKEmiAA9SIoAvjqOAE1djgCLHp0AKk2dANRspwCdV6oAlASvANgQuQALKboA IzC/ABQU1ADNZNcADTrpAKNT9AC7L/gA4jT4AGRj/wD/QAOAAQDVPwAA1T8AANAuxQMBAAAA1T8A AAAAAADVPwAAAAAAAAIQAAAAAAAAANY/AABwAAAQAEAAAP//AQAAAAcAVQBuAGsAbgBvAHcAbgD/ /wEACAAAAAAAAAAAAAAA//8BAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAEAAAARxaQAQAA AgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIA bwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAA ADUmkAEAAAILBgQDBQQEAgSHegBhAAAAgAgAAAAAAAAA/wEBAAAAAABUAGEAaABvAG0AYQAAACIA BABxCIgYAPDQAgAAaAEAAAAApsLSRqbC0kaau9ImAgAFAAAAhwkAAE82AAABACAAAAAEAAMQcwAA AIcJAABPNgAAAQAgAAAAcwAAAAAAAAAhAwDwEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI B6AFtAC0AIGBMjQAAAAAAAAAAAAAAAAAALY/AAC2PwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAUyg1EA8BAACAAD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS1AAAAAAKfD/DwEACB8AAOQEAAD///9/////f/// /3////9/////f////3////9/6m96AAAAAAAyAAAAAAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAiABU AGgAZQByAGUAIABoAGEAcwAgAGIAZQBlAG4AIABhACAAZgBhAGkAcgAgAGIAaQB0ACAAbwBmACAA ZABpAHMAYwB1AHMAcwBpAG8AbgAgAG8AbgAgAHQAaABlACAATQBNAE8AWAAgAG0AYQBpAGwAaQBu AGcAIABsAGkAcwB0ACwAIABhAG4AZAAgAGkAbgAgAGMAYQBzAHUAYQBsACAAZABpAHMAYwB1AHMA cwBpAG8AbgBzACAAYQBiAG8AdQB0ACAAdwBoAGEAdAAgAHcAZQAgAGEAcgBlACAAYQBjAHQAdQBh AGwAbAB5ACAAdAByAHkAaQBuAGcAIAB0AG8AIABhAGMAaABpAGUAdgBlAAAAAAAAAA4ARABhAHYA aQBkACAAVwAgAEwAZQB2AGkAbgBlAA4ARABhAHYAaQBkACAAVwAgAEwAZQB2AGkAbgBlAAAAAAAA AAAAAAAAAAAAAAAAAAAATAAAAAYAAAAQAAAAAAAMAAEADAACAAwAAwAMAAQADAAFAAwABgAMAAcA DAAIAAwACQAMAAoADAALAAwADAAMAA0ADAAOAAwADwAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAA AAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAGAIAABIAAAABAAAAmAAAAAIAAACgAAAAAwAA ADQBAAAEAAAAQAEAAAUAAABYAQAABgAAAGQBAAAHAAAAcAEAAAgAAACEAQAACQAAAJwBAAASAAAA qAEAAAoAAADIAQAACwAAANQBAAAMAAAA4AEAAA0AAADsAQAADgAAAPgBAAAPAAAAAAIAABAAAAAI AgAAEwAAABACAAACAAAA5AQAAB4AAACMAAAAVGhlcmUgaGFzIGJlZW4gYSBmYWlyIGJpdCBvZiBk aXNjdXNzaW9uIG9uIHRoZSBNTU9YIG1haWxpbmcgbGlzdCwgYW5kIGluIGNhc3VhbCBkaXNjdXNz aW9ucyBhYm91dCB3aGF0IHdlIGFyZSBhY3R1YWxseSB0cnlpbmcgdG8gYWNoaWV2ZQAAAAAeAAAA BAAAAAAAAAAeAAAAEAAAAERhdmlkIFcgTGV2aW5lAAAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAe AAAADAAAAE5vcm1hbC5kb3QAAB4AAAAQAAAARGF2aWQgVyBMZXZpbmUAAB4AAAAEAAAAMgAAAB4A AAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAABe0LIAAAAAQAAAAADU9I7slckBQAAA AAA8dN+VlskBQAAAAAA8dN+VlskBAwAAAAEAAAADAAAAhwkAAAMAAABPNgAAAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIA AAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a60AQAAcAEAAAwAAAABAAAAaAAA AA8AAABwAAAABQAAAHwAAAAGAAAAhAAAABEAAACMAAAAFwAAAJQAAAALAAAAnAAAABAAAACkAAAA EwAAAKwAAAAWAAAAtAAAAA0AAAC8AAAADAAAAFEBAAACAAAA5AQAAB4AAAAEAAAASUJNAAMAAABz AAAAAwAAACAAAAADAAAAtj8AAAMAAAAPJwsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAA AAAeEAAAAQAAAIkAAABUaGVyZSBoYXMgYmVlbiBhIGZhaXIgYml0IG9mIGRpc2N1c3Npb24gb24g dGhlIE1NT1ggbWFpbGluZyBsaXN0LCBhbmQgaW4gY2FzdWFsIGRpc2N1c3Npb25zIGFib3V0IHdo YXQgd2UgYXJlIGFjdHVhbGx5IHRyeWluZyB0byBhY2hpZXZlAAwQAAACAAAAHgAAAAYAAABUaXRs ZQADAAAAAQAAAADEAAAAAwAAAAAAAAAgAAAAAQAAADgAAAACAAAAQAAAAAEAAAACAAAADAAAAF9Q SURfSExJTktTAAIAAADkBAAAQQAAAHwAAAAGAAAAAwAAAAAAQwADAAAAAAAAAAMAAAAAAAAAAwAA AAUAAAAfAAAAIgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAdABmAC4AbwByAGcALwBOAE8A VABFAFcARQBMAEwALgBoAHQAbQBsAAAAHwAAAAEAAAAAAH8GAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkA AAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAA ABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAA JgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAA/v///zAAAAAxAAAAMgAAADMAAAA0 AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIA AABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAA/v///0sAAABMAAAATQAAAE4AAABPAAAAUAAA AFEAAAD+////UwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAP7////9////XAAAAP7////+//// /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAA AAAARgAAAAAAAAAAAAAAACBFbwGWlskBXgAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgH/////BQAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvAAAAiTUAAAAAAABXAG8AcgBk AEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA GgACAQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAu XAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAASgAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP////////////// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYfAAAATWljcm9z b2Z0IE9mZmljZSBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQu OAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA --=_mixed 0058541F85257567_=-- From infinity@lindenlab.com Tue Feb 24 08:07:47 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8A1128B23E for ; Tue, 24 Feb 2009 08:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HMJO9tsAYPT for ; Tue, 24 Feb 2009 08:07:46 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id C6AF73A6934 for ; Tue, 24 Feb 2009 08:07:46 -0800 (PST) Received: from [192.168.1.10] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id A98E43DBC44D for ; Tue, 24 Feb 2009 08:08:05 -0800 (PST) Message-Id: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> From: Meadhbh Hamrick (Infinity) To: mmox@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 08:08:04 -0800 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 16:07:47 -0000 so... what started as a pleasant little proposal to take our (the awg's) pleasant little protocol (ogp) kick it around in public (the mmox mailing list) and potentially generate some RFCs from it seems to have spawned a number of discussions. _all_ of the discussions are interesting, but perhaps not all of them are germane to the proposed task. so i ask.. is it appropriate to limit the discussion here to the MMOX Charter, LLSD, OGP and HyperGrid with occasional reference to the IETF IPR Disclosure Policy? to be sure... we _are_ in the stage where the charter is important to discuss... but i'm just wondering... and these questions are here to spark _conversation_, not radical debate. there are rational answers, pro and con, to each of these questions and teasing them out is important... * why would we care about HLA, DIS or IEEE-1278? they're already standardized. (though understanding that the structure of something like OGP differs from the structure of these protocols _is_ important.) * why do we care about OLIVE, which is a proprietary protocol with a single implementation? * why do we care about MXP whose apparent dependence on another protocol with unclear IPR encumbrance gives some people on this list the willies. so the questions i pose are... * pursuit of which of these topics brings us to our goal of an interoperable virtual worlds? * what does it mean to be interoperable? * must we have early agreement on all topics before we move forward with any component? * OGP (Open Grid Protocol) * should OGP be named something else? * how do we do the event queue? (COMET? Bayeux? RHTTP? Long Poll?) * where do we stuff permissions in this model? * OGP/Teleport is not HyperGrid * LLSD * why is LLSD different from XDR? ASN.1? Google ProtocolBuffers? * 128 bit integers? good enough? * should LLSD be named something else? * XML serialization * maps are too much like apple plists in the XML serialization. * MMOX Charter * we should rename everything * we should abandon interoperability in favor of general agreement of model * IETF * Virtual Worlds in General * Previously Established Protocols * HLA, DIS, IEEE-1278 and related protocols * OLIVE * MXP? * VRML * Representation of virtual objects * meshes vs. prims * interaction models for virtual objects * Intellectual Property Regimes for Virtual Worlds * Creative Commons (awesome gateway to free culture or the ultimate embodiment of evil in the noosphere?) * DRM (the only way i'll trust you with my content or the ultimate embodiment of evil in the noosphere?) * permissions regime * MPEG-21? * must we mandate the SL-style c/m/t permission? From cathypfeffer@gmail.com Tue Feb 24 09:01:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5391C3A6977 for ; Tue, 24 Feb 2009 09:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxf0YrOFJzeW for ; Tue, 24 Feb 2009 09:01:16 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id 8DC2E3A6B3E for ; Tue, 24 Feb 2009 09:01:11 -0800 (PST) Received: by ewy8 with SMTP id 8so340710ewy.13 for ; Tue, 24 Feb 2009 09:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=YPyXB5A16naEU5luBDyhaKsc7wJz/EVkU5kYmfEkUxY=; b=pZOYg7V2Xn6+h3g+TDLbR8wuegOfBhKDbPUR0/N2pDOsu/d3nxjIvyvNBNNo5T7wus kaBlTZgVnTrOyoGdXJM+rys0lNczTU2g3lHc1uEuo8KSsiNtzE2l4F+lVH0GUvHGYD+2 ddTlXeJzzeQ3T1AcgyS1g1sB53ECAEvM3vojY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=T8MtTUuCRpPfVfbX84NWNjjjKUjc8zNko1XNKjFAR2uEsRUcXwUhTmoNbJpT2ySa6P MpKq+UivBDPQCttKIXSlRB8Zeu5ClckhAhJQh7Dp0YCHAhyt96VD5SLc36PsxjP070Np xSEzKRrcpFwhyEPVGXtZvGFr5NpH4Z5NLdlE8= MIME-Version: 1.0 Received: by 10.210.125.13 with SMTP id x13mr4965ebc.18.1235494889810; Tue, 24 Feb 2009 09:01:29 -0800 (PST) Date: Tue, 24 Feb 2009 18:01:29 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c3f5c076ac90463ad12ed Subject: [mmox] Compact Binary Serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:01:17 -0000 --0015174c3f5c076ac90463ad12ed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > There needs to be support for a binary serialization that does not > contain embedded type or key references, but instead use explicit > external schema. Thus, to describe a "quaternion" you would simply > specify four fp16 (or fp32) values in sequence, with no specific type > information. This can extend to describing general entity property > values: the type information can be carried by the schema for the > entity, and does not need to be encoded in the actual data. Allowing > external schema leads to significant bandwidth savings during transmission. Wow, this one is violent! OK, let's examine it in detail: 1) Example of the quaternion. As I understand it, a quaternion is currently implemented as: 0.5 -0.5 0.5 0.5 (in the order x, y, z, s and not math's order s, x, y, z, that's one of Second Life's strangenesses) bandwidth could be spared with something like: 0.5,-0.5,0.5,0.5 (If you ask me why this is enclosed within tags while we could remove these tags without losing any information, I think the answer is: "because it leads to a cleaner C++ code to access the data in that way". Correct me if I'm wrong here, Infinity) Such a functioning could spare bandwith (57 bytes versus 87 bytes for this quaternion), while still remaining compatible with the other serializations (but not in a 1:1 straightforward compatible way as they are now). There could even be more bandwidth spared with constructs like: 0.5,-0.5,0.5,0.5 because you don't really need to specify in the data that there are four floats, it's obvious from the number of commas. That would be 47 bytes versus 87, including the useless tags. Nearly the half. 2) Moving the type information to the schema. Yes, that's the "ordinary way" of encoding data in XML. Ordinary way: XML schema or DTD says: we have the avatar's nose orientation quaternion here. That's four fp32. XML data over the wire: 0.5,-0.5,0.5,0.5 LLSD (simplifying): LLIDL says: nose orientation is an array of four fp32s LLSD data over the wire: 0.5,-0.5,0.5,0.5 (Example of nose orientation might be idiotic, I had no time to choose it better.) (I have used and not 4 s because that was boring to type) **** Jon, you are touching something at the very core of LLSD here. **** Where ordinary XML markup would say "this is nose orientation", XML serialization of LLSD says "this is four floats". While such choices seem weird in an XML file, they make a lot of sense for binary serialization where the data type of the following data can be specified in a single byte: "the next sequence of four bytes is going to be a floating point number". It would be impossible to declare "now there is going to be the nose's orientation. For the number of bytes involved, look at the schema" in a binary file using a simple byte. That does not mean it is impossible to put semantics in the binary file sent over the wire, but you have to do it with maps, i.e. with the binary serialization equivalent of: nose-orientation 0.5,-0.5,0.5,0.5 Have I summed up correctly the whole reasoning behind that, Infinity? Compare the bandwidth difference with: 0.5,-0.5,0.5,0.5 No need to comment on that. I see this as another example of "Yeah, that's strange XML, but it maps 1:1 to a nice and natural binary serialization" :-(. Now back to your question: "should we move the type information to the schema, as all people do in XML?". The answer is probably: "no, because we want to keep a simple 1:1 mapping with the binary serialization". Now, could we do partial exceptions for common types like vectors or quaternions? Perharps. I already suggested: 127,255,127 100.0,75.3,28.6 0.5,-0.5,0.5,0.5 but it could also take other forms with more semantics like 127,255,127 100.0,75.3,28.6 0.5,-0.5,0.5,0.5 although I see the second solution as harder to fit in the existing LLIDL, which works at a lower level of semantics. (I intentionally did not store the colour in a vector, because that's another SL-ism). I hope that helps. -- Cathy --0015174c3f5c076ac90463ad12ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > There needs to be support for a binary serialization that does not > contain embedded type or key references, but instead use explicit > external schema. Thus, to describe a "quaternion" you would= simply
> specify four fp16 (or fp32) values in sequence, with no specific type =
> information. This can extend to describing general entity property=
> values: the type information can be carried by the schema for the=
> entity, and does not need to be encoded in the actual data. Allowing <= br>> external schema leads to significant bandwidth savings during trans= mission.

Wow, this one is violent!

OK, let's examine it i= n detail:

1) Example of the quaternion.

As I understand it, = a quaternion is currently implemented as:
=C2=A0=C2=A0 <array>
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <float>0.5</float>= =C2=A0 <!-- x -->
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <f= loat>-0.5</float>=C2=A0 <!-- y -->
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <float>0.5</float>= =C2=A0 <!-- z -->
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <float>0.5</float>= =C2=A0 <!-- s -->
=C2=A0=C2=A0 </array>

(in the order= x, y, z, s and not math's order s, x, y, z, that's one of Second L= ife's strangenesses)

bandwidth could be spared with something li= ke:

=C2=A0=C2=A0 <array>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <float repeat=3D"4"= >0.5,-0.5,0.5,0.5</float>=C2=A0 <!-- x, y, z, s -->
=C2= =A0=C2=A0 </array>

(If you ask me why this is enclosed within <array> tags while we = could remove these tags without losing any information, I think the answer = is: "because it leads to a cleaner C++ code to access the data in that= way". Correct me if I'm wrong here, Infinity)

Such a functioning could spare bandwith (57 bytes versus 87 bytes for t= his quaternion), while still remaining compatible with the other serializat= ions (but not in a 1:1 straightforward compatible way as they are now).

There could even be more bandwidth spared with constructs like:
=C2= =A0=C2=A0 <array>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <floats>0.5,-0.5,0.5,0.5&l= t;/float>=C2=A0 <!-- x, y, z, s -->
=C2=A0=C2=A0 </array>

because you don't really need to specify in the data that there are= four floats, it's obvious from the number of commas. That would be 47 = bytes versus 87, including the useless <array> tags. Nearly the half.=


2) Moving the type information to the schema.

Yes, that'= s the "ordinary way" of encoding data in XML.

Ordinary way= :
=C2=A0=C2=A0=C2=A0=C2=A0 XML schema or DTD says: we have the avatar= 9;s nose orientation quaternion here. That's four fp32.
=C2=A0=C2=A0=C2=A0=C2=A0 XML data over the wire: <nose-orientation>0.= 5,-0.5,0.5,0.5</nose-orientation>

LLSD (simplifying):
=C2= =A0 =C2=A0=C2=A0 LLIDL says: nose orientation is an array of four fp32s
= =C2=A0=C2=A0=C2=A0=C2=A0 LLSD data over the wire: <floats>0.5,-0.5,0.= 5,0.5</floats>

(Example of nose orientation might be idiotic, I had no time to choose = it better.)
(I have used <floats> and not 4 <float>s because= that was boring to type)

**** Jon, you are touching something at th= e very core of LLSD here. ****

Where ordinary XML markup would say "this is nose orientation"= ;, XML serialization of LLSD says "this is four floats".

W= hile such choices seem weird in an XML file, they make a lot of sense for b= inary serialization where the data type of the following data can be specif= ied in a single byte: "the next sequence of four bytes is going to be = a floating point number". It would be impossible to declare "now = there is going to be the nose's orientation. For the number of bytes in= volved, look at the schema" in a binary file using a simple byte.

That does not mean it is impossible to put semantics in the binary file= sent over the wire, but you have to do it with maps, i.e. with the binary = serialization equivalent of:
=C2=A0 <map>
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 <key>nose-orientation</key>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <array>
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <floats>0.5,-0.5,0.5,0.5</floats= >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </array>
=C2=A0=C2=A0= </map>

Have I summed up correctly the whole reasoning behind = that, Infinity?

Compare the bandwidth difference with:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <nose-orientation>0.5,-0.5,0.5,0.5<= /nose-orientation>
No need to comment on that.

I see this as a= nother example of "Yeah, that's strange XML, but it maps 1:1 to a = nice and natural binary serialization" :-(.

Now back to your question: "should we move the type information to= the schema, as all people do in XML?". The answer is probably: "= no, because we want to keep a simple 1:1 mapping with the binary serializat= ion".

Now, could we do partial exceptions for common types like vectors or qu= aternions? Perharps. I already suggested:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 <integers>127,255,127</integers>
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <floats>100.0,75.3,28.6<= ;/floats>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <floats>0.5,-0.5,0.5= ,0.5</floats>

but it could also take other forms with more sem= antics like
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <colour&= gt;127,255,127</colour>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 <vector>100.0,75.3,28.6</vector>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <quat>0.5,-0.5,0.5,0= .5</quat>

although I see the second solution as harder to fit = in the existing LLIDL, which works at a lower level of semantics.

(I= intentionally did not store the colour in a vector, because that's ano= ther SL-ism).


I hope that helps.

--
Cathy
--0015174c3f5c076ac90463ad12ed-- From infinity@lindenlab.com Tue Feb 24 09:13:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9669C3A6B28 for ; Tue, 24 Feb 2009 09:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.211 X-Spam-Level: X-Spam-Status: No, score=-3.211 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpyDm6yeE4la for ; Tue, 24 Feb 2009 09:13:12 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id E16D93A6A2C for ; Tue, 24 Feb 2009 09:13:12 -0800 (PST) Received: from [192.168.1.10] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id B0A233DBC44C; Tue, 24 Feb 2009 09:13:31 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Christian Scholz In-Reply-To: <49A40ADA.2080309@comlounge.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 09:13:30 -0800 References: <49A40ADA.2080309@comlounge.net> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] xxSD working group? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:13:14 -0000 1. can you please submit your proposal? 2. yes, LLSD is used extensively in the currently deployed viewer and server. here are a few references to code: https://svn.secondlife.com/svn/linden/branches/2008/Branch_1-20-Viewer/indra/llcommon/llsd.cpp (the linden C++ implementation) https://svn.secondlife.com/svn/linden/branches/2008/Branch_1-20-Viewer/indra/llcommon/llsd.h (the linden C++ interface) http://svn.secondlife.com/trac/linden/browser/release/indra/lib/python/indra/base/llsd.py?rev=170&format=txt (the linden python implementation) http://www.openmetaverse.org/svn/libsl/libopenmetaverse/tags/0.3.2.2/libsecondlife/LLSD/XmlLLSD.cs (libsecondlife's XML LLSD serialization file) what you're seeing that looks like binary encoding is actually our "gMessage system" (aka "that pile of UDP packets we don't want to get standardized cause the last thing the internet needs is another half implemented version of TFTP.) most of the XML LLSD is sent over HTTPS, which might explain why you can't see it in wireshark. (yes, it irritates me too... but then again, it's not too hard to run wireshark as root, have it open /dev/mem, walk the process space, find the OpenSSL variables, tease out the private (or session) key and decrypt the SSL. if you try that, i think you'll see a lot more XML.) and the XML serialized LLSD that is not going over HTTPS is generally sent compressed, so again, if you're not uncompressing it before you look at it, you won't see angle-brackets. 3. the charter of this list is rather constrained... it is to attempt to standardize a protocol that is in wide use (for some definition of the term "wide".) it has yet been altered to be "think about a general architecture for virtual worlds." don't get me wrong, this is a very good idea (thinking about general architectures and so forth.) but you might have a MUCH better audience with the VWR and MPEG-V. 4. normal programmers understand LLSD, abstraction, and separating the internal representation of a data structure from it's serialization. do a google search for "rpc", "xml-rpc", "iiop", "dbus" and "marshalling". 5. namespace support for LLSD XML serialization isn't what i would call "a big win," but i can imagine a use where someone might want to extend the LLSD XML serialization DTD / schema to include additional information like ("don't ever let this serialized blob out of example.com's domain" or "if this blob goes out of this domain, please apply this XSLT stylesheet to it first.") For us at LL, these aren't "big wins," but i brought it up cause if there's a strong need for it, we could add an "improved" XML serialization to the list of serialization techniques, and i would undergo the ritual vegetable pelting that Linden employees subject themselves to when they volunteer other groups to support their "crazy" ideas. 6. the reason we separate the serialization from the protocol definition is we want to avoid having to add "binary serialization", "json serialization" and "xml serialization" sections to each defined protocol interaction. LLSD serialization was conceived as a way to avoid that. i think there's a history of people defining protocols using relatively "high level" abstractions, then providing mechanistic technique for generating the "octets over the wire." ASN.1 / BER encoding is an example, *shudder* CORBA / IIOP is another (though i'm definitely not recommending either for use here.) so... to recap... if you define your protocol interactions in a "high level" abstraction like LLSD/LLIDL, then have a separate section that says "how to convert LLSD blobs into {binary | json | xml} octets over the wire", you don't have to keep repeating yourself in each and every section. this limits the size of the spec, and may actually lead to fewer errors if you believe in murphy's law. it also makes the interaction more understandable, IMHO, because you're dealing with an appropriate level of abstraction. honestly, i could care less about XML when i'm thinking about application layer interaction. 7. i really like the idea of using LLSD to represent meshes, link-sets of prims, or even 2d SVG representations of avatars and objects. On Feb 24, 2009, at 6:57 AM, Christian Scholz wrote: > Catherine Pfeffer wrote: >> Infinity wrote: >>> Catherine... Jon... >>> >>> can you create a proposal for a next generation XML serialization? >> >> Yes I can. >> >>> the existing serialization is in current use by SL, OpenSim and >>> PyOGP, >> >> Really? I am surprised to hear that, because I had once the >> curiosity to >> run Wireshark to sniff packets exchanged by my Second Life client >> with >> the simulators, and I saw that the binary serialization was used >> all the >> time, even when using the new capacities system. Could you please >> point >> me to a situation where I could test the existing XML serialization? >> >>> so there's probably going to be a lot of resistance to changing >>> something that currently works and is deployed. >> >> Infinity, we need to make once for all clear whether this is just a >> Linden Lab existing technologies rubber stamping work group, or if we >> are designing vendor independent protocols for the 3 dimensional >> web of >> the future. >> >> While I agree there is no reason to throw away existing stuff (like >> LLSD's simplicity) when it is cool, I think that every bit of the >> technology should be evaluated, and replaced when it has conceptual >> flaws in it. > > I also wonder if we not first should think about a general > architecture > and then check all the fields if we can use existing formats or not > and > if not, what the requirements are our inventions need to fulfil. > >> If you disagree with this position, please state it clearly, and I >> would >> be happy to withdraw from this mailing list and to go to other >> projects >> where I might be more useful. Similarly, if Linden Lab's position is >> "let them speak and then enforce our own stuff at the end", please >> also >> spare my time. >> >>> keep in mind, however, that OGP does not use XML to represent it's >>> PDUs, it uses LLSD. XML is one of three defined serializations of >>> LLSD. it's a subtle difference, but important. >> >> I have it in mind, even though the rationale for using three >> different >> serializations is far from being clear to me. > > I also wonder how much the "normal" programmer will understand this. > Most likely they will skip the LLSD step and directly output the XML > or > parse that. It might not be good but if this thing gets widespread it > will certainly happen. > >>> for instance... is there a benefit to explicitly adding support for >>> namespaces to the XML serialization? >> >> That's a very good question. What would be the purposes of such >> namespaces? > > I wonder this, too. Especially if this is just a serialization layer. > What do you do with namespaces if you deserialize to LLSD? What > happens > to them if you then serialize again into a different format? > > Maybe some XML representation is really all which is needed. One might > also look at OpenSocial where they have two formats, ATOM and JSON and > rules for translating one to the other. Maybe even ATOM is usable as a > base here. > > Also remember that adding new concepts/terms/names to something will > make it more difficulty to understand. If it's just XML or JSON or > whatever is in use already, it's easier to understand and it might get > more adoption. > >>> there was a bit of discussion >>> about this amongst some AWG members, and the consensus was... "why >>> bother? the XML (presentation layer) is not the place where you want >>> to extend the PDU... you want to extend it in the LLSD / LLIDL >>> definition of the interaction." >> >> Makes sense. >> >> But this reasoning apparently assumes that the namespaces would be >> used >> to extend the interoperability standard. >> >> Normally, namespaces are rather used to mix data from different >> standards. > > Well, I know a lot of places where it's used to add additional > attributes etc. > >> That could be *very useful* if we want to mix LLSD for example with a >> mesh description expressed in another standard. Or to be able to >> include >> SVG graphics. Etc. While this would be very powerful, that would not >> scale back to the two other serializations, because it's pure XML >> mechanisms. > > Right. But you might say that such a mesh is stored in one field (tag > then) and you can simply copy the whole XML part over to this field in > e.g. a JSON structure. But that might be somewhat messy ;-) > > But actually I really would first think about a more global approach > towards a general architecture and then defined the more details > protocols and formats needed. > > -- 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 cs@comlounge.net > 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) > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From cathypfeffer@gmail.com Tue Feb 24 09:19:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBE93A6A2C for ; Tue, 24 Feb 2009 09:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdYDx6ShvvY9 for ; Tue, 24 Feb 2009 09:19:55 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id 923863A69F2 for ; Tue, 24 Feb 2009 09:19:54 -0800 (PST) Received: by ewy8 with SMTP id 8so349200ewy.13 for ; Tue, 24 Feb 2009 09:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Efl+ycVAbKhZzPhyQBwPjEN3D6QIOUlrIRxGVJtiwlI=; b=nAqFm5/cJtEB9gD4PX1q3fxjth9LSZiOg2XSf/4akWO/raeENdlRzP/Oxt6tbeXe9X SA3MMbwzDnhPH2wamP8wXs7paV54Q3//UyIbzwHnqteCk8nI4Fc7oUM9XTCKe807TVsQ QOyTOVdK6Bb08zLBxAnC4VcxiT76IUFt9CXtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZHDpcItnO8dUqzDMBTKoW0wZYoXf8DSTjLGcpc0k2QyajBvrs6dbb2Voh3T4MzYQ8G nr6Tb15pfEy78gGRl6sxoJQ9Db3JaNzfrjpJBGjOBSd5abMbhr1f1PY4CHrRkyh0yYsi EIkJOdIZl+1RmSCoBtHxxrxLXVj1Ml3tSZXI0= MIME-Version: 1.0 Received: by 10.210.34.19 with SMTP id h19mr26121ebh.132.1235496013035; Tue, 24 Feb 2009 09:20:13 -0800 (PST) Date: Tue, 24 Feb 2009 18:20:13 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c3d16fa77e40463ad546e Subject: [mmox] LLIDL or schemas? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:19:55 -0000 --0015174c3d16fa77e40463ad546e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Jon said: > I propose that the data structure > definition language be moved to some XML schema. Yes, LLIDL makes no sense in the XML world, where there are schemas (or DTDs) for that. That's another example of technical compromise needed by this "three serializations" scheme. My suggestion would be: "do only one serialization, but do it well"... - If XML has an angle bracket tax that is too expensive to pay, especially on limited capability devices, then let's stick to a binary format only. - If XML is the way to go because it's more flexible, human-readable, and because there's already a bunch of tools for it, then go for it only, but do it using all the possibilities of the XML technology. My opinion is that doing an 1:1 transposition of a binary format is just like automatically translating French into English word per word, it gives bad (although sometimes really funny) results. Anyhow, who is asking for a choice between three serializations? Is there a use case for that? Don't take it bad, Infinity. I'm just trying to put my engineering knowledge at the service of realistic and long-term decisions, not to destroy Linden Lab's vision of the future. -- Cathy --0015174c3d16fa77e40463ad546e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jon said:
> I propose that the data structure
> definition lan= guage be moved to some XML schema.

Yes, LLIDL makes no sense in the = XML world, where there are schemas (or DTDs) for that.
That's another example of technical compromise needed by this "thr= ee serializations" scheme.

My suggestion would be: "do onl= y one serialization, but do it well"...
=C2=A0- If XML has an angle= bracket tax that is too expensive to pay, especially on limited capability= devices, then let's stick to a binary format only.
=C2=A0- If XML is the way to go because it's more flexible, human-reada= ble, and because there's already a bunch of tools for it, then go for i= t only, but do it using all the possibilities of the XML technology.
My opinion is that doing an 1:1 transposition of a binary format is just li= ke automatically translating French into English word per word, it gives ba= d (although sometimes really funny) results.

Anyhow, who is asking f= or a choice between three serializations? Is there a use case for that?

Don't take it bad, Infinity. I'm just trying to put my engineer= ing knowledge at the service of realistic and long-term decisions, not to d= estroy Linden Lab's vision of the future.

--
Cathy
--0015174c3d16fa77e40463ad546e-- From infinity@lindenlab.com Tue Feb 24 09:29:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A76113A6971 for ; Tue, 24 Feb 2009 09:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRcguXzt-ug4 for ; Tue, 24 Feb 2009 09:29:36 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id D71DF3A6874 for ; Tue, 24 Feb 2009 09:29:36 -0800 (PST) Received: from [192.168.1.10] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 46A913DBC44D; Tue, 24 Feb 2009 09:29:56 -0800 (PST) Message-Id: <10448809-5E0B-4862-8A05-658B372C1D76@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Catherine Pfeffer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 09:29:55 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] LLIDL or schemas? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:29:37 -0000 hmm.. that's an idea.. we could move the binary and JSON serializations to a separate, informational RFC. honestly... we (Linden) would love to not have to support JSON, but the input we got from peeps doing web 2.0-ish stuff is that JSON was preferred to XML, which is why it's in the draft. translating from LLSD to an XML serialization is NOT the equivalent of translating from English to French. Human languages tend to have MUCH more ambiguity and are MUCH more subject to context. I would point out that if translating from LLSD to XML is hard, and subject to error, then certainly translating from a C data structure to XML is also hard and subject to error. both processes consume a well defined "atom" of data and produce another well defined "atom" of data in a different format. the use case for the JSON and Binary serializations are in the draft. feedback we received from the AWG was that the XML format was too encumbering for messages that should be processed quickly. the use case for the JSON serialization comes from the people whose product / project consumes data from a LLSD data source and uses it in an AJAX context. On Feb 24, 2009, at 9:20 AM, Catherine Pfeffer wrote: > Jon said: > > I propose that the data structure > > definition language be moved to some XML schema. > > Yes, LLIDL makes no sense in the XML world, where there are schemas > (or DTDs) for that. > > That's another example of technical compromise needed by this "three > serializations" scheme. > > My suggestion would be: "do only one serialization, but do it well"... > - If XML has an angle bracket tax that is too expensive to pay, > especially on limited capability devices, then let's stick to a > binary format only. > - If XML is the way to go because it's more flexible, human- > readable, and because there's already a bunch of tools for it, then > go for it only, but do it using all the possibilities of the XML > technology. > > My opinion is that doing an 1:1 transposition of a binary format is > just like automatically translating French into English word per > word, it gives bad (although sometimes really funny) results. > > Anyhow, who is asking for a choice between three serializations? Is > there a use case for that? > > Don't take it bad, Infinity. I'm just trying to put my engineering > knowledge at the service of realistic and long-term decisions, not > to destroy Linden Lab's vision of the future. > > -- > Cathy > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Tue Feb 24 10:04:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6379C28C203 for ; Tue, 24 Feb 2009 10:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpLjUILqgNMV for ; Tue, 24 Feb 2009 10:04:29 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id CFC3D28C23F for ; Tue, 24 Feb 2009 10:04:01 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 9821F3DBC44E; Tue, 24 Feb 2009 10:04:20 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Catherine Pfeffer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 10:04:18 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:04:30 -0000 yes. several alternatives were considered. it was noted, however, that... * the difference in space between the existing standard and something like what's proposed here, after applying gzip is minor. (this is germane because we expect people to use compressed content encoding if they care about bandwidth utilization) * the difference in parse time is negligible as it turns out you either have to parse angle brackets or parse = inside an element. * the DTD as it's specified now was considered "easier to code" by the person tasked with implementing it * many of us did not like the idea of making the content of an attribute and the name of an element co-dependent, as Zero explained in a different email i'm also a bit confused... what's the difference between 99992123123123 and 99992123123123 ??? i might be mis-reading you, but it sounds like you're saying the former allows you to add a size attribute, but the latter doesn't. which can't possibly be what you're suggesting because i just put myself in the situation of having to extend the XML serialization in the future and added a size attribute to the integer element and the world didn't come to an end. On Feb 24, 2009, at 5:51 AM, Catherine Pfeffer wrote: > (Infinity: there is a question for you at the end of this message) > > Jon said: > > A better way is > > > > > > true > > > key="something_i_like_to_eat_on_sundays">bananas > > > > > > natural way to express it.This has less of the angle bracket tax, > and it > > has a VERY straight-forward parsing style. In fact, in my opinion > it's > > the most In XPath, it's now trivial: "value[@key=success]" > > Yes. I had thought at this solution too, but I had hesitated to > propose it straight away to the mailing list... > > This solution has fewer angle bracket tax, but it also has hidden > implications. I assumed (perharps wrongly) that the authors of the > XML serialization had seen these implications, and rejected this > solution because of these implications. > > Moving tags (, , and so on) to attribute > names or values is not an innocent operation. Here are the > consequences I can see: > > > 1) To allow validation of the allowed types, the new "type" > attribute would need to be declared as an enumeration in the DTD or > schema. > > No big deal so far. > > > 2) More of a problem: if using XML schema for validation, it is more > straightforward to check that > 3.14 > and > 42 > are correct, than to check that > 3.14 > 42 > are correct. > > (XML schema allows for checking that the data inside the tags > conform to a certain syntax, for example that floats are made of > digts and possibly of a decimal dot and a minus sign). > > > 3) The key ("success" or "something_i_like_to_eat_on_sundays") is > not part of the data flow anymore, but part of the markup. > > There are half-religious wars inside the XML world according to what > should be an attribute and what should be text ;-). Personally, in > this case, I would say that an attribute is more suited to this kind > of data, because then we could enumerate all the allowed values for > the virtual world context ("name", "taper_x", "socks", > "notecard_encoding", whatever is normalized on top of VWSD), so I > see this as an advantage of your solution. > > On the other hand, if I understand well, LLSD has been defined to > allow keys to evolve rapidely and to be supported differently across > various implementations, so validating the key values is perharps a > bad idea. > > > 4) Other advantages of your solution, Jon: default values for > attributes could be omitted, and we could address size and signed- > ness of the scalars in separate attributes. > > Examples: > 42 > would be synonymous of > 42 > > 3.14159265353238 > would be synonymous of > signed="yes">3.14159265353238 > > Of course, there is a lot to spare on the angle bracket tax here, > since most data is probably integer, 32 bits,, and signed). > > It is also more future-proof, since 'size="128"' could be added > afterward easily, even if not planned initially. > > > > I'm working on a list of the things I think are wrong with the > current > > proposal, of which this is one thing (there are about six). If we're > > open to change on those things (including this), then I could get > behind > > the LLSD. Stay tuned :-) > > I have a similar list too ;-). Someone here has proposed a VWSD > working group to separate high level concerns (like meshes versus > prims) from low level concerns (like data types and serializations). > If we are sure that xxSD is the way to go (and not ASN or whatever), > I would volunteer to be part of such a group, and so would you, Jon, > I guess ;-). > > Infinity, how was the XML serialization thought? Have several > alternatives been compared and considered carefully? Or is it just > the result of the inspiration of the person who made it at a given > time? > > -- > Cathy > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From cathypfeffer@gmail.com Tue Feb 24 10:33:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2853A3A6977 for ; Tue, 24 Feb 2009 10:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+1U15FQHG1S for ; Tue, 24 Feb 2009 10:33:22 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id E384A3A6805 for ; Tue, 24 Feb 2009 10:33:21 -0800 (PST) Received: by ewy8 with SMTP id 8so370527ewy.13 for ; Tue, 24 Feb 2009 10:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=s8CWcmCmTEBoGTSIiPBZ7bKe+C89ZbApum72ajIuqXA=; b=ZWSbm8tQhhkyddwI4uEehzV5dgNuPUJMtf7+dwleWz1PF+qZz4pYdgUH5MQMY2zv4+ Aa/Tj3Q6SkIC66p7cXvaV3A8Gvn0YZmfW/L1wcJyO961UaU+ULV9iCK9b5yipXeaa8TA rUCg4Ao7jlnF2726xJGLdhPRmLlbxdkEuYeHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=av0q1eCWLQm0YPZ0ySKy5B3H8N8kouFR8Jy9VsqpJYR4Tt+JtNrEqtN/DmfxGtJrZT +gidrVYOnPOCdV43uzqSzwGX7KqZAM62RqEasmAeXws5Qb/Cpnls3ctTUUTX8tDAwG0b B3kn7/AteZ0q1ACBkTUOm9g2/LAZi2c8GHE5c= MIME-Version: 1.0 Received: by 10.210.92.11 with SMTP id p11mr24379ebb.24.1235500419430; Tue, 24 Feb 2009 10:33:39 -0800 (PST) Date: Tue, 24 Feb 2009 19:33:39 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c436c9ebb000463ae5b74 Subject: [mmox] Top down or down top? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:33:23 -0000 --0015174c436c9ebb000463ae5b74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Christian wrote: > Well, I know a lot of places where it's used to add additional > attributes etc. (it = namespaces) Additional attributes from the same standard? > Maybe some XML representation is really all which is needed. I'm glad we said it in parallel without any concertation ;-). > But actually I really would first think about a more global approach > towards a general architecture and then defined the more details > protocols and formats needed. What we need is perharps both a top-down approach and a down-top approach. For example, what happens if you write all the clothing serialization in LLIDL and then Jon says "well, data description would be better in XML schemas" ? ;-) In the other direction, the high level analysis might discover that we need to add a "time" data type to the lower level. I feel it safer to think both at highest layers and at lowest layers at the same time. The actual work needs not be done by the same people. If they work in different groups, there just needs to be enough communication between both groups so the whole picture remains consistent. The whole approach can be an incremental process. -- Cathy --0015174c436c9ebb000463ae5b74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Christian wrote:
> Well, I know a lot of places where it's used t= o add additional
> attributes etc.
(it =3D namespaces)

Addi= tional attributes from the same standard?

> Maybe some XML repres= entation is really all which is needed.

I'm glad we said it in parallel without any concertation ;-).
> But actually I really would first think about a more global approach=
> towards a general architecture and then defined the more details > protocols and formats needed.

What we need is perharps both a t= op-down approach and a down-top approach.

For example, what happens = if you write all the clothing serialization in LLIDL and then Jon says &quo= t;well, data description would be better in XML schemas" ? ;-)

In the other direction, the high level analysis might discover that we = need to add a "time" data type to the lower level.

I feel = it safer to think both at highest layers and at lowest layers at the same t= ime. The actual work needs not be done by the same people. If they work in = different groups, there just needs to be enough communication between both = groups so the whole picture remains consistent. The whole approach can be a= n incremental process.


--
Cathy
--0015174c436c9ebb000463ae5b74-- From suzyque@gmail.com Tue Feb 24 10:38:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2752D3A690D for ; Tue, 24 Feb 2009 10:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyrF2wwZMAJx for ; Tue, 24 Feb 2009 10:38:25 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id A00EA3A63D2 for ; Tue, 24 Feb 2009 10:38:25 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1560302qwe.31 for ; Tue, 24 Feb 2009 10:38:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=3zhrEAtJZDerS2nrPpqXJj7xPuuqmEgC0KsVrhmJIy0=; b=F7USY/dKaKoJC7+QKQhBZzGIHKS/4W4Yvr9+RFNWn2wyS1ZSgJJVP4S95JMYe/Nrrn 85E9R7SQZWGSvsgpfvyWEWAOPD4Sh8d/raOFAQ38cvreZA5mPpdQPiFFQIgakg6Eat7F K2/L50TjCY1dZRDlm3z9kH6/T7S2zKO6Td75M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Ozy4mEb0t3t052T/QN3V3Z9hmoNwVgNgp+YlsRrJIiS1GYv0dQZPW5i2Gs+JtzEmJ4 NcMuA9daa+mCxWkEmszTqLXWE16+k8SR+wnXNmuMNjTcrkfusrbx8plcwscQ3a6bzFFu 7y3XRAymSM1FqA3+MRugSYok9T9TOxy4/fedg= MIME-Version: 1.0 Sender: suzyque@gmail.com Received: by 10.224.2.205 with SMTP id 13mr45821qak.343.1235500724161; Tue, 24 Feb 2009 10:38:44 -0800 (PST) In-Reply-To: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> Date: Tue, 24 Feb 2009 12:38:44 -0600 X-Google-Sender-Auth: 27321e82c32657e8 Message-ID: <2bd5b7f10902241038w3f9ddaffkf822b5e0c31c2c48@mail.gmail.com> From: Suzy Deffeyes To: Infinity Meadhbh Hamrick Content-Type: multipart/alternative; boundary=0015175ca88ec88eb80463ae6d7d Cc: mmox@ietf.org Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: suzyq@pobox.com List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:38:27 -0000 --0015175ca88ec88eb80463ae6d7d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit re: other standards.... Discussion of other standards that exist in this area is totally appropriate, if a good match for a particular area of the standard already exists and has a community of tools and support for it, we should consider adopting it. re: how to proceed. It does feel like there are a lot of conversations in the MMOX group that are diving into minute detail, and I still feel that there are widely differing ideas on what the word Interoperability means. We don't all have to have an identical view on what Interoperability means. I think it would help us to define things in terms of the Use Cases we want to support. Use Cases could be defined in terms of functionality, capability, and services available for an end user ( end loser? :-). Some examples of Use Cases: 1. User maintains same identity, and moves between grids (should define the word grid), there is no concept of inventory items having "restrictions" on them 2. Same as 1, but with full up "Annie Get Your Gun" policy and mechanisms in place for inventory item permissions 3. End users with different viewer technologies collaborate in a shared space. The shared space contains a chair that is simulated by Virtual World A and a motorcycle simulated by Virtual Worlds B 4..... 5.... re: proprietary... I tend to care about OLIVE because it is outside our little SL/OS teleport bubble. They have different Use Cases that are important to them, and might be interesting to see where we can have some overlap. Perhaps in the overlap areas, a proprietary vendor might feel the benefit of adding their own proposal outweighs the benefits of staying proprietary. Suzy Deffeyes Pixel Gausman IBM On Tue, Feb 24, 2009 at 10:08 AM, Infinity Meadhbh Hamrick < infinity@lindenlab.com> wrote: > so... what started as a pleasant little proposal to take our (the awg's) > pleasant little protocol (ogp) kick it around in public (the mmox mailing > list) and potentially generate some RFCs from it seems to have spawned a > number of discussions. _all_ of the discussions are interesting, but perhaps > not all of them are germane to the proposed task. > > so i ask.. is it appropriate to limit the discussion here to the MMOX > Charter, LLSD, OGP and HyperGrid with occasional reference to the IETF IPR > Disclosure Policy? > > to be sure... we _are_ in the stage where the charter is important to > discuss... but i'm just wondering... and these questions are here to spark > _conversation_, not radical debate. there are rational answers, pro and con, > to each of these questions and teasing them out is important... > * why would we care about HLA, DIS or IEEE-1278? they're already > standardized. (though understanding that the structure of something like OGP > differs from the structure of these protocols _is_ important.) > * why do we care about OLIVE, which is a proprietary protocol with a > single implementation? > * why do we care about MXP whose apparent dependence on another > protocol with unclear IPR encumbrance gives some people on this list the > willies. > > so the questions i pose are... > * pursuit of which of these topics brings us to our goal of an > interoperable virtual worlds? > * what does it mean to be interoperable? > * must we have early agreement on all topics before we move forward > with any component? > > * OGP (Open Grid Protocol) > * should OGP be named something else? > * how do we do the event queue? (COMET? Bayeux? RHTTP? Long Poll?) > * where do we stuff permissions in this model? > * OGP/Teleport is not HyperGrid > * LLSD > * why is LLSD different from XDR? ASN.1? Google ProtocolBuffers? > * 128 bit integers? good enough? > * should LLSD be named something else? > * XML serialization > * maps are too much like apple plists in the XML > serialization. > * MMOX Charter > * we should rename everything > * we should abandon interoperability in favor of general agreement > of model > * IETF > * Virtual Worlds in General > * Previously Established Protocols > * HLA, DIS, IEEE-1278 and related protocols > * OLIVE > * MXP? > * VRML > * Representation of virtual objects > * meshes vs. prims > * interaction models for virtual objects > * Intellectual Property Regimes for Virtual Worlds > * Creative Commons (awesome gateway to free culture or the > ultimate embodiment of evil in the noosphere?) > * DRM (the only way i'll trust you with my content or the > ultimate embodiment of evil in the noosphere?) > * permissions regime > * MPEG-21? > * must we mandate the SL-style c/m/t permission? > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --0015175ca88ec88eb80463ae6d7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable re: other standards.... Discussion of other standards that exist in this ar= ea is totally appropriate, if a good match for a particular area of the sta= ndard already exists and has a community of tools and support for it, we sh= ould consider adopting it.

re: how to proceed. It does feel like there are a lot of conversations = in the MMOX group that are diving into minute detail, and I still feel that= there are widely differing ideas on what the word Interoperability means.= =A0 We don't all have to have an identical view on what Interoperabilit= y means.

I think it would help us to define things in terms of the Use Cases we = want to support. Use Cases could be defined in terms of functionality, capa= bility, and services available for an end user ( end loser? :-).

Some examples of Use Cases:
1. User maintains same identity, and moves = between grids (should define the word grid), there is no concept of invento= ry items having "restrictions" on them
2. Same as 1, but with= full up "Annie Get Your Gun" policy and mechanisms in place for = inventory item permissions
3. End users with different viewer technologies collaborate in a shared spa= ce. The shared space contains a chair that is simulated by Virtual World A = and a motorcycle simulated by Virtual Worlds B
4.....
5....

re: proprietary... I tend to care about OLIVE because it is outside our= little SL/OS teleport bubble. They have different Use Cases that are impor= tant to them, and might be interesting to see where we can have some overla= p. Perhaps in the overlap areas, a proprietary vendor might feel the benefi= t of adding their own proposal outweighs the benefits of staying proprietar= y.

Suzy Deffeyes
Pixel Gausman
IBM

On Tue, Feb 24, 2009 at 10:08 AM, Infinity Meadhbh Hamrick <infinity@lindenlab.com= > wrote:
so... what starte= d as a pleasant little proposal to take our (the awg's) pleasant little= protocol (ogp) kick it around in public (the mmox mailing list) and potent= ially generate some RFCs from it seems to have spawned a number of discussi= ons. _all_ of the discussions are interesting, but perhaps not all of them = are germane to the proposed task.

so i ask.. is it appropriate to limit the discussion here to the MMOX Chart= er, LLSD, OGP and HyperGrid with occasional reference to the IETF IPR Discl= osure Policy?

to be sure... we _are_ in the stage where the charter is important to discu= ss... but i'm just wondering... and these questions are here to spark _= conversation_, not radical debate. there are rational answers, pro and con,= to each of these questions and teasing them out is important...
=A0 =A0 =A0 =A0* why would we care about HLA, DIS or IEEE-1278? they'r= e already standardized. (though understanding that the structure of somethi= ng like OGP differs from the structure of these protocols _is_ important.)<= br> =A0 =A0 =A0 =A0* why do we care about OLIVE, which is a proprietary protoc= ol with a single implementation?
=A0 =A0 =A0 =A0* why do we care about MXP whose apparent dependence on ano= ther protocol with unclear IPR encumbrance gives some people on this list t= he willies.

so the questions i pose are...
=A0 =A0 =A0 =A0* pursuit of which of these topics brings us to our goal of= an interoperable virtual worlds?
=A0 =A0 =A0 =A0* what does it mean to be interoperable?
=A0 =A0 =A0 =A0* must we have early agreement on all topics before we move= forward with any component?

* OGP (Open Grid Protocol)
=A0 =A0 =A0 =A0* should OGP be named something else?
=A0 =A0 =A0 =A0* how do we do the event queue? (COMET? Bayeux? RHTTP? Long= Poll?)
=A0 =A0 =A0 =A0* where do we stuff permissions in this model?
=A0 =A0 =A0 =A0* OGP/Teleport is not HyperGrid
* LLSD
=A0 =A0 =A0 =A0* why is LLSD different from XDR? ASN.1? Google ProtocolBuf= fers?
=A0 =A0 =A0 =A0* 128 bit integers? good enough?
=A0 =A0 =A0 =A0* should LLSD be named something else?
=A0 =A0 =A0 =A0* XML serialization
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* maps are too much like apple plists in th= e XML serialization.
* MMOX Charter
=A0 =A0 =A0 =A0* we should rename everything
=A0 =A0 =A0 =A0* we should abandon interoperability in favor of general ag= reement of model
* IETF
* Virtual Worlds in General
=A0 =A0 =A0 =A0* Previously Established Protocols
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* HLA, DIS, IEEE-1278 and related protocols=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* OLIVE
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* MXP?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* VRML
=A0 =A0 =A0 =A0* Representation of virtual objects
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* meshes vs. prims
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* interaction models for virtual objects =A0 =A0 =A0 =A0* Intellectual Property Regimes for Virtual Worlds
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Creative Commons (awesome gateway to free= culture or the ultimate embodiment of evil in the noosphere?)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* DRM (the only way i'll trust you with= my content or the ultimate embodiment of evil in the noosphere?)
=A0 =A0 =A0 =A0* permissions regime
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* MPEG-21?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* must we mandate the SL-style c/m/t permis= sion?
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--0015175ca88ec88eb80463ae6d7d-- From john.hurliman@intel.com Tue Feb 24 10:51:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F8013A6982 for ; Tue, 24 Feb 2009 10:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qH3Qycl2zRrT for ; Tue, 24 Feb 2009 10:51:12 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id 4C4A23A6960 for ; Tue, 24 Feb 2009 10:51:12 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 24 Feb 2009 10:51:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,260,1233561600"; d="scan'208";a="113940892" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by azsmga001.ch.intel.com with ESMTP; 24 Feb 2009 10:51:31 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Tue, 24 Feb 2009 11:51:31 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Tue, 24 Feb 2009 11:51:25 -0700 Thread-Topic: [mmox] taxonomy of topics Thread-Index: AcmWmhvUDpMaBv4uRVK52QHsZ3SRoAAFgBrw Message-ID: <62BFE5680C037E4DA0B0A08946C0933D502DECE0@rrsmsx506.amr.corp.intel.com> References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> In-Reply-To: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:51:13 -0000 If this is a request to limit what topics will be discussed by MMOX, can we= please cut LLSD, OGP, and HyperGrid out of the discussion? I've posted my = critiques of both to this mailing list and I feel that using another IDL su= ch as Google Protocol Buffers, and starting over from scratch for cross-dom= ain communication would be in the better interest of the virtual world inte= rop. HyperGrid is another implementation of the same trust map proposal of = OGP (with different default settings), and no one has suggested that they w= ill be submitting it as a proposal. John >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Meadhbh Hamrick >Sent: Tuesday, February 24, 2009 8:08 AM >To: mmox@ietf.org >Subject: [mmox] taxonomy of topics > >so... what started as a pleasant little proposal to take our (the >awg's) pleasant little protocol (ogp) kick it around in public (the >mmox mailing list) and potentially generate some RFCs from it seems to >have spawned a number of discussions. _all_ of the discussions are >interesting, but perhaps not all of them are germane to the proposed >task. > >so i ask.. is it appropriate to limit the discussion here to the MMOX >Charter, LLSD, OGP and HyperGrid with occasional reference to the IETF >IPR Disclosure Policy? > >to be sure... we _are_ in the stage where the charter is important to >discuss... but i'm just wondering... and these questions are here to >spark _conversation_, not radical debate. there are rational answers, >pro and con, to each of these questions and teasing them out is >important... > * why would we care about HLA, DIS or IEEE-1278? they're already >standardized. (though understanding that the structure of something >like OGP differs from the structure of these protocols _is_ important.) > * why do we care about OLIVE, which is a proprietary protocol >with a >single implementation? > * why do we care about MXP whose apparent dependence on another >protocol with unclear IPR encumbrance gives some people on this list >the willies. > >so the questions i pose are... > * pursuit of which of these topics brings us to our goal of an >interoperable virtual worlds? > * what does it mean to be interoperable? > * must we have early agreement on all topics before we move >forward >with any component? > >* OGP (Open Grid Protocol) > * should OGP be named something else? > * how do we do the event queue? (COMET? Bayeux? RHTTP? Long >Poll?) > * where do we stuff permissions in this model? > * OGP/Teleport is not HyperGrid >* LLSD > * why is LLSD different from XDR? ASN.1? Google ProtocolBuffers? > * 128 bit integers? good enough? > * should LLSD be named something else? > * XML serialization > * maps are too much like apple plists in the XML >serialization. >* MMOX Charter > * we should rename everything > * we should abandon interoperability in favor of general >agreement of >model >* IETF >* Virtual Worlds in General > * Previously Established Protocols > * HLA, DIS, IEEE-1278 and related protocols > * OLIVE > * MXP? > * VRML > * Representation of virtual objects > * meshes vs. prims > * interaction models for virtual objects > * Intellectual Property Regimes for Virtual Worlds > * Creative Commons (awesome gateway to free culture or >the ultimate >embodiment of evil in the noosphere?) > * DRM (the only way i'll trust you with my content or >the ultimate >embodiment of evil in the noosphere?) > * permissions regime > * MPEG-21? > * must we mandate the SL-style c/m/t permission? >_______________________________________________ >mmox mailing list >mmox@ietf.org >https://www.ietf.org/mailman/listinfo/mmox >=20 From cathypfeffer@gmail.com Tue Feb 24 11:04:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59A6D28C12F for ; Tue, 24 Feb 2009 11:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvEX+GPlAFRL for ; Tue, 24 Feb 2009 11:04:19 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id E6C2928C128 for ; Tue, 24 Feb 2009 11:04:18 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so538040eya.31 for ; Tue, 24 Feb 2009 11:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=PkAjMkLNQiNZVn9Qkb2/cfmKiMjlXIGrMGX+RL49LSQ=; b=O+VpOFsrIh1tkJahfHgflP08QFLOaSIZagILrTE1HxWafJqhEBMHOIg0tx62oj+4a4 nrvve++Etr2i9hNfpo97VYemSa/vkus99NntF9S6zDRo08CvFts8jTle5F9bVFuoghIt bKXcmXMnUzp2VkOH6ksRpzuAIF1j8/X+0DGpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=bD/+C0IbIDKGpmyU2vlzUr0nzTa6L9z8dBmIwifVoBaixh+2/Qew0ql0C3j7YVtRX/ hafYQAYYJBhfsXmRARRo0fKy0OquSu3Y2zybEmbdldUABpjCYF6K5vpfdoXV/Hc43fpB X428XwXTLaL84WVks4Q4X/5HWq7z9Qxj5jcbo= MIME-Version: 1.0 Received: by 10.210.28.6 with SMTP id b6mr17340ebb.48.1235502277376; Tue, 24 Feb 2009 11:04:37 -0800 (PST) Date: Tue, 24 Feb 2009 20:04:37 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c1a685cb9fb0463aeca85 Subject: [mmox] Formalizing my proposal X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:04:20 -0000 --0015174c1a685cb9fb0463aeca85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Infinity wrote: > 1. can you please submit your proposal? Sure. I'll submit a proposal that makes the XML serialization better, although it would assume: 1)- that LLSD is what we need for lower layer 2) that we would stick to three serializations for LLSD and not just one, leading to clumsy XML both points are still not certainties in my mind. But I'll send the formalized proposal as you asked it. > most of the XML LLSD is sent over HTTPS, > which might explain why you can't see it in wireshark Aaah, Ok, thanks for the tip! ;-) > 6. the reason we separate the serialization from the protocol > definition is we want to avoid having to add "binary serialization", > "json serialization" and "xml serialization" sections to each defined > protocol interaction. Yes, and that leads to a XML serialization that does not take all the advantage of what can be done in XML, and that takes a lot of bandwidth. Again, why would we need three serializations when one is just enough? Not saying that it's just 1/3rd of the implementation effort... > I think there's a history of people defining protocols > using relatively "high level" abstractions, then providing mechanistic > technique for generating the "octets over the wire." That's correct, it's nice to think in abstract terms, and then map the result to a given implementation. That does not mean you need three implementations... > 7. i really like the idea of using LLSD to represent meshes, link-sets > of prims, or even 2d SVG representations of avatars and objects. ... which means, in XML, that we could not re-use existing meshes or SVG XML dialects just by changing the namespace, but that we would have to "convert" everything to LLSD. While this would certainly work, it sounds to me like a lot of efforts, while simply mixing vw: and svg: namespaces in one single file could do the trick. Otherwise, you'd first have to define how SVG remaps to LLSD, then implement it. XML namespaces are precisely offering this ability to mix different type of data from different standards without ambiguity and without any need to remap one standard into the other. -- Cathy --0015174c1a685cb9fb0463aeca85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Infinity wrote:
> 1. can you please submit your proposal?

Sure= . I'll submit a proposal that makes the XML serialization better, altho= ugh it would assume:
1)- that LLSD is what we need for lower layer
2) that we would stick to three serializations for LLSD and not just one, l= eading to clumsy XML

both points are still not certainties in my min= d. But I'll send the formalized proposal as you asked it.

> m= ost of the XML LLSD is sent over HTTPS, =C2=A0
> which might explain why you can't see it in wireshark

Aaah, Ok, thanks for the tip! ;-)

> 6. the reason we sep= arate the serialization from the protocol =C2=A0
> definition is we w= ant to avoid having to add "binary serialization", =C2=A0
> "json serialization" and "xml serialization" secti= ons to each defined =C2=A0
> protocol interaction.

Yes, and th= at leads to a XML serialization that does not take all the advantage of wha= t can be done in XML, and that takes a lot of bandwidth.

Again, why would we need three serializations when one is just enough? = Not saying that it's just 1/3rd of the implementation effort...

= > I think there's a history of people defining protocols =C2=A0
&= gt; using relatively "high level" abstractions, then providing me= chanistic =C2=A0
> technique for generating the "octets over the wire."
That's correct, it's nice to think in abstract terms, and then map= the result to a given implementation. That does not mean you need three im= plementations...

> 7. i really like the idea of using LLSD to represent meshes, link-= sets =C2=A0
> of prims, or even 2d SVG representations of avatars and= objects.

... which means, in XML, that we could not re-use existing= meshes or SVG XML dialects just by changing the namespace, but that we wou= ld have to "convert" everything to LLSD.

While this would certainly work, it sounds to me like a lot of efforts,= while simply mixing
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vw:
a= nd
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 svg:
namespaces in one = single file could do the trick. Otherwise, you'd first have to define h= ow SVG remaps to LLSD, then implement it.

XML namespaces are precisely offering this ability to mix different typ= e of data from different standards without ambiguity and without any need t= o remap one standard into the other.


--
Cathy
--0015174c1a685cb9fb0463aeca85-- From veikko.eeva@iki.fi Tue Feb 24 11:15:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A4F3A693E for ; Tue, 24 Feb 2009 11:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWy9h0u311vc for ; Tue, 24 Feb 2009 11:15:00 -0800 (PST) Received: from av-gw2.cc.tut.fi (av-gw2.cc.tut.fi [130.230.130.111]) by core3.amsl.com (Postfix) with ESMTP id CBF2F3A68A7 for ; Tue, 24 Feb 2009 11:14:59 -0800 (PST) Received: from av-gw2.cc.tut.fi (unknown [127.0.0.1]) by av-gw2.cc.tut.fi (Symantec Mail Security) with ESMTP id C38A9150117 for ; Tue, 24 Feb 2009 21:15:17 +0200 (EET) X-AuditID: 82e6826f-ac999bb0000003e2-2d-49a44745c00a Received: from mail.cc.tut.fi (unknown [130.230.1.120]) by av-gw2.cc.tut.fi (Symantec Mail Security) with ESMTP id AC5DA900C6 for ; Tue, 24 Feb 2009 21:15:17 +0200 (EET) Received: from [192.168.1.100] (a91-153-26-45.elisa-laajakaista.fi [91.153.26.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cc.tut.fi (Postfix) with ESMTP id BB0E1A41AE for ; Tue, 24 Feb 2009 21:15:17 +0200 (EET) Message-ID: <49A44744.5050804@iki.fi> Date: Tue, 24 Feb 2009 21:15:16 +0200 From: Veikko Eeva User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mmox@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [mmox] LLIDL or schemas? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:15:01 -0000 > Jon said: > > I propose that the data structure > > definition language be moved to some XML schema. > > Yes, LLIDL makes no sense in the XML world, where there are schemas (or > DTDs) for that. > > That's another example of technical compromise needed by this "three > serializations" scheme. > > My suggestion would be: "do only one serialization, but do it well"... > - If XML has an angle bracket tax that is too expensive to pay, > especially on limited capability devices, then let's stick to a binary > format only. > - If XML is the way to go because it's more flexible, human-readable, > and because there's already a bunch of tools for it, then go for it > only, but do it using all the possibilities of the XML technology. > > My opinion is that doing an 1:1 transposition of a binary format is just > like automatically translating French into English word per word, it > gives bad (although sometimes really funny) results. > > Anyhow, who is asking for a choice between three serializations? Is > there a use case for that? > > Don't take it bad, Infinity. I'm just trying to put my engineering > knowledge at the service of realistic and long-term decisions, not to > destroy Linden Lab's vision of the future. I joined the list just recently and I haven't read through all the messages in detail, so forgive me if this issues has been handled already... But is there an issue concerning (efficient) protocol encoding between prospective current and future virtual worlds? From an engineering stand-point I'd say the issue in this case is pretty much that we don't know what kind of fields are there needed in the protocol. So, in order to alleviate that, a more dynamic, expandable approach would be good. And we are in luck, since such protocols have been devised in the past and there are plenty of parsers and libraries to use. One such approach is TLV encoded messages (http://en.wikipedia.org/wiki/Type-length-value) that allow to carry both binary and XML data and allow addition of new and even proprietary fields with no problems. Mandating an XML-based protocol feels grossly inefficient (if not a general TLV solution being one already) that drops probably all game-like soft realtime applications out of reach. What comes to parsing in general, if someone is good enough to define the protocol in some sensible fashion, i.e. formal manner (EBNF, Schema, SDL etc.), there are automatic tools and libraries to create the needed code. Or even something like Google Protocol Buffers ("think XML, but smaller, faster, and simpler", http://code.google.com/intl/fi/apis/protocolbuffers/). So, I would say the "transport protocol" issue seems to be a solved one. We should just pick the most efficient one that allows expanding the pay-load, like TLV. Instead the focus should be what those fields should be. That is, there should focus on the content of the protocol: property rights and all things like that. Even the actual type of transferred resources can be agreed on later, e.g. if all content should be COLLADA (http://en.wikipedia.org/wiki/COLLADA) and SVG or something. If the issues is synchronising real-time actions between worlds, I strongly suspect it shall not work. Games and simulations use prediction and all kinds of protocol gimmicks in order to sustain immersion. The most plausible approach to take would that there's a handshaking phase in agreeing a common approach (e.g. High Level Architecture (HLA)) that will take place. But this is something I believe cannot be decided here and now. Engineering thoughts cordially, Veikko E. From jwatte@gmail.com Tue Feb 24 11:23:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112D73A6A2C for ; Tue, 24 Feb 2009 11:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=-1.007, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-wJdzSqWY0W for ; Tue, 24 Feb 2009 11:23:06 -0800 (PST) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 118FF3A6927 for ; Tue, 24 Feb 2009 11:23:05 -0800 (PST) Received: by gxk7 with SMTP id 7so2729426gxk.13 for ; Tue, 24 Feb 2009 11:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9kXLNe4VtrybGlqmYlW5iIiTyj0poTXujWCKUp5Hsx0=; b=ovJU4kvXPHFbXLIcKGvdsm0MpSqOb2i/JGwQsYR2nYpfF+kSB2/cABEoWbrq9aD7XO /0Wpw714s97mkXH9LwfXcznUl7EWM4omz5MNnobWeVSUfWVT/rycYR9z3fYQQGADDYK9 xiqtq40bAoKqlx/pMBg+LpsDj/H7V5Pi3E/4I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Zyq0kYq9ileZJByZPlGnTN4VOYgQW2X3PJPVJFw9NXFeWF51Yg3ByciqbhlEdPbfpy wo5vCgn9x7HAxmm9KqjNnoE+xLbCp/rE8UWOmiZNAmUgdv/Zipx1f+wEWIKbNbnlOsgP 8Goy22Kv4ckDyZznhIatrwuhf213kWeU4/qNA= Received: by 10.100.196.17 with SMTP id t17mr110110anf.84.1235503404238; Tue, 24 Feb 2009 11:23:24 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d35sm261311and.38.2009.02.24.11.23.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 11:23:23 -0800 (PST) Message-ID: <49A44928.10307@gmail.com> Date: Tue, 24 Feb 2009 11:23:20 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:23:07 -0000 Catherine Pfeffer wrote: > (XML schema allows for checking that the data inside the tags conform > to a certain syntax, for example that floats are made of digts and > possibly of a decimal dot and a minus sign). > But you don't actually know whether those digits are actual, valid data until and unless that data hits some real executable code. Additionally, we will likely deal with data types that are naturally atomic ("vector3" or "quaternion") but that are not part of the XML data type set. Sending a vector3 as "xyz" seems like a bad idea, compared to "x,y,z". You wouldn't know whether "123000,-5000000,600000" is a proper teleport destination, or under the surface of the earth, or outside the allowed simulation coordinate space, until you treated that coordinate in the target world space. Thus, the validation capabilities of a possible XSD are limited at best anyway. I must admit that the main reason I want things in attributes is brevity, and uniformity of handling. If I want to get a node set of all property values of a given entity record, I can simply do: values = entityNode.getElementsByTagName("value"); Similarly, if I want to get a specific element, I can do: thePosition = entityNode.getElementById("pos"); This assumes that the "key" attribute is defined as an ID such that the DOM implementation can recognize it. On the other hand, depending on structure, it may mean that they key "pos" can't be used on multiple objects in the same overall XML document, so it might be better to get "matching attribute value" anyway: thePosition = entityNode.getElementPath("[@key='pos']") > > I have a similar list too ;-). Someone here has proposed a VWSD > working group to separate high level concerns (like meshes versus > prims) from low level concerns (like data types and serializations). > If we are sure that xxSD is the way to go (and not ASN or whatever), I > would volunteer to be part of such a group, and so would you, Jon, I > guess ;-). Personally, I think it's too early to really worry about it too much. I first want rough consensus on the model we're using -- I think most, but not all, participants on the list now understand that interoperating virtutal world objects practically require simulation hosts to talk to other simulation hosts. I also think that most participants understand that a specified client/server protocol would not actually solve interoperability between disparate simulation systems. But how do we actually define and determine "rough consensus"? Perhaps coming up with some metric for that would be a good first step. Sincerely, jw From cathypfeffer@gmail.com Tue Feb 24 11:24:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C19028C1E0 for ; Tue, 24 Feb 2009 11:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDaHUYdmtvSI for ; Tue, 24 Feb 2009 11:24:55 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by core3.amsl.com (Postfix) with ESMTP id BA70328C1D8 for ; Tue, 24 Feb 2009 11:24:52 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d3so523980nfc.39 for ; Tue, 24 Feb 2009 11:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=XlAj/Y41Zan1sgHA146tDn3WeCgK8Atzdu2qquI5VjM=; b=nX3QLDqSwWqkNVJh+o4ZuWZ4jO3iX6oH0aJXjVWo7zQiTqKml3G7WDDsPSmCoLdST9 naYyZG77kcT/eauX7ks+mDnPMtMaQ3Hd4wZJ5Y/Ga3Ji5XrsMh2BvVE9RMp4Mk32/e9T pcs5lLGN144oVTGMHgiV7rUiB2VY4ew27s6PI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ngZgF9r78696mnavcsdO6kJCH5x/VL8EAwGSK2nMaRnITMeeswoqNp6xmf8wXWoLV6 Tngxu4DzcD0C3NpMnj6eLYvKxJsNhuKEmG9Q9m/gPG23mvd8Kqjms4hjXGWFcKD3aMUy Qhwe/w1PUZbGGSKcdK9HrHBXaHW/AREWuFxi8= MIME-Version: 1.0 Received: by 10.210.33.3 with SMTP id g3mr11891ebg.88.1235503509518; Tue, 24 Feb 2009 11:25:09 -0800 (PST) Date: Tue, 24 Feb 2009 20:25:09 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c1982cdbb930463af138e Subject: [mmox] explanations X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:24:56 -0000 --0015174c1982cdbb930463af138e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Infinity wrote: > i'm also a bit confused... what's the difference between > > 99992123123123 > > and > > 99992123123123 > > ??? Let's restart from the beginning. We were speaking about maps. Taking current LLSD proposal, an example of map would be: something-big 99992123123123 something-smaller 42 This kind of constructs is unusual in the XML world, because it highly depends on the order: key, integer, key, integer. To find the integer associated with a key, you need to move in the following-siblings axis in XPath terminology. I suggested the following construct to avoid this problem: something-big 99992123123123 something-smaller 42 but that's even more bloated. So Jon came with something equivalent to: 99992123123123 42 which is smaller. Now this construct, valid for map entries, could be generalized for s outside of the maps: 99992123123123 Whether this is a good idea or not can be discussed and that was the object of my previous mail. -- Cathy --0015174c1982cdbb930463af138e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Infinity wrote:
> i'm also a bit confused... what's the diffe= rence between
>
> <value type=3D"integer" size=3D= "128">99992123123123</value>
>
> and
>=
> <integer size=3D"128"> 99992123123123</integer><= br>>
> ???

Let's restart from the beginni= ng. We were speaking about maps. Taking current LLSD proposal, an example o= f map would be:

<map>
=C2=A0=C2=A0=C2=A0=C2=A0 <key>something-big</ke= y>
=C2=A0=C2=A0=C2=A0=C2=A0 <integer>99992123123123</integer= >
=C2=A0=C2=A0=C2=A0=C2=A0 <key>something-smaller</key>=C2=A0=C2=A0=C2=A0=C2=A0 <integer>42</integer>
</map>

This kind of constructs is unusual in the XML world, be= cause it highly depends on the order: key, integer, key, integer. To find t= he integer associated with a key, you need to move in the following-sibling= s axis in XPath terminology. I suggested the following construct to avoid t= his problem:

<map>
=C2=A0=C2=A0=C2=A0=C2=A0 <entry>
=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0 <key>something-big</key>
=C2=A0 =C2=A0=C2=A0 =C2=A0 <integer>99992123123123</integer>=C2=A0=C2=A0=C2=A0=C2=A0 </entry>
=C2=A0=C2=A0=C2=A0=C2=A0 <en= try>
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 <key>something-smaller</key> =C2=A0 =C2=A0=C2=A0 =C2=A0 <integer>42</integer>
=C2=A0=C2= =A0=C2=A0=C2=A0 </entry>
</map>

but that's even more bloated. So Jon came with something equivalent= to:

<map>
=C2=A0=C2=A0=C2=A0=C2=A0 <entry key=3D"something-big" type=3D&= quot;integer">99992123123123</entry>
=C2=A0=C2=A0=C2=A0=C2= =A0 <entry key"something-smaller">42</entry>
</= map>

which is smaller. Now this construct, valid for map entries, could be g= eneralized for <value>s outside of the maps:
=C2=A0=C2=A0=C2=A0=C2=A0 <value key=3D"something-big" type=3D&= quot;integer">99992123123123</value>

Whether this is a good idea or not can be discussed and that was the ob= ject of my previous mail.

--
Cathy
--0015174c1982cdbb930463af138e-- From dyerbrookme@juno.com Tue Feb 24 11:38:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B02D13A6893 for ; Tue, 24 Feb 2009 11:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHYD6PVuR1G7 for ; Tue, 24 Feb 2009 11:38:36 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id BCD5B3A67A2 for ; Tue, 24 Feb 2009 11:38:36 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail11.vgs.untd.com [10.181.12.151]) by smtpout05.vgs.untd.com with SMTP id AABE4JVGKAM2LHUA for (sender ); Tue, 24 Feb 2009 11:38:49 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNn/ahqjvxbfGl6OqkZ6t0Xw== Received: (from dyerbrookme@juno.com) by webmail11.vgs.untd.com (jqueuemail) id N97KS2JJ; Tue, 24 Feb 2009 11:38:41 PST Received: from [68.161.198.3] by webmail11.vgs.untd.com with HTTP: Tue, 24 Feb 2009 19:38:40 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Tue, 24 Feb 2009 19:38:40 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090224.143840.17447.0@webmail11.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 5:2:3623131722 X-UNTD-Peer-Info: 10.181.12.151|webmail11.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 130 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:38:37 -0000 >I believe that we can, and should, enable the metadata that allows = service providers to provide strong DRM. This means that the acceptable = DRM scheme/schemes must be identified in the metadata, and a provider ca= n then choose not to provide a resource to some peer that has not signed= on to that DRM scheme. The actual mechanics of how the service verifies= that the peer is signed on to that same scheme does not need to be trea= ted by the standard; that's up to each DRM provider to figure out. This sounds good, but I do have to wonder why you would abandon this rea= dy opportunity to make the mechanics of verification part of interoperab= ility, even granted all the problems inherent in making a key and sendin= g a key or encrypting and getting into an arms race with hackers. These = concerns are abstract and mathematical, it seems to me pragmatic and ser= viceable compromises can be made. = I use the metaphor of the locked door in SL. Everyone knows that you can= use the sitpos hack through the "locked" door, that while it is locked = to a casual clicker, if you sit through it on a prim you rez or a couch,= it can't keep you out. Yet it is worth locking and worth having not onl= y as a social injunction articulated through an admittedly insufficient = mechanical means, but because the flawed mechanical means actually work = some certain percentage of the time as *most people* either don't know t= he sitpos hack OR they realize they are not wanted and go away. Once you= decide politically to drive the system through concern about protection= of creators and not drive it through concern about deterrence of hacker= s, you turn it around mathematically and pragmatically. >If we do that, then the DRM worlds and the open worlds will be able to = compete for the favor of the content creators and the users. Creators wh= o don't like the open practices of some open provider, will simply gravi= tate towards the protected practices provided by the protected providers= , and vice versa. Yes, and that means letting the market and freedom of information decide= , and that's anethema to opensource which prides itself on being "open" = and "owned by everybody" but in fact is closed to commerce based on owne= rship lol. >Meanwhile, I think that the set of bits we've identified = (view/copy/use/transfer/modify/derive) and the semantics for each bit = (allow-change, deny, allow-once and allow-always) could and should be = part of a required minimum schema -- i e, the service providers will = publish what they attempt to enforce, and incompatible semantics means = that no transfer of assets happen. That's just common sense. Yes, it is common sense, and the chimera of hacking and futility thrown = up about this are markers for extremism and abstractedness out of touch = with user needs. I believe that what saves this kind of proposal from the closed propriet= ary walled-garden military-industrial complex evil that those on the lef= t see it as (which is why some AWgroupies blogger is posting falsely, "C= ongratulations on your new job at Forterra, Prokofy) -- is that the DRM = is set not by the company, but by the creator, at least in the UGC world= s. That makes all the difference. Private property isn't in the hands of= corporations only, but of individuals. And again, the market can decide= , whether that creator wants to set his own DRM checkoffs, or whether he= will go through a central committee to ensure his IP. Prokofy Neva ____________________________________________________________ Click here to save cash and find low rates on auto loans. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLaW10EzMZbkrlEklo1N9K= I2UnplSuIqurkCLEV0rN9nzJMz4xVrq/ From dyerbrookme@juno.com Tue Feb 24 11:49:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B3A93A6957 for ; Tue, 24 Feb 2009 11:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ols55pynHrF for ; Tue, 24 Feb 2009 11:49:18 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id B0AB43A6950 for ; Tue, 24 Feb 2009 11:49:18 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail11.vgs.untd.com [10.181.12.151]) by smtpout01.vgs.untd.com with SMTP id AABE4JVZRAL873SS for (sender ); Tue, 24 Feb 2009 11:47:59 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNjWKPrwmK2t+bDV4l+Vb57Q== Received: (from dyerbrookme@juno.com) by webmail11.vgs.untd.com (jqueuemail) id N97LAHBG; Tue, 24 Feb 2009 11:47:08 PST Received: from [68.161.198.3] by webmail11.vgs.untd.com with HTTP: Tue, 24 Feb 2009 19:46:48 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Tue, 24 Feb 2009 19:46:48 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090224.144648.17447.1@webmail11.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 7:3:3895543845 X-MAIL-INFO: 393e0ebbabded3dffadbc36b4eca63733afa935b9a63238a17ea X-UNTD-Peer-Info: 10.181.12.151|webmail11.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 133 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:49:19 -0000 >Message: 1 Date: Tue, 24 Feb 2009 08:08:04 -0800 From: Meadhbh Hamrick (Infinity) Subject: [mmox] taxonomy of topics >so... what started as a pleasant little proposal to take our (the = awg's) pleasant little protocol (ogp) kick it around in public (the = mmox mailing list) and potentially generate some RFCs from it seems to h= ave spawned a number of discussions. = Dorothy, you're not in Oz anymore. >* Intellectual Property Regimes for Virtual Worlds * Creative Commons (awesome gateway to free culture or the ultimate em= bodiment of evil in the noosphere?) Er, there's nothing particularly awesome about free culture that somebod= y else always has to pay for, starting with the payment for servers and = programmers that house it, hmmm? Need to get at least land tier fees to = run the server farms and pay the coders, eh? Now, since I'm likely the only one on the list who uses the term "noosph= ere" I'll take that as yet another direct slam on a tier-payer from the = lovely customer-friendly Linden Lab, but that's ok. When you're way far = out on the left. anything in the center seems terribly conservative and = scary, I realize. Intellectual property regimes, not just server rental = fees and getting a cut from currency and shopping sites, are indeed the = way in which *other people besides technology vendors* are going to make= money in the Metaverse. I'll thank you to remember that. Virtual worlds= have people in them with a variety of "use cases". We're not all playin= g a game like World of Warcraft where we can accept the governance and I= P regimes from the Middle Ages along with the medieval scenery. > * DRM (the only way i'll trust you with my content or the ultimate em= bodiment of evil in the noosphere?) I guess I can tell what you think about it : ) >* permissions regime * MPEG-21? * must we mandate the SL-style c/m/t permission? Yes? And, pretty funny that the people who invented and implemented the = virtual world in which c/m/t prevails are not willing to defend it as th= e pragmatic center to hold against the encroachments on private property= from the left and the encroachments on creativity from the right. Shame= . Prokofy Neva ____________________________________________________________ Click to become an artist and quit your boring job. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIXulKmsbRPZDYmPqSQ6py= vuPS0hrolkNzlxtFdTBY4WRIqbE9bEk/ From jwatte@gmail.com Tue Feb 24 11:50:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A263A68CD; Tue, 24 Feb 2009 11:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bdq+gqf70p2D; Tue, 24 Feb 2009 11:50:21 -0800 (PST) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 8123B3A68A7; Tue, 24 Feb 2009 11:50:21 -0800 (PST) Received: by gxk7 with SMTP id 7so2737894gxk.13 for ; Tue, 24 Feb 2009 11:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=R0lvVffsS0X89l3+LmozQ9VsXLNotwjQFe4pWayiJf0=; b=CASJtBBy6BdaqLQW3Ld1hVgoN8LsXNWbUUUjLdgliBgSyVnEixVv87YiR//EIEljQP 5d0x+2E9hsq8dWuqqcguqZHyIpaRTgWDrZ+/MuLC8KqkB61rFssvF+2NOjSzjNwuZM+O EEVeuqAgZXSwMLRqBBTNb3NQ22yloJejOD+5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WoP/LUNx1uk7nuaoLVfhjTS4r/0Y/HyjCE9TEuB41s63HGw6dDXcof14CE4tcNJG30 8M3XloHeNeCOUno14nntD92H/yb9dBa3UHxigDeqxW1krHcGH2J57KW/DzHORvDqbtxE z6kIyiNVg0IRG86IRK5NevfBMTMytw/1RDvAI= Received: by 10.100.164.12 with SMTP id m12mr95782ane.144.1235505039451; Tue, 24 Feb 2009 11:50:39 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c14sm12087235ana.21.2009.02.24.11.50.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 11:50:38 -0800 (PST) Message-ID: <49A44F8C.5020609@gmail.com> Date: Tue, 24 Feb 2009 11:50:36 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: David W Levine References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:50:22 -0000 I like the depth of thinking you've put into this. If we can shift the overall discussion in this direction, I think that will be very fruitful. David W Levine wrote: > 1. The ability to manage one's identity when interacting in > multiple MMOX spaces. Note that Microsoft tried to do that with Microsoft Passport, for the 2D web, where it is a lot easier to do than the 3D web. They didn't succeed. It's not yet clear to me that you need an identity, as separate from your service provider. After all, if you change mail hosts, your e-mail address changes. Thus, I think it would be useful to specify what an identity looks like ("an email address is name @ host"), but trying to make it so that I can use "jwatte@gmail.com" when I sign up for HotMail doesn't seem feasible. > > 3. The ability to share content between MMOX spaces > a. Import and Export of content and models (This may > well leverage off of > existing work such as Collada) Static, import/export of content > while not > terribly dramatic is an important part of the value chain of > interoperability Offline and online sharing are, I think, very different. For offline sharing, you want as rich a model as possible, and size isn't all that important. For online sharing, you want something that gives a representative visual, but there are a lot of things you don't need (such as built-in scripting, undo history, specific modifier stack parameters for your DCC, etc). Also, for offline sharing, there are several official or de facto standards already in place, including AutoCad, COLLADA and X3D (which attempts to deliver on the "interactivity/scripting" part of a virtual world object). > ii. Extensible, with a common registry, so that > we can understand the > types of contents a client can accept, and a > virtual space, or virtual > asset store can be asked to provide I believe that if the standard is just an empty vessel, where different systems can put different content, then no true interoperability will have been achieved, because something like the Source Engine will put in Source Engine format data, and something like Club Penguin will put in Club Penguin format data. Yes, you can get the data, but that doesn't do you any good, because your system can't understand it. Thus, you get a lot of "Hey, I'm compliant with standard X!" without any real operability coming out of it. I am strongly for specifying a minimum set of content types that have to be supported, whatever they are. Ideally, that minimum set is something that maps well to existing content repositories, including all the AutoCad models of the world's cities and buildings, the Google Warehouse, and ESRI GIS data, for example. > 4. The affordances in MMOX to permit the creation of > micro-payment economies > a. Appropriate spots defined in MMOX protocols for cost > information > b. Appropriate spots defined in MMOX protocols for > reference to > micropayment systems > I'm not so sure this is in scope at all. If I want to do a transaction with a service provider, I expect that to be done through a web application. There are already fine web application standards. If any tie into micro-payments is needed, I think that only the capability to tie a web link to a command is necessary -- the fact that that link/command is a micro-transaction isn't even necessarily known to the VW system. > 5. The ability to share "non immersive streams" between spaces Again, assuming we have a content description, that "ability" can be expressed as a simple URL link. In fact, a standard like X3D already supports that kind of sharing. I think a much more important problem to solve is the sharing of real-time data streams. Also, there seems to be an implicit assumption that "one space" is served by "one system." I think that, long term, that will not actually scale. You won't put a simulation of 40,000 avatars on Times Square onto a single system. You simply must come up with a way to share the simulation of those avatars betwene separate systems. Thus, for both scalability, and interoperability reasons, I think that the ability for two separate hosts to "share responsibility" of an agreed virtual space is important. And, once you have that, each user of each of those systems can experience that shared space through the already existing infrastructure, without any particular user-side presentation standard being needed at all. Sincerely, jw From veikko.eeva@iki.fi Tue Feb 24 11:50:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8AC83A6977 for ; Tue, 24 Feb 2009 11:50:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifAhy3BVzYj3 for ; Tue, 24 Feb 2009 11:50:36 -0800 (PST) Received: from av-gw2.cc.tut.fi (av-gw2.cc.tut.fi [130.230.130.111]) by core3.amsl.com (Postfix) with ESMTP id C34E93A68A7 for ; Tue, 24 Feb 2009 11:50:36 -0800 (PST) Received: from av-gw2.cc.tut.fi (unknown [127.0.0.1]) by av-gw2.cc.tut.fi (Symantec Mail Security) with ESMTP id D722715016F for ; Tue, 24 Feb 2009 21:50:55 +0200 (EET) X-AuditID: 82e6826f-abf98bb0000003e2-d7-49a44f9f0e2a Received: from mail.cc.tut.fi (unknown [130.230.1.120]) by av-gw2.cc.tut.fi (Symantec Mail Security) with ESMTP id C70B1900CD for ; Tue, 24 Feb 2009 21:50:55 +0200 (EET) Received: from [192.168.1.100] (a91-153-26-45.elisa-laajakaista.fi [91.153.26.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cc.tut.fi (Postfix) with ESMTP id 6B68AA413C for ; Tue, 24 Feb 2009 21:51:01 +0200 (EET) Message-ID: <49A44FA5.60200@iki.fi> Date: Tue, 24 Feb 2009 21:51:01 +0200 From: Veikko Eeva User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: mmox@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:50:37 -0000 > If this is a request to limit what topics will be discussed by MMOX, can we please cut LLSD, OGP, and HyperGrid out of the discussion? I've posted my critiques of both to this mailing list and I feel that using another IDL such as Google Protocol Buffers, and starting over from scratch for cross-domain communication would be in the better interest of the virtual world interop. HyperGrid is another implementation of the same trust map proposal of OGP (with different default settings), and no one has suggested that they will be submitting it as a proposal. Agreed. I haven't read these, but seems to be in the same vein as mine. I feel the real issues are about digital rights management, asset management, authentication and things like that. Not even the kinds of virtual worlds more than deciding what kinds of interactions are supported. For that I would propose having a handshaking to establish the most appropriate way of communication and otherwise keep it with, for instance in in some TLV protocol. In that way expansion is guaranteed and a most way of interaction can be chosen. That would allow reaping the benefits of decades of engineering experience and decades of engineering experience yet to come (and possibly avoid straming tons of XML makes the most limited resource, bandwidth, even more limited. :-)). -- Veikko E. From jwatte@gmail.com Tue Feb 24 11:58:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEC303A6874 for ; Tue, 24 Feb 2009 11:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDRp8eX3I4i4 for ; Tue, 24 Feb 2009 11:58:20 -0800 (PST) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id C65703A657C for ; Tue, 24 Feb 2009 11:58:19 -0800 (PST) Received: by gxk7 with SMTP id 7so2740263gxk.13 for ; Tue, 24 Feb 2009 11:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=RQ1Kh8AbriSmcyOfcUWHfCQagwXfSm5XJQqM9okUC64=; b=uQILBKZKx+edX5T5lQI/cENnaSELh9k30HB9YnEkly7oHxsOe4InUQCTz7RTaFVW0Q K0hzJvYtALMDgsxgT8qG6Mu5e62lPXzgaKp8RHGSJBtOBv8/Alt4OBHwwy79VEDIQNOb M8QA0z8Q/K+Ajx2inoiFw6rUBefMnVGrEwvrA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=nIwvX6jO60c/SOneZYryEgTWYBQ3/IRDHGJlcXaHvGVQ799vm4Az4WTT87pIvf0+VY U1XuRQUcVscW34yV1jFXF5tyiKc/rNwYzSVXQHQs1uTolUt9kbrD1uAkp6MTSl//wYJl jVh9R7G0H4bAjKfvCga6VOydoAan7BqnRxCKs= Received: by 10.101.67.11 with SMTP id u11mr176752ank.16.1235505519012; Tue, 24 Feb 2009 11:58:39 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c9sm103307ana.33.2009.02.24.11.58.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 11:58:38 -0800 (PST) Message-ID: <49A4516C.5060906@gmail.com> Date: Tue, 24 Feb 2009 11:58:36 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> In-Reply-To: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 19:58:20 -0000 Meadhbh Hamrick (Infinity) wrote: > so i ask.. is it appropriate to limit the discussion here to the MMOX > Charter, LLSD, OGP and HyperGrid with occasional reference to the IETF > IPR Disclosure Policy? > No, because neither OGP nor HyperGrid is suitably vendor/solution neutral at this point. And, to get to what ought to be vendor neutral interoperability, we first need to define what that is. The ability to tunnel Second Life derived client/server stream data in an open container is probably not it. The argument "it's already implemented" can be said about many things. The Quake protocol is already implemented, and has been used for a lot of client/server interoperability. OLIVE has at least three interoperability protocols implemented and in use by paying customers (DIS, HLA, and a non-published entity protocol). The point is to examine each possible candidate for applicability to open, vendor-neutral interoperability that enables applications that currently are not enabled. Then make a determination of effort/benefit for each, and go from there towards something that has "rough consensus" (whatever that means). > > * why do we care about OLIVE, which is a proprietary protocol with > a single implementation? Because it is one of many, many virtual worlds in existence, and we are committed to providing good value to our customers. We believe this includes interoperability. Are you saying that your view of interoperability is "my way or the highway"? > * OGP (Open Grid Protocol) Is there a later published proposal than version 4 on the Second Life MMOX Wiki? Anyway, if that is your approach, then I think a lot of us who are not from OpenSim or other Second Life derived technology should simply withdraw from participation. The question then is why task it under the IETF, when you could probably do it faster and easier within the Second Life AWG? Sincerely, jw From jwatte@gmail.com Tue Feb 24 12:18:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6C63A68B2 for ; Tue, 24 Feb 2009 12:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=-1.292, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fg1C7568FRh for ; Tue, 24 Feb 2009 12:18:52 -0800 (PST) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id C2B7C3A689F for ; Tue, 24 Feb 2009 12:18:51 -0800 (PST) Received: by gxk7 with SMTP id 7so2747784gxk.13 for ; Tue, 24 Feb 2009 12:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=so0OsS2r1MGDnh3rGrFS3BkFfRTOE6bCiLQi6v/02Kk=; b=EBJAHu7KOKt0/0NM3FNvgxIhtAFOKy8/E2+RfWgCNLJ0MfzReyIrD/HOaQCj+I7MDf lLxKCPOWNVsO75dGUg8fkH5iXuCE5iRH4apFsEI8KIj8jev5KrEC8/xC1lri+z7aWu+h VjLfl1BXJB3hD074zmkEGsGyr0VvW1B0XajT8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=JKiIQ2sFUI6+46gqRV3T5ETz2xayKcWzS2Ry2whRa7YGp2j51xYchU/GT6u1kIcdVJ 1mPBHmm/V5UhoQ/2EV3g7lDfRNk301RntxUKSmFlZnDL0uDD+NOtu9CJdUHwj5GWN+JQ 7KHAwcxMFPRo8g7O36aYk+bYp2fUInU5nXKHE= Received: by 10.100.153.6 with SMTP id a6mr132230ane.76.1235506749804; Tue, 24 Feb 2009 12:19:09 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c9sm3051100ana.53.2009.02.24.12.19.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 12:19:09 -0800 (PST) Message-ID: <49A4563A.5060008@gmail.com> Date: Tue, 24 Feb 2009 12:19:06 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Compact Binary Serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 20:18:53 -0000 Catherine Pfeffer wrote: > (in the order x, y, z, s and not math's order s, x, y, z, that's one > of Second Life's strangenesses) > They are in good hands. Direct3D, OLIVE, and a lot of other 3D systems use XYZW. It's a bit like the question of row vectors on the left (D3D) or column vectors on the right (OpenGL). There are two ways to do it, and the world is split about equally. > LLSD (simplifying): > LLIDL says: nose orientation is an array of four fp32s > LLSD data over the wire: 0.5,-0.5,0.5,0.5 > Why do you need to send "floats" at all? > > I see this as another example of "Yeah, that's strange XML, but it > maps 1:1 to a nice and natural binary serialization" :-(. > I think the binary serialization in LLSD is too verbose. My suggestion was to allow the SD language to express type information to the point where you can assume the data types from the context. For example, to update properties on an object, you would need to send, in binary, something like: ( ) * "number-of-updates" is a small integer, so will typically fit in a byte. "property-id" is a small integer in the context of "object-id" and thus will typically take one byte. "data-for-property" for a quaternion stored as four fp16 is 8 bytes. Thus, the actual storage for this one property (in the context of where it's used) is 9 bytes; the total message size (assuming there is only one property value) is 10 bytes plus the size of an object identifier. Note that "data-for-property" is ONLY the raw data, not with any indication of what that data is. The schema for the entity already describes what that data is, so you don't need to send that with every binary packet you send. Thus, in that form of binary serialization, you optimize for transmission size, which is important for interactive, real-time transmissions. When you want a more "resilient" format, and size doesn't matter, you simply use XML instead. To clarify: object of id has some type. That type has some schema, that maps small-integer property-id values to string-name and data-type. Typically, when you encounter an object, you will understand the type/structure of that object once, but you will see changes to properties many times. And, in systems which have fewer types than objects (which is most systems except for SL, I think), you have additional savings by only needing to encounter a type once, and then that work is re-used for each object of the same type. In this context, the schema for the object type would be described in some data description language. That language could perhaps be one area where something like LLSD would make sense -- but LLSD, as it stands, is not up to the task IMO. Hence, my suggestions (one of which is to support external schema for transfer encoding efficiency). Btw: if you know that you will have the schema when you serialize/de-serialize objects, then the "more natural" XML encoding would also map easily to the internal binary format, because all the data you need about whether things are arrays or ints or whatnot is available through the schema, so the more natural "1,2,3,4" XML serialization would also be possible (and, IMO, desirable). > Now back to your question: "should we move the type information to the > schema, as all people do in XML?". The answer is probably: "no, > because we want to keep a simple 1:1 mapping with the binary > serialization". > But my point is that the binary serialization does not serve the needs of what a binary serialization should do, which is save transmission space. It contains both key and datatype, where the verbose key name is typically inlined instead of sent by reference-to-external-schema. If you can describe things with external schema, then you can save a LOT of transmission space where it matters, which is in the binary serialization. Sincerely, jw From jwatte@gmail.com Tue Feb 24 12:21:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F98B3A68AD for ; Tue, 24 Feb 2009 12:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDXLo3BV1ElM for ; Tue, 24 Feb 2009 12:21:24 -0800 (PST) Received: from ag-out-0708.google.com (ag-out-0708.google.com [72.14.246.246]) by core3.amsl.com (Postfix) with ESMTP id 5869C3A689F for ; Tue, 24 Feb 2009 12:21:24 -0800 (PST) Received: by ag-out-0708.google.com with SMTP id 5so2244405agb.12 for ; Tue, 24 Feb 2009 12:21:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=IbwUhOUV5OWQhIB0YjWnaoL9u9N4pfha1bUjj9EiV2g=; b=C9wgo6qQiQsc74FZjcVTyNRYTOM2sHn1A4MUmQa6GYJWJ/UF1bz3LTfSjNnaC+KQAO tkox7rDb1cFYKnLy9ZW53q+qXA+eUb4k38nq55nzmS7BdcbtXIcdcx+Nc3teLWzd4sT3 8u/bI4D1fn2q8wFZWb9jG3rzBL1zTf9GVWnSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kyOJlVXPPuhz/ENn/7Bf51J6gkbaBMQXMNusIPGwNSno96EAZsskBKpIqwZkRI1bAT rK+vtDTxFfPbDbl1cY+wn9pCP1T+AoLAGtBo1VDtRTDXVntnUfgsytv+PqLfzz7xRFX7 4pz9PhVSMFuKy6qZn4Lcc850xT/+Fi2HogWTk= Received: by 10.100.143.14 with SMTP id q14mr172397and.47.1235506903045; Tue, 24 Feb 2009 12:21:43 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c29sm6979664anc.3.2009.02.24.12.21.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 12:21:42 -0800 (PST) Message-ID: <49A456D4.3060602@gmail.com> Date: Tue, 24 Feb 2009 12:21:40 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <49A40ADA.2080309@comlounge.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] xxSD working group? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 20:21:25 -0000 Meadhbh Hamrick (Infinity) wrote: > 3. the charter of this list is rather constrained... it is to attempt > to standardize a protocol that is in wide use (for some definition of > the term "wide".) it I thought we all agreed that the charter was *not* to standardize any particular protocol currently in use, because that's an explicit technology bias. If that is actually the charter, then I know that a lot of people on this list will have to withdraw. Sincerely, jw From wjgeorge@dceo.rutgers.edu Tue Feb 24 12:52:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 151A73A67E6 for ; Tue, 24 Feb 2009 12:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14JJ3lmXqFHM for ; Tue, 24 Feb 2009 12:52:48 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 44F5C3A67AF for ; Tue, 24 Feb 2009 12:52:48 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so2494569ywh.49 for ; Tue, 24 Feb 2009 12:53:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.107.17 with SMTP id f17mr195926anc.51.1235508786151; Tue, 24 Feb 2009 12:53:06 -0800 (PST) Date: Tue, 24 Feb 2009 15:53:06 -0500 Message-ID: <27a487810902241253v1f2c5b82q9dac1cd39e34ec07@mail.gmail.com> From: William George To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016e644d50450c1c80463b04e08 Subject: [mmox] Time to rethink the commercial angle X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 20:52:49 -0000 --0016e644d50450c1c80463b04e08 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In order to sidestep some of the thorny (and circular) discussions on property rights, as well as the petty technical arguments backed by "customer interests", I propose that only worlds with free access and only unencumbered objects be allowed to interoperate, at least to start. The commercial objectives are taking up too much of _my_ limited bandwidth. Remember when the internet did not have any commercial interests? This was up until 1994, not really that long ago. Waka --0016e644d50450c1c80463b04e08 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In order to sidestep some of the thorny (and circular) discussions on prope= rty rights, as well as the petty technical arguments backed by "custom= er interests", I propose that only worlds with free access and only un= encumbered objects be allowed to interoperate, at least to start.

The commercial objectives are taking up too much of=A0 _my_ limited ban= dwidth.

Remember when the internet did not have any commercial inter= ests? This was up until 1994, not really that long ago.

Waka

--0016e644d50450c1c80463b04e08-- From lenglish5@cox.net Tue Feb 24 12:58:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7984F3A6403 for ; Tue, 24 Feb 2009 12:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.844 X-Spam-Level: X-Spam-Status: No, score=0.844 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WneNDQgiYDVL for ; Tue, 24 Feb 2009 12:58:11 -0800 (PST) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id BFE2C3A697D for ; Tue, 24 Feb 2009 12:57:58 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090224205815.XJEM12540.fed1rmmtao106.cox.net@fed1rmimpo02.cox.net>; Tue, 24 Feb 2009 15:58:15 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id KwyF1b00B4N6T0Q04wyFbl; Tue, 24 Feb 2009 15:58:16 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=1L0mOPdZtdlSQioZjM8A:9 a=zdXwaV3Coh6r3BFfzu6N5mvzHJAA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <49A45F67.6040506@cox.net> Date: Tue, 24 Feb 2009 13:58:15 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <49A44928.10307@gmail.com> In-Reply-To: <49A44928.10307@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 20:58:12 -0000 Jon Watte wrote: > > > Personally, I think it's too early to really worry about it too much. > I first want rough consensus on the model we're using -- I think most, > but not all, participants on the list now understand that > interoperating virtutal world objects practically require simulation > hosts to talk to other simulation hosts. which simulation hosts in Croquet/Qwaq are we talking about? > I also think that most participants understand that a specified > client/server protocol would not actually solve interoperability > between disparate simulation systems. Depends on how disparate.... Seems to me that the forterra strategy, as implemented in SL, would require sufficient extra server sapce to accommodate all 85000+ concurrent users visiting 85000+ different simulators at the same time.... > > But how do we actually define and determine "rough consensus"? Perhaps > coming up with some metric for that would be a good first step. > How loud the humming is, I understand. Lawson From lenglish5@cox.net Tue Feb 24 13:01:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932CF3A6922 for ; Tue, 24 Feb 2009 13:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.854 X-Spam-Level: X-Spam-Status: No, score=0.854 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl0vDTopct5x for ; Tue, 24 Feb 2009 13:01:24 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id D70C23A6403 for ; Tue, 24 Feb 2009 13:01:23 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090224210142.FXUR4363.fed1rmmtao103.cox.net@fed1rmimpo02.cox.net>; Tue, 24 Feb 2009 16:01:42 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id Kx1g1b00G4N6T0Q04x1gg3; Tue, 24 Feb 2009 16:01:40 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=Z8KEVYD-VSEweMoqA2gA:9 a=n2T1_QMgRWl4rTflX-1L7zuBe2QA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <49A46034.4080201@cox.net> Date: Tue, 24 Feb 2009 14:01:40 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <49A40ADA.2080309@comlounge.net> <49A456D4.3060602@gmail.com> In-Reply-To: <49A456D4.3060602@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] xxSD working group? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:01:24 -0000 Jon Watte wrote: > Meadhbh Hamrick (Infinity) wrote: >> 3. the charter of this list is rather constrained... it is to attempt >> to standardize a protocol that is in wide use (for some definition of >> the term "wide".) it > > I thought we all agreed that the charter was *not* to standardize any > particular protocol currently in use, because that's an explicit > technology bias. > If that is actually the charter, then I know that a lot of people on > this list will have to withdraw. > > > Sincerely, > > jw > Does the IETF make up new protocols from scratch, generally? Thought "working/implemented code" was part of the deal. L From lenglish5@cox.net Tue Feb 24 13:09:42 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FA043A6403 for ; Tue, 24 Feb 2009 13:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.863 X-Spam-Level: X-Spam-Status: No, score=0.863 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W50Vlx9tOYKp for ; Tue, 24 Feb 2009 13:09:41 -0800 (PST) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id A2A8B3A693E for ; Tue, 24 Feb 2009 13:09:41 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090224211000.LIGM2948.fed1rmmtao101.cox.net@fed1rmimpo01.cox.net>; Tue, 24 Feb 2009 16:10:00 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id KxA01b00P4N6T0Q03xA0KE; Tue, 24 Feb 2009 16:10:01 -0500 X-Authority-Analysis: v=1.0 c=1 a=R9HNfHEklgIA:10 a=REZHN6UhnksA:10 a=Wajolswj7cQA:10 a=d6JQF2MkfAu_9zOoG9IA:9 a=rg-SKf3U6qxdehqkXfHPSSX0EJ0A:4 a=MInBT2ynV54A:10 X-CM-Score: 0.00 Message-ID: <49A46228.2030207@cox.net> Date: Tue, 24 Feb 2009 14:10:00 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: William George References: <27a487810902241253v1f2c5b82q9dac1cd39e34ec07@mail.gmail.com> In-Reply-To: <27a487810902241253v1f2c5b82q9dac1cd39e34ec07@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Time to rethink the commercial angle X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:09:42 -0000 William George wrote: > In order to sidestep some of the thorny (and circular) discussions on > property rights, as well as the petty technical arguments backed by > "customer interests", I propose that only worlds with free access and > only unencumbered objects be allowed to interoperate, at least to start. > > The commercial objectives are taking up too much of _my_ limited > bandwidth. > > Remember when the internet did not have any commercial interests? This > was up until 1994, not really that long ago. That can be done by policy on the server side as has already been shown with the Gridnauts grid, where the only thing preserved during the teleport is the name of the avatar simply because the asset server interface isn't defined for cross-world teleport. Even if asset-sharing was defined, server could have a flag set so that only 'intergrid-creative-commons" assets would be released to other servers, so the issue of NON-sharing isn't a big deal to implement. It's the sharing of assets while preserving meta-data such as permissions/copyright that requires the thought. Lawson From jwatte@gmail.com Tue Feb 24 13:18:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF5073A69E5 for ; Tue, 24 Feb 2009 13:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xkRU+bMo5EB for ; Tue, 24 Feb 2009 13:18:51 -0800 (PST) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id DCFE63A68CD for ; Tue, 24 Feb 2009 13:18:50 -0800 (PST) Received: by gxk7 with SMTP id 7so2770838gxk.13 for ; Tue, 24 Feb 2009 13:19:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=zJTj2M4n61jpEpcAx6BHBfVxd4o6COAGzELHLtaAXN8=; b=HTyUMeYh1fd7K2dyabETr50NOQvKLf1auMKwR/jNNokAWdoBRNyVhK61loTBVJHwS1 KU5ihlVaCi+v8oKQly0dMXlqaDMdOKJINV/8ynh2TGc5J9TcwDLBhc1ckMjKOqBXJnkC AWfeJOjTkW/SWJ0/cpvBEPwYVI2cFuoefEzFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=UfWW0Oh6xaIX8Rcx7OfVmPRTik3fYFq2EWeB1NN4XWSSW2iy1H3si2gahxP2Qsra+p r9wdgFKD1U+Nduk+nhgIu5ev9cBp8pgsLHJVdkw07pXAGyFvrTBGwsjluBWyHzbm/naC yrcvcq9zCC5r5y+ZykUb/UssXxMe1cBYO2/dU= Received: by 10.100.106.12 with SMTP id e12mr163275anc.18.1235510348790; Tue, 24 Feb 2009 13:19:08 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d38sm10129120and.49.2009.02.24.13.19.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 13:19:08 -0800 (PST) Message-ID: <49A46448.4020409@gmail.com> Date: Tue, 24 Feb 2009 13:19:04 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <49A44928.10307@gmail.com> <49A45F67.6040506@cox.net> In-Reply-To: <49A45F67.6040506@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:18:52 -0000 Lawson English wrote: > Jon Watte wrote: >> >> >> Personally, I think it's too early to really worry about it too much. >> I first want rough consensus on the model we're using -- I think >> most, but not all, participants on the list now understand that >> interoperating virtutal world objects practically require simulation >> hosts to talk to other simulation hosts. > > > which simulation hosts in Croquet/Qwaq are we talking about? > > In Croquet, each participating peer would be a simulation host, authoritative for the objects that they introduce into the shared world. > > Seems to me that the forterra strategy, as implemented in SL, would > require sufficient extra server sapce to accommodate all 85000+ > concurrent users visiting 85000+ different simulators at the same > time.... > We already discussed this, if you look in the archives. That is not true. If any Second Life customer interoperates with some other system, then it is true that the SL servers will have to funnel object information through their system to their clients and their objects, so that the clients can see the other systems, and the objects can interoperate with the objects from the other system. This is not a large additional load, because the simulation of the non-Second-Life objects is done by other hosts. As long as one Second Life customer can only be in one place at a time, there will only need to be one avatar simulated by the Second Life servers, which is pretty much what they're already providing. Sincerely, jw From jwatte@gmail.com Tue Feb 24 13:20:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6223A6A1C for ; Tue, 24 Feb 2009 13:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVk-qoJzaWaK for ; Tue, 24 Feb 2009 13:20:18 -0800 (PST) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id 6A2B23A68CD for ; Tue, 24 Feb 2009 13:20:18 -0800 (PST) Received: by gxk7 with SMTP id 7so2771298gxk.13 for ; Tue, 24 Feb 2009 13:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=aixcP1FBbensbv/MliJkA59rQNzPETgzijBL4adyfGc=; b=otP2bEce4Z+dOdcgEJIaMWYraLs/jPidKTIi7PY18D+fvyrEUy5GiSHPVeqgcf6FPK /tU+/qer9kKy2QS3WodvlCH/6ERJNPvo0Kex9b4dlr1dCGmSDeNOAdNImh15O/Iz0Dla +WftDsKV+ey4OadcWHDO9um7MC4/HRJ7wNzzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kDoj5iMNKgR4SN7s1kh1YRj2eaga30Cc33cnWD6cbh8Jp70cMJS8nZtKtVsSIBZiPP fus/4wWptM0fnl99Vr/uNbMAEDZTZLjyURbIBlQKmr0+wHUjfTSXVn6ydqQfGRuXywBg 0gDqFOVomkX1rhbpvg+KIMaCol02T4f7tn/UI= Received: by 10.100.216.10 with SMTP id o10mr271731ang.86.1235510436334; Tue, 24 Feb 2009 13:20:36 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c29sm11767858anc.23.2009.02.24.13.20.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 13:20:35 -0800 (PST) Message-ID: <49A464A1.1020506@gmail.com> Date: Tue, 24 Feb 2009 13:20:33 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <49A40ADA.2080309@comlounge.net> <49A456D4.3060602@gmail.com> <49A46034.4080201@cox.net> In-Reply-To: <49A46034.4080201@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] xxSD working group? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:20:19 -0000 Lawson English wrote: > Does the IETF make up new protocols from scratch, generally? Thought > "working/implemented code" was part of the deal. > Sounds like I should formally propose our internal interoperability protocol, then. I'd rather not propose our implementation details as a standard, but instead work towards something that is more vendor neutral, though. Sincerely, jw From lenglish5@cox.net Tue Feb 24 13:26:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5EDB3A6874 for ; Tue, 24 Feb 2009 13:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.872 X-Spam-Level: X-Spam-Status: No, score=0.872 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxRIbTUuSsvx for ; Tue, 24 Feb 2009 13:26:23 -0800 (PST) Received: from fed1rmmtao105.cox.net (fed1rmmtao105.cox.net [68.230.241.41]) by core3.amsl.com (Postfix) with ESMTP id DBE4E3A67E6 for ; Tue, 24 Feb 2009 13:26:22 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090224212641.RJYJ15318.fed1rmmtao105.cox.net@fed1rmimpo02.cox.net>; Tue, 24 Feb 2009 16:26:41 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id KxSh1b0094N6T0Q04xShPx; Tue, 24 Feb 2009 16:26:41 -0500 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=BU7gY-_inwJ40qjL8IQA:9 a=YfJgFK9viDKMk0V69_oA:7 a=ABghouAS2EnQXUuo3KXvFN2X-_gA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <49A46611.8050706@cox.net> Date: Tue, 24 Feb 2009 14:26:41 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <49A44928.10307@gmail.com> <49A45F67.6040506@cox.net> <49A46448.4020409@gmail.com> In-Reply-To: <49A46448.4020409@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:26:23 -0000 Jon Watte wrote: > Lawson English wrote: >> Jon Watte wrote: >>> >>> >>> Personally, I think it's too early to really worry about it too >>> much. I first want rough consensus on the model we're using -- I >>> think most, but not all, participants on the list now understand >>> that interoperating virtutal world objects practically require >>> simulation hosts to talk to other simulation hosts. >> >> >> which simulation hosts in Croquet/Qwaq are we talking about? >> >> > > In Croquet, each participating peer would be a simulation host, > authoritative for the objects that they introduce into the shared world. > > >> >> Seems to me that the forterra strategy, as implemented in SL, would >> require sufficient extra server sapce to accommodate all 85000+ >> concurrent users visiting 85000+ different simulators at the same >> time.... >> > > We already discussed this, if you look in the archives. That is not > true. If any Second Life customer interoperates with some other > system, then it is true that the SL servers will have to funnel object > information through their system to their clients and their objects, > so that the clients can see the other systems, and the objects can > interoperate with the objects from the other system. This is not a > large additional load, because the simulation of the non-Second-Life > objects is done by other hosts. > As long as one Second Life customer can only be in one place at a > time, there will only need to be one avatar simulated by the Second > Life servers, which is pretty much what they're already providing. > Which non-SL objects are we talking about? scripted behavior can be added to any SL object or objects. Are you suggesting that the SL simulator handle the scripted i/o from 15,000 objects living in another sim each with potentially hundreds of active scripts? Lawson From lisa.dusseault@gmail.com Tue Feb 24 13:43:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85ECE3A6A1E for ; Tue, 24 Feb 2009 13:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVPBmvQsproI for ; Tue, 24 Feb 2009 13:43:45 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id 79FAB28C102 for ; Tue, 24 Feb 2009 13:43:45 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2483386rvb.49 for ; Tue, 24 Feb 2009 13:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VQojdDNI/kJORRK8ZLf1tqd+lTG9vshOE+NWEm0siC0=; b=q5T0B2wbvRcWshcrTdP7X8hsl0R6GVZCL6wUVY6qH9AwmLCucxtLZ9jIm30cNTYoqz FQZ9/IpbKsIRszVO4da9I+yE/PgHrJxpe3iWvpd7TgQMbPMurWitDEfYB8goUG9B2WtD /1SEehiktaJeu2N7VzZ+/zq3F1HVvULErHr2w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g4J37WcliFEhgkYAobHp9KAInCg2UovV/Dib5OuqaxokHoxtDNLIf3Ii8FFNun9DMA wPC7W72qtum1MVYgDtTInUyN4J4aiIlI/iGEJZNdo0jOIP0qz6dB0muXSfnSuF08OqDB MH8B05/6Jv4zAOzsNVjUPbFGAu4muZQTCdN8w= MIME-Version: 1.0 Received: by 10.140.144.6 with SMTP id r6mr2782807rvd.185.1235511844250; Tue, 24 Feb 2009 13:44:04 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2009 13:44:04 -0800 Message-ID: From: Lisa Dusseault To: Catherine Pfeffer Content-Type: multipart/alternative; boundary=000e0cd2296097a5a70463b1042d Cc: mmox@ietf.org Subject: Re: [mmox] Requirements for new xxSD specification X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:43:46 -0000 --000e0cd2296097a5a70463b1042d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Feb 24, 2009 at 7:29 AM, Catherine Pfeffer wrote: > Infinity wrote: > > so my response would be: > > 1.a. can we look at the effect before making this change? my > > suspicion is that message sizes will be much more affected by turning > > on compressed content encoding than with the change from one DTD to > > another. > > Of course. Whatever we come up with, it must meet the following > requirements : > 1 - be easy to validate with a schema or DTD This is something we (in IETF) have found to be a *drawback* in an extensible standard. We've hesitated over even providing DTDs in some cases, worried that implementors would validate incoming messages against the DTD, and drop messages that didn't validate, even ones that had been extended according to a new standard. The example I have the most familiarity with is WebDAV. In a response to a query to get the properties of a file in WebDAV, you might see: http://www.example.com/file Box type A J.J. Johnson HTTP/1.1 200 OK The specification says that anything inside the 'response' element should be ignored if not understood, but if the 'href' element is there it contains the file address and if the 'propstat' element is there it contains a number of properties with the same status. ...etc... Any element inside the 'prop' element is a property name and inside that element is the property value. Thus, the list of XML elements you would see inside the 'prop' element can change for any resource or at any time and the recipient still knows what it means. This is reasonably concise (for XML which is not saying much) and extensible as long as recipients follow the rules of ignoring unknown elements in some places and treating them as property names in other places. However, it is NOT amenable to using DTDs, XML Schema or any form of restrictive validation. Someday, somebody could come up with a new metalanguage that does a better job of this for XML. RelaxNG is a step in that direction. Because of the separation between XML and the various description or schema languages that work for XML, an argument against or for a description or schema language is not the same thing as an argument for or against XML. Lisa --000e0cd2296097a5a70463b1042d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 24, 2009 at 7:29 AM, Catheri= ne Pfeffer <= cathypfeffer@gmail.com> wrote:
Infinity wrote:
> so my response would be:
>=A0=A0=A0=A0=A0=A0= =A0 1.a. can we look at the effect before making this change? my =A0
>= ; suspicion is that message sizes will be much more affected by turning =A0=
> on compressed content encoding than with the change from one DTD t= o =A0
> another.

Of course. Whatever we come up with, it must meet the = following requirements :
1 - be easy to validate with a schema or DTD

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

The example I have the most familiarity with is WebDAV.=A0 In a respons= e to a query to get the properties of a file in WebDAV, you might see:
=
=A0=A0=A0=A0 <D:response xmlns:R=3D"http://ns.example.com/boxschema/" xmlns:D=3D&quo= t;DAV:">
=A0=A0=A0=A0=A0=A0=A0=A0 <D:href>http://www.example.com/file</D:href>
=A0=A0=A0=A0=A0=A0=A0= =A0 <D:propstat>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <D:prop>
= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <R:bigboxtype>Box type A</R:b= igboxtype>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <R:author><R:Name>J.J. Joh= nson</R:Name></R:author>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <= /D:prop>
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <D:status>HTTP/1.1 200 = OK</D:status>
=A0=A0=A0=A0=A0=A0=A0=A0 </D:propstat>
=A0= =A0=A0 </D:response>

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

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

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

Someday, somebody could come up with a new metalanguage that does a bet= ter job of this for XML.=A0 RelaxNG is a step in that direction.=A0 Because= of the separation between XML and the various description or schema langua= ges that work for XML, an argument against or for a description or schema l= anguage is not the same thing as an argument for or against XML.

Lisa

--000e0cd2296097a5a70463b1042d-- From lisa.dusseault@gmail.com Tue Feb 24 13:51:43 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7C0E28C120 for ; Tue, 24 Feb 2009 13:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqr+rqlsdePL for ; Tue, 24 Feb 2009 13:51:42 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 9D1CE28C115 for ; Tue, 24 Feb 2009 13:51:42 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2485960rvb.49 for ; Tue, 24 Feb 2009 13:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kvcbgcHnnCm18SgfZN+ucy+F1Sy59kcGW9U59ltO/SE=; b=AJW8udMVxK9c2VoYBvuE/rqXR6vChW/hJ26oF//54/jeXNxctrwWKrVFxLF2U6G1As YieFGA5CEefVwYWIsRYYU3lcMuptmDPMcYLBJzOitNTWmxlDI00d7nsAYsu1pBzd/Ugl pQjmkZpxzPbmx5NTtyluU/Gei9fqTa8GNkZFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gaYp+8NQbyCdA64l225y5m7PkMvxo55QVStLxdo4QvlO2/p5RQQA5Ib2MOOiJOPNh9 Xm726xDhu7OTV2Vp6j/VPEBToVqO7d8ulySPNWqDux1o9Pgp4VDgwgiAnzJukwqEE1EB p7eudzsKHONNdnFRbcfTo0CbZfUu6ZjD/tJjM= MIME-Version: 1.0 Received: by 10.141.146.4 with SMTP id y4mr2792803rvn.88.1235512321351; Tue, 24 Feb 2009 13:52:01 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2009 13:52:01 -0800 Message-ID: From: Lisa Dusseault To: Catherine Pfeffer Content-Type: multipart/alternative; boundary=000e0cd1461407a0f20463b121a7 Cc: mmox@ietf.org Subject: Re: [mmox] Formalizing my proposal X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 21:51:43 -0000 --000e0cd1461407a0f20463b121a7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I completely agree with this. We'd need a pretty good reason to standardize three serializations of the same data up front. We'd also need a careful model for who needs to support all, and who can choose which to support, and how negotiation is done. It's all a *lot* more standards work and multiplies risks of interop failures. That said, there is certainly good engineering behind having the layering abstractions, and in some cases multiple serializations are worthwhile. After 10 years of being in its own format, there's some effort to do an XML version of iCalendar for inviting people to meetings. The problem is no negotiation support in the tools that use iCalendar. Lisa On Tue, Feb 24, 2009 at 11:04 AM, Catherine Pfeffer wrote: > Infinity wrote: > > 1. can you please submit your proposal? > > Sure. I'll submit a proposal that makes the XML serialization better, > although it would assume: > 1)- that LLSD is what we need for lower layer > 2) that we would stick to three serializations for LLSD and not just one, > leading to clumsy XML > > both points are still not certainties in my mind. But I'll send the > formalized proposal as you asked it. > > > most of the XML LLSD is sent over HTTPS, > > which might explain why you can't see it in wireshark > > Aaah, Ok, thanks for the tip! ;-) > > > 6. the reason we separate the serialization from the protocol > > definition is we want to avoid having to add "binary serialization", > > "json serialization" and "xml serialization" sections to each defined > > protocol interaction. > > Yes, and that leads to a XML serialization that does not take all the > advantage of what can be done in XML, and that takes a lot of bandwidth. > > Again, why would we need three serializations when one is just enough? Not > saying that it's just 1/3rd of the implementation effort... > > > I think there's a history of people defining protocols > > using relatively "high level" abstractions, then providing mechanistic > > technique for generating the "octets over the wire." > > That's correct, it's nice to think in abstract terms, and then map the > result to a given implementation. That does not mean you need three > implementations... > > > 7. i really like the idea of using LLSD to represent meshes, link-sets > > of prims, or even 2d SVG representations of avatars and objects. > > ... which means, in XML, that we could not re-use existing meshes or SVG > XML dialects just by changing the namespace, but that we would have to > "convert" everything to LLSD. > > While this would certainly work, it sounds to me like a lot of efforts, > while simply mixing > vw: > and > svg: > namespaces in one single file could do the trick. Otherwise, you'd first > have to define how SVG remaps to LLSD, then implement it. > > XML namespaces are precisely offering this ability to mix different type of > data from different standards without ambiguity and without any need to > remap one standard into the other. > > > -- > Cathy > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --000e0cd1461407a0f20463b121a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I completely agree with this.=A0 We'd need a pretty good reason to stan= dardize three serializations of the same data up front.=A0 We'd also ne= ed a careful model for who needs to support all, and who can choose which t= o support, and how negotiation is done.=A0 It's all a *lot* more standa= rds work and multiplies risks of interop failures.=A0

That said, there is certainly good engineering behind having the layeri= ng abstractions, and in some cases multiple serializations are worthwhile.= =A0 After 10 years of being in its own format, there's some effort to d= o an XML version of iCalendar for inviting people to meetings.=A0 The probl= em is no negotiation support in the tools that use iCalendar.

Lisa

On Tue, Feb 24, 2009 at 11:04 AM= , Catherine Pfeffer <cathypfeffer@gmail.com> wrote:
Infinity wrote:
> 1. can you please submit your proposal?

Sure= . I'll submit a proposal that makes the XML serialization better, altho= ugh it would assume:
1)- that LLSD is what we need for lower layer
2) that we would stick to three serializations for LLSD and not just one, l= eading to clumsy XML

both points are still not certainties in my min= d. But I'll send the formalized proposal as you asked it.

> m= ost of the XML LLSD is sent over HTTPS, =A0
> which might explain why you can't see it in wireshark

Aaah, Ok, thanks for the tip! ;-)

> 6. the reason we sep= arate the serialization from the protocol =A0
> definition is we want= to avoid having to add "binary serialization", =A0
> "json serialization" and "xml serialization" secti= ons to each defined =A0
> protocol interaction.

Yes, and that = leads to a XML serialization that does not take all the advantage of what c= an be done in XML, and that takes a lot of bandwidth.

Again, why would we need three serializations when one is just enough? = Not saying that it's just 1/3rd of the implementation effort...

= > I think there's a history of people defining protocols =A0
>= using relatively "high level" abstractions, then providing mecha= nistic =A0
> technique for generating the "octets over the wire."
That's correct, it's nice to think in abstract terms, and then map= the result to a given implementation. That does not mean you need three im= plementations...

> 7. i really like the idea of using LLSD to represent meshes, link-= sets =A0
> of prims, or even 2d SVG representations of avatars and ob= jects.

... which means, in XML, that we could not re-use existing me= shes or SVG XML dialects just by changing the namespace, but that we would = have to "convert" everything to LLSD.

While this would certainly work, it sounds to me like a lot of efforts,= while simply mixing
=A0=A0=A0=A0=A0=A0=A0 vw:
and
=A0=A0=A0=A0=A0= =A0=A0 svg:
namespaces in one single file could do the trick. Otherwise,= you'd first have to define how SVG remaps to LLSD, then implement it.<= br>
XML namespaces are precisely offering this ability to mix different typ= e of data from different standards without ambiguity and without any need t= o remap one standard into the other.


--
Cathy

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--000e0cd1461407a0f20463b121a7-- From jwatte@gmail.com Tue Feb 24 14:25:28 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF44B3A66B4 for ; Tue, 24 Feb 2009 14:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7PPKAGIek97 for ; Tue, 24 Feb 2009 14:25:28 -0800 (PST) Received: from mail-gx0-f163.google.com (mail-gx0-f163.google.com [209.85.217.163]) by core3.amsl.com (Postfix) with ESMTP id C433F28C13C for ; Tue, 24 Feb 2009 14:25:27 -0800 (PST) Received: by gxk7 with SMTP id 7so2792181gxk.13 for ; Tue, 24 Feb 2009 14:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=snPKsdft8yMeeSUJp5T5dch7XSvcPR7ih2rv/kPF0YY=; b=Rvvu4BhLzbvqYVP74oyOhHy1TvsrTyVcQRIYJ5cSlaPsMxi/XpGihGzUEWUBZZlgVJ AQV9U9MZDm6aJfzidj/pnBJa+9zhpEEzAfjXFrrZ/T9JqqahxoTRxZfFNHwDoOgv6OdG vgcZ9RK/139HdkEJzn8cqWI0/QdRQnwx4GE7E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=h5jxnyM2M11IYLZ6/CGi0aqQX4nnHeIFgaIMD1p+R/vTF16wPQao63NK33mzYKJowT k+aiZvDD7GxZgGw92a6cVJ1JE+fRoHmH6wPh2YuazxY65IM2o6j38o+h7U24xWRojpMk 1ZgxnlGkycX9MsKdrbzJAU48DQocZz6DVNxBE= Received: by 10.100.196.20 with SMTP id t20mr224729anf.120.1235514345855; Tue, 24 Feb 2009 14:25:45 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b37sm1048842ana.37.2009.02.24.14.25.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 14:25:44 -0800 (PST) Message-ID: <49A473E6.4070709@gmail.com> Date: Tue, 24 Feb 2009 14:25:42 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <49A44928.10307@gmail.com> <49A45F67.6040506@cox.net> <49A46448.4020409@gmail.com> <49A46611.8050706@cox.net> In-Reply-To: <49A46611.8050706@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 22:25:29 -0000 Lawson English wrote: > Which non-SL objects are we talking about? scripted behavior can be > added to any SL object or objects. Are you suggesting that the SL > simulator handle the scripted i/o from 15,000 objects living in > another sim each with potentially hundreds of active scripts? > No, that's exactly what I'm not suggesting. I suggest you actually read the proposal, which does lay this out in some detail. In brief, each system runs its own objects, with its own scripts. Only "proxy" information about the object is funneled through the peer systems, to allow them to make whatever determination they want (or not) about those objects, and present those objects to their users. This keeps simulation of each object on the system where the object originated, which is a requirement, given that some systems script in Java, others in JavaScript, and yet others in C++ and XML. Sincerely, jw From lisa.dusseault@gmail.com Tue Feb 24 14:29:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2C53A66B4 for ; Tue, 24 Feb 2009 14:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.42 X-Spam-Level: X-Spam-Status: No, score=-2.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il6cMq9AJdRQ for ; Tue, 24 Feb 2009 14:29:00 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id C35DA3A69BA for ; Tue, 24 Feb 2009 14:29:00 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so2498566rvb.49 for ; Tue, 24 Feb 2009 14:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Y1yu7YkqNaPm5zySRVH1l8cDYThkYMnopxcUXy0oxEA=; b=wqhdDm9PmeSHxaA+r8AKR+mzaKPExhyaoWKPQsqo1C3GyM5tjOlme4aOX4FMhtot/r l5y3Jy/4oeJlXNC/iykIBh3k7sILqHe2Cx5x66/DfQ/vV3DrsLIBgooImLmw3+z5XBjm eY9IU9+FXyYWRotyD6zGlJ6wexcyHOfPVSm9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MOwxbMu+5x2HJj1I591P4JFij8jSvNGBW+oyLw/Bm7q+exbSmx/3Ue6KosSzh+4F/Z rcVzzSCA46Albz01BaJMyDx5b8siETqhkBaXMGJwAYr4WjCjtlbACykqSlxCDOgD4785 Z9rUROGQ/Qn3m/TM3YOPlMM4lApOz7XkLOPHo= MIME-Version: 1.0 Received: by 10.141.53.4 with SMTP id f4mr2806116rvk.155.1235514560204; Tue, 24 Feb 2009 14:29:20 -0800 (PST) Date: Tue, 24 Feb 2009 14:29:20 -0800 Message-ID: From: Lisa Dusseault To: "mmox@ietf.org" , Barry Leiba Content-Type: multipart/alternative; boundary=000e0cd291ba79d1820463b1a69d Subject: [mmox] List moderator and participation info X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 22:29:01 -0000 --000e0cd291ba79d1820463b1a69d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all, I'm the sponsoring AD for this list and for the MMOX BOF meeting. I've asked Barry Leiba (barryleiba@computer.org) to moderate this list: although we don't have a WG and thus no WG chair, Barry can help people keep on topic and back off from inappropriately heated debate. What's "On topic"? That is decided by the moderator since this is not a WG yet. If you don't like the definition of what's on topic, start your own mailing list and define your own topic. That said, somewhat off-topic conversations are extremely likely to be tolerated as long as they're polite, unrepetitive, and don't overwhelm the main topics (currently BOF preparation, ID submission and charter proposals). A quick note on participation: individuals participate in the IETF, not companies. We have no official differentiation between somebody who works for a company that may or may not benefit from standardization or interoperability, somebody who is representing another organization, and somebody who is acting as a private individual entirely. We have no problems with observers, on list or off. Lisa --000e0cd291ba79d1820463b1a69d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm the sponsoring AD for this list and for the MMOX= BOF meeting.=A0 I've asked Barry Leiba (barryleiba@computer.org) to moderate this list: although w= e don't have a WG and thus no WG chair, Barry can help people keep on t= opic and back off from inappropriately heated debate.

What's "On topic"?=A0 That is decided by the moderator si= nce this is not a WG yet.=A0 If you don't like the definition of what&#= 39;s on topic, start your own mailing list and define your own topic.=A0 Th= at said, somewhat off-topic conversations are extremely likely to be tolera= ted as long as they're polite, unrepetitive, and don't overwhelm th= e main topics (currently BOF preparation, ID submission and charter proposa= ls).

A quick note on participation: individuals participate in the IETF, not= companies.=A0 We have no official differentiation between somebody who wor= ks for a company that may or may not benefit from standardization or intero= perability, somebody who is representing another organization, and somebody= who is acting as a private individual entirely.=A0 We have no problems wit= h observers, on list or off.

Lisa --000e0cd291ba79d1820463b1a69d-- From yesha.sivan@gmail.com Tue Feb 24 14:39:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2520528C1F0 for ; Tue, 24 Feb 2009 14:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFdWuFRcoI9G for ; Tue, 24 Feb 2009 14:39:50 -0800 (PST) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by core3.amsl.com (Postfix) with ESMTP id 9B68D28C1E6 for ; Tue, 24 Feb 2009 14:39:49 -0800 (PST) Received: by mu-out-0910.google.com with SMTP id w9so2014577mue.9 for ; Tue, 24 Feb 2009 14:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=1qDNZbXt7Z43GJWZTFi9qBB6kqoFWCDNvZ7L0EaHARI=; b=gNNKZPouFLIeG+Gx/yEgS6933fOi2vsfgf/KENeNIL5RbcslqAbR0Vfrw9YBKPwrx8 sm6m5epDepBoS63OV3f0dUQ5c+zp41tKFdEe7YML3r2R1aw90WgnRAXfQiVRUvv9ApQ7 4wNmUjxUuDeU+atDTgWYZj8q/Ax7oVdTRPcbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=B3atCC8MSIgZ243/I0Zq7PVJvRLzGhe6wt3yrjv6U6Ux+tq23+UaRZ4cLSn51JJ3Gw pKBo0cwpnaQk8IWIvIl6lr8csHYPL+8raHLxi+brfTpV6l3dT+GgnCS98Hd5jbIewmJa WPQpsxg68n53iLPYv2/NyFpgBjk7l85ZyXg6A= MIME-Version: 1.0 Sender: yesha.sivan@gmail.com Received: by 10.103.221.5 with SMTP id y5mr10409muq.66.1235515207595; Tue, 24 Feb 2009 14:40:07 -0800 (PST) Date: Wed, 25 Feb 2009 00:40:07 +0200 X-Google-Sender-Auth: c11111f045a03069 Message-ID: <3e3ef2f00902241440k3f7450c5w122c99e25bbb8bb8@mail.gmail.com> From: Yesha Sivan To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016367659eb1036340463b1cdd4 Subject: [mmox] Reflections X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 22:39:51 -0000 --0016367659eb1036340463b1cdd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I just wanted to share with the group few ideas: 1. This is a SMART group of people. I have participated in few similar efforts and the knowledge here is wide and deep. 2. my 2 cents: the issue of identity and commerce -- enabling it -- is critical. The long term value of Virtual Worlds is the combination of 3D + Community + Creation + Commerce. (I have written extensively about it just Google "3d3c virtual worlds"). If we DO NOT DEAL WITH IT -- we will fail to being the full potential of this medium. I know it is difficult for some people to appreciate this... arguments like "money will come later" are not acceptable to me. 3. There is a deep fear here among non-SL people that SL will control the process. This is a justified fear. But let's face it -- these people have done an amazing job in the field. >From a public point of view -- if today SL became totally open it will be cool. Yet ...even then... I do want to see some kind of a super central authority (ala http://www.icann.org/) for identity, commerce, money etc. 4. Other standards: yes there are few of them out there (and some of you I work in/for some of them :) -- BUT all good efforts will merge at the end. I'm positive, --Yesha Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual Worlds. --0016367659eb1036340463b1cdd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just wanted to share with the group few ideas:

1.= This is a SMART group of people. I have participated in few similar effort= s and the knowledge here is wide and deep.

2. my 2 cents: the issue = of identity and commerce -- enabling it -- is critical. The long term value= of Virtual Worlds is the combination of
3D + Community + Creation + Commerce. (I have written extensively about it = just Google "3d3c virtual worlds").=C2=A0 If we DO NOT DEAL WITH = IT -- we will fail to being the full potential of this medium. I know it is= difficult for some people to appreciate this... arguments like "money= will come later" are not acceptable to me.

3. There is a deep fear here among non-SL people that SL will control t= he process. This is a justified fear. But let's face it -- these people= have done an amazing job in the field.
From a public point of view -- i= f today SL became totally open it will be cool. Yet ...even then... I do wa= nt to see some kind of a super central authority=C2=A0 (ala http://www.icann.org/)
for identity, commerce, money etc.

4. Other standards: yes there are= few of them out there (and some of you I work in/for some of them :) -- BU= T all good efforts will merge at the end.

I'm positive,

--Yesha

Dr. Yesha Y. Sivan, http://www.dryesha.com; Connecting Real and Virtual Worlds= .
--0016367659eb1036340463b1cdd4-- From mccahill@duke.edu Tue Feb 24 15:17:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C0C3A6B00 for ; Tue, 24 Feb 2009 15:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvJ2PQ1OG8wJ for ; Tue, 24 Feb 2009 15:17:34 -0800 (PST) Received: from smtp.duke.edu (smtp-03.oit.duke.edu [152.3.174.16]) by core3.amsl.com (Postfix) with ESMTP id 82FC23A6AF5 for ; Tue, 24 Feb 2009 15:17:34 -0800 (PST) Received: from smtp.duke.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 695FA81A9; Tue, 24 Feb 2009 18:17:53 -0500 (EST) Received: from [152.3.69.22] (unknown [152.3.69.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.duke.edu (Postfix) with ESMTP id 02DB08081; Tue, 24 Feb 2009 18:17:53 -0500 (EST) Message-Id: <6B85E8A2-831E-43B1-B0AC-C504AB596B26@duke.edu> From: "Mark P. McCahill" To: David W Levine In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 18:17:51 -0500 References: X-Mailer: Apple Mail (2.930.3) X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2009.2.24.231026 Cc: mmox@ietf.org Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 23:17:36 -0000 +1 I really like the approach David is taking here. The first two items: * managing identity * naming and authenticating services in MMOX worlds are prerequisites for getting anywhere with cross-system interoperability, would benefit users of existing systems, and should be achievable in the fairly near term. Understanding how to negotiate these services is the place to start, rather than defining an abstract wire-level protocol, if the intent is to bring something other than Second Life-like worlds into the fold. Mark McCahill On Feb 24, 2009, at 11:04 AM, David W Levine wrote: > > 1. The ability to manage one's identity when interacting in > multiple MMOX spaces. > a. Allowing presence information to be shared and > coordinated across > MMOX spaces > b. Permitting friends lists, and IMs to be shared > across spaces > c. Permitting MMOX spaces to share naming > d. Simple ways of allowing a consistent name, managed > by the user, and > verifiable by other users > e. Single sign on, mediated by multiple spaces, within > the policy constraints > of the spaces > f. A consistent appearance, within the constraints of > the various systems > g. The ability to manage the degree of visibility / > coupling between identities > in MMOX spaces > > Note that for all of these, there is no requirement to couple the > systems together > beyond managing identity, and share presence and IM information. > These use > cases don't speak to how you move between spaces. You may have to > shutdown > your client on one system and start another. This also is not a "You > must enable > this" this is very much a "Make it easy for spaces which want to > enable this to do > it." Also, note that "presence and messaging" speak to user needs, > and consitent > appearance and name (when desired by users) again speeks to meeting > user's > desires. > > 2. The ability for the services in an MMOX world to be named, > and authenticated > a. Services to associate virtual places and the > services which support them > with authentication and administrative domains > b. Services to permit a service to validate the > membership of a remote > service in one or more authentication and administrative > domains > > This is needed so that we can do essentially any of the > interoperability work. > Without some framework which lets us know who we are talking to, it is > impossible to trust the behavior of distributed systems. > > 3. The ability to share content between MMOX spaces > a. Import and Export of content and models (This may > well leverage off of > existing work such as Collada) Static, import/export of > content while not > terribly dramatic is an important part of the value chain of > interoperability > b. Mark up schemes which recognize the existence of > multiple presentation > environments, but permit the sharing of content > i. Shared "type" information for the various > types of graphical > content which MMOX spaces contain > ii. Extensible, with a common registry, so > that we can understand the > types of contents a client can accept, and a > virtual space, or virtual > asset store can be asked to provide > c. A MMOX based, system independent asset addressing > scheme which includes > i. Content negotiation based on 2b > ii. Access Management based on (1) and (2) > > This is, to my mind, the key mid term deliverable > > 4. The affordances in MMOX to permit the creation of micro- > payment economies > a. Appropriate spots defined in MMOX protocols for > cost information > b. Appropriate spots defined in MMOX protocols for > reference to > micropayment systems > > 5. The ability to share "non immersive streams" between spaces > a. Markup to permit the consistent sharing of stream > media such as voice, > and video, with shared start and synchronization > information to permit > "parallel" events between MMOX space > > 6. The ability to express Policy intent between MMOX services > and virtual spaces > a. Places in reserved in the MOX protocols for > expressing policy intent > b. One or more policy languages for expressing policy > > > The solution space: > > Most of the deployed solutions partition the software problem into > the following chunks. > > 1. Some form of a client which permits a user to interact > with the shared experience > 2. Virtual space servers which manage the state of a portion > of virtual space > 3. A set of supporting services used by the virtual space > servers > > Note that exactly how these three large chunks are assembled and the > granular nature of > the services can vary radically, even when serving very similar > environments. Some > environments push a large amount of rendering and management onto > complex clients, > others perform the bulk of rendering in the server portion of the > deployment. Some > implementations combine client and simulation into a single entity > which does some > simulation and some user presentation. Some distribute the > simulation, some centralize it. > > The heart of most of the solutions is managing to accept and merge a > stream of updates, > and then distribute the merged updates back to users. This can > happen at a range of > granularities. The two ends of the spectrum, are, roughly, sending > updates as a fully > merged audio visual stream, which the client merely displays, and > sending low level > changes to a underlying mode, which the client uses to assemble a > complete visual > representation of the scene. Variations include croquet and qwaq > which use an > underlying distributed object model to pass large amounts of > updates, and approaches > such as used by SecondLife and Protonsphere, where voice is managed > in a separate > service, with the merged state service merely letting the voice > service know where the > users are located. > > Closely related, are issues of representation and format of content. > This takes several, > separable forms. Import and Export of material to the core > environment, and, more > problematically, run time representations > > Approach > Our overall approach should be web centric, and web services > oriented. We can, and > should think of sets of related services which can be composed as > part of different > solutions which will enable varying degrees of interoperability. We > can, and should > attempt to provide as web like an approach to function as possible. > Content negotiation, > separation of protocol from security, separation of interface from > implementation and > other techniques. > > Our goal is not to enshrine any single virtual world as the standard > for all MMOX spaces, > but rather create a flexible, extensible set of services which will > allow us to grow larger > and large overlapping sets of capabilities. My expectation is that > we will see a lot of low > hanging fruit in the area of identity, authentication, authorization > and presence > management (Where a user is, and allowing messaging to them across > MMOX spaeces) > and initially, we will find a lot of format and content area > addressed by gateways, > markup, and content negotiation. I see nothing wrong with having a > URI which refers to > "A pretty maple tree with fall colors" which provides a way to fetch > the "Collada Style > version" the "3dMax Mesh version" the "Linden Lab 1.2 sculpty spec > version" such that > a virtual space can select, through content negotiation the one most > useful to it. > > We get value, when we have consistent ways of referring to all the > various forms of > content, and we get more value when we have ways of using existing > content negotiation > to allow a web light selection of an appropriate form. It is equally > possible to imagine > negotiating between a client and a virtual space, the desired form > of objects. There are > some deep challenges lurking, such as when two different approaches > have radically > different > > What I would encourage us, as a mailing list to do, is look through > the problem > statement, and interoperability goals I've put together here. They > are an attempt to > capture the various sentiments in the ongoing discussion. I am sure > I have missed points, > and I am sure some people will disagree with some of the points I > have made. > > I would ask people to look for "No, you missed X" and "Hey, I don't > think Y" is true. I > will attempt to capture all of those, and revise the document, until > we think it represents > something close to the general group consensus. (I am not looking > for 100% consensus, > but a "Yeah, this captures most of what we're trying to do." With > that in hand, I would > suggest we could then begin to enumerate the specific services and > markups we need to > support our goals, and begin to flesh out use cases to help us > understand the goals and > services. > > I do not expect this to yield a set of specs which Linden Lab, or > OpenSim, Or any one > virtual world vendor or project would implement whole. What I expect > it to yield is a set > of specs, which can be combined with existing projects and code > bases to drive us > towards a more interoperable future. > > Out of scope > > I also want to begin to accumulate a short list of "No, this is out > of scope" assertions > > 1. We will provide all the affordances necessary to permit a > broad range of > interaction policies. Appropriate policies for various deployed > solutions and > future deployed solutions is out of scope, beyond providing us use > cases which > highlight specific affordances we may wish to consider > 2. Whether or not immersive multi-party spaces are useful and > which specific > capabilities are required is out of scope. We aspire to support a > broad range of > possible capabilities, and we respect that different organizations > will have > different perspectives on what is required. Our goal is to define > broad, > interoperable frameworks which will enable a range of deployments, > not to define > the one true model for this space > 3. Propose additional statements here > > Closing comments > > I don't think our collective goal can be to take any one existing > spec or solution and > simply declare it the basis for our work going forward. At the same > time, we must base > our work in actually running code, showing real interoperability. > Our goal must be to > build supersets of function, based on existing products and > solutions which demonstrate > real interoperability. > > The IETF favors working code and growing consensus over blank paper > and blue sky > efforts. This is based in a history of success and failure in the > industry when it comes to > building, promoting and succeeding at standards work. Work at the > IETF is grounded in > working code. > > One way forward is to focus on several clusters of work. One: a > clear, broad framework, > which forms the basis for long term broad interoperation. Two: > Capturing the current set > of incompatible and overlapping formats and protocols in use, so > that we can create a > extensible and shared catalog of artifacts for sharing. (eg. "Here > is the canonical, > extensible list of graphic content types you might want to move on > a MMOX transport" > Three grow out proposed solutions such as LLSD, OGP, and others, as > they are > contributed towards a common superset which can be used to as the > basis for > demonstrating concrete progress towards interop goals. Four, > Identify places where we > simply want to use existing work, such as OpenID, OAuth, X.509 and > create a shared > profile for how we can use these protocols to further > interoperability. > > > > > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From cs@comlounge.net Tue Feb 24 15:31:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862943A6917 for ; Tue, 24 Feb 2009 15:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I--f9c424Xnr for ; Tue, 24 Feb 2009 15:31:01 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 4C7123A6999 for ; Tue, 24 Feb 2009 15:31:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 6C2B31CE0223; Wed, 25 Feb 2009 00:31:19 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMVoIn0si1Ap; Wed, 25 Feb 2009 00:31:18 +0100 (CET) Received: from [192.168.178.40] (pD9EBD593.dip.t-dialin.net [217.235.213.147]) by post.comlounge.net (Postfix) with ESMTP id 3E8EC1CE01A0; Wed, 25 Feb 2009 00:31:17 +0100 (CET) Message-ID: <49A48342.4020707@comlounge.net> Date: Wed, 25 Feb 2009 00:31:14 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Mark P. McCahill" References: <6B85E8A2-831E-43B1-B0AC-C504AB596B26@duke.edu> In-Reply-To: <6B85E8A2-831E-43B1-B0AC-C504AB596B26@duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 23:31:03 -0000 Mark P. McCahill schrieb: > +1 > > I really like the approach David is taking here. The first two items: > > * managing identity > * naming and authenticating services in MMOX worlds > > are prerequisites for getting anywhere with cross-system interoperability, > would benefit users of existing systems, and should be achievable in the > fairly near term. Understanding how to negotiate these services is the > place to start, rather than defining an abstract wire-level protocol, if > the intent is to bring something other than Second Life-like worlds into > the fold. +1 and I would actually list: - defining an identity endpoint - service discovery to find services for this identity such as profile definition, friends list, inventory server, ... - distributed authorization Then having a way defined for services to be found and authorized one could define the specifics of these services. I would extend this beyond MMOX worlds though because there is huge interest in the web and social networking players as well. So maybe a seperate working group which has not the focus so much just on virtual worlds for this part might make sense. But I have no idea about the IETF process anyway at this time and if and how this would be possible or wanted. -- Christian > > > Mark McCahill > > > On Feb 24, 2009, at 11:04 AM, David W Levine wrote: >> >> 1. The ability to manage one's identity when interacting in >> multiple MMOX spaces. >> a. Allowing presence information to be shared and >> coordinated across >> MMOX spaces >> b. Permitting friends lists, and IMs to be shared across >> spaces >> c. Permitting MMOX spaces to share naming >> d. Simple ways of allowing a consistent name, managed by >> the user, and >> verifiable by other users >> e. Single sign on, mediated by multiple spaces, within >> the policy constraints >> of the spaces >> f. A consistent appearance, within the constraints of >> the various systems >> g. The ability to manage the degree of visibility / >> coupling between identities >> in MMOX spaces >> >> Note that for all of these, there is no requirement to couple the >> systems together >> beyond managing identity, and share presence and IM information. These >> use >> cases don't speak to how you move between spaces. You may have to >> shutdown >> your client on one system and start another. This also is not a "You >> must enable >> this" this is very much a "Make it easy for spaces which want to >> enable this to do >> it." Also, note that "presence and messaging" speak to user needs, and >> consitent >> appearance and name (when desired by users) again speeks to meeting >> user's >> desires. >> >> 2. The ability for the services in an MMOX world to be named, >> and authenticated >> a. Services to associate virtual places and the services >> which support them >> with authentication and administrative domains >> b. Services to permit a service to validate the >> membership of a remote >> service in one or more authentication and administrative domains >> >> This is needed so that we can do essentially any of the >> interoperability work. >> Without some framework which lets us know who we are talking to, it is >> impossible to trust the behavior of distributed systems. >> >> 3. The ability to share content between MMOX spaces >> a. Import and Export of content and models (This may >> well leverage off of >> existing work such as Collada) Static, import/export of content >> while not >> terribly dramatic is an important part of the value chain of >> interoperability >> b. Mark up schemes which recognize the existence of >> multiple presentation >> environments, but permit the sharing of content >> i. Shared "type" information for the various >> types of graphical >> content which MMOX spaces contain >> ii. Extensible, with a common registry, so that >> we can understand the >> types of contents a client can accept, and a >> virtual space, or virtual >> asset store can be asked to provide >> c. A MMOX based, system independent asset addressing >> scheme which includes >> i. Content negotiation based on 2b >> ii. Access Management based on (1) and (2) >> >> This is, to my mind, the key mid term deliverable >> >> 4. The affordances in MMOX to permit the creation of >> micro-payment economies >> a. Appropriate spots defined in MMOX protocols for cost >> information >> b. Appropriate spots defined in MMOX protocols for >> reference to >> micropayment systems >> >> 5. The ability to share "non immersive streams" between spaces >> a. Markup to permit the consistent sharing of stream >> media such as voice, >> and video, with shared start and synchronization >> information to permit >> "parallel" events between MMOX space >> >> 6. The ability to express Policy intent between MMOX services >> and virtual spaces >> a. Places in reserved in the MOX protocols for >> expressing policy intent >> b. One or more policy languages for expressing policy >> >> >> The solution space: >> >> Most of the deployed solutions partition the software problem into the >> following chunks. >> >> 1. Some form of a client which permits a user to interact with >> the shared experience >> 2. Virtual space servers which manage the state of a portion of >> virtual space >> 3. A set of supporting services used by the virtual space servers >> >> Note that exactly how these three large chunks are assembled and the >> granular nature of >> the services can vary radically, even when serving very similar >> environments. Some >> environments push a large amount of rendering and management onto >> complex clients, >> others perform the bulk of rendering in the server portion of the >> deployment. Some >> implementations combine client and simulation into a single entity >> which does some >> simulation and some user presentation. Some distribute the simulation, >> some centralize it. >> >> The heart of most of the solutions is managing to accept and merge a >> stream of updates, >> and then distribute the merged updates back to users. This can happen >> at a range of >> granularities. The two ends of the spectrum, are, roughly, sending >> updates as a fully >> merged audio visual stream, which the client merely displays, and >> sending low level >> changes to a underlying mode, which the client uses to assemble a >> complete visual >> representation of the scene. Variations include croquet and qwaq >> which use an >> underlying distributed object model to pass large amounts of updates, >> and approaches >> such as used by SecondLife and Protonsphere, where voice is managed in >> a separate >> service, with the merged state service merely letting the voice >> service know where the >> users are located. >> >> Closely related, are issues of representation and format of content. >> This takes several, >> separable forms. Import and Export of material to the core >> environment, and, more >> problematically, run time representations >> >> Approach >> Our overall approach should be web centric, and web services oriented. >> We can, and >> should think of sets of related services which can be composed as part >> of different >> solutions which will enable varying degrees of interoperability. We >> can, and should >> attempt to provide as web like an approach to function as possible. >> Content negotiation, >> separation of protocol from security, separation of interface from >> implementation and >> other techniques. >> >> Our goal is not to enshrine any single virtual world as the standard >> for all MMOX spaces, >> but rather create a flexible, extensible set of services which will >> allow us to grow larger >> and large overlapping sets of capabilities. My expectation is that we >> will see a lot of low >> hanging fruit in the area of identity, authentication, authorization >> and presence >> management (Where a user is, and allowing messaging to them across >> MMOX spaeces) >> and initially, we will find a lot of format and content area addressed >> by gateways, >> markup, and content negotiation. I see nothing wrong with having a URI >> which refers to >> "A pretty maple tree with fall colors" which provides a way to fetch >> the "Collada Style >> version" the "3dMax Mesh version" the "Linden Lab 1.2 sculpty spec >> version" such that >> a virtual space can select, through content negotiation the one most >> useful to it. >> >> We get value, when we have consistent ways of referring to all the >> various forms of >> content, and we get more value when we have ways of using existing >> content negotiation >> to allow a web light selection of an appropriate form. It is equally >> possible to imagine >> negotiating between a client and a virtual space, the desired form of >> objects. There are >> some deep challenges lurking, such as when two different approaches >> have radically >> different >> >> What I would encourage us, as a mailing list to do, is look through >> the problem >> statement, and interoperability goals I've put together here. They are >> an attempt to >> capture the various sentiments in the ongoing discussion. I am sure I >> have missed points, >> and I am sure some people will disagree with some of the points I have >> made. >> >> I would ask people to look for "No, you missed X" and "Hey, I don't >> think Y" is true. I >> will attempt to capture all of those, and revise the document, until >> we think it represents >> something close to the general group consensus. (I am not looking for >> 100% consensus, >> but a "Yeah, this captures most of what we're trying to do." With that >> in hand, I would >> suggest we could then begin to enumerate the specific services and >> markups we need to >> support our goals, and begin to flesh out use cases to help us >> understand the goals and >> services. >> >> I do not expect this to yield a set of specs which Linden Lab, or >> OpenSim, Or any one >> virtual world vendor or project would implement whole. What I expect >> it to yield is a set >> of specs, which can be combined with existing projects and code bases >> to drive us >> towards a more interoperable future. >> >> Out of scope >> >> I also want to begin to accumulate a short list of "No, this is out of >> scope" assertions >> >> 1. We will provide all the affordances necessary to permit a >> broad range of >> interaction policies. Appropriate policies for various deployed >> solutions and >> future deployed solutions is out of scope, beyond providing us use >> cases which >> highlight specific affordances we may wish to consider >> 2. Whether or not immersive multi-party spaces are useful and >> which specific >> capabilities are required is out of scope. We aspire to support a >> broad range of >> possible capabilities, and we respect that different organizations >> will have >> different perspectives on what is required. Our goal is to define broad, >> interoperable frameworks which will enable a range of deployments, not >> to define >> the one true model for this space >> 3. Propose additional statements here >> >> Closing comments >> >> I don't think our collective goal can be to take any one existing spec >> or solution and >> simply declare it the basis for our work going forward. At the same >> time, we must base >> our work in actually running code, showing real interoperability. Our >> goal must be to >> build supersets of function, based on existing products and solutions >> which demonstrate >> real interoperability. >> >> The IETF favors working code and growing consensus over blank paper >> and blue sky >> efforts. This is based in a history of success and failure in the >> industry when it comes to >> building, promoting and succeeding at standards work. Work at the IETF >> is grounded in >> working code. >> >> One way forward is to focus on several clusters of work. One: a clear, >> broad framework, >> which forms the basis for long term broad interoperation. Two: >> Capturing the current set >> of incompatible and overlapping formats and protocols in use, so that >> we can create a >> extensible and shared catalog of artifacts for sharing. (eg. "Here is >> the canonical, >> extensible list of graphic content types you might want to move on a >> MMOX transport" >> Three grow out proposed solutions such as LLSD, OGP, and others, as >> they are >> contributed towards a common superset which can be used to as the >> basis for >> demonstrating concrete progress towards interop goals. Four, Identify >> places where we >> simply want to use existing work, such as OpenID, OAuth, X.509 and >> create a shared >> profile for how we can use these protocols to further interoperability. >> >> >> >> >> >> >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From cs@comlounge.net Tue Feb 24 15:41:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 039E43A6B19 for ; Tue, 24 Feb 2009 15:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTQPxtO2uLfh for ; Tue, 24 Feb 2009 15:41:16 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 008593A6B1F for ; Tue, 24 Feb 2009 15:41:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 456E81CE0223; Wed, 25 Feb 2009 00:41:35 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2rphbbKb9+j; Wed, 25 Feb 2009 00:41:34 +0100 (CET) Received: from [192.168.178.40] (pD9EBD593.dip.t-dialin.net [217.235.213.147]) by post.comlounge.net (Postfix) with ESMTP id 624BD1CE01A0; Wed, 25 Feb 2009 00:41:32 +0100 (CET) Message-ID: <49A485AA.50502@comlounge.net> Date: Wed, 25 Feb 2009 00:41:30 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> In-Reply-To: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 23:41:18 -0000 Hi! Meadhbh Hamrick (Infinity) schrieb: > * why do we care about OLIVE, which is a proprietary protocol with a > single implementation? Because we could maybe learn something from it. I want to know how OLIVE works, I want to know how Qwak works, how Croquet works and so on. I also want to know what their use cases are they are trying to solve and why the have choosen certain routes to go over others. > so the questions i pose are... > * pursuit of which of these topics brings us to our goal of an > interoperable virtual worlds? I think we should start with a collection of use cases, see where we can find common ground on these and then try to find which protocol or format is best suited for it. We have proposals on the table which we can discuss and weight the pro and cons of each. We also should IMHO wherever we can use existing protocols instead of inventing our own. > * what does it mean to be interoperable? That's maybe an output from the use case discussion. > * must we have early agreement on all topics before we move forward > with any component? Probably not on all topics but we should have a general agreement on a plan on how we move forward ;-) > * OGP (Open Grid Protocol) > * should OGP be named something else? > * how do we do the event queue? (COMET? Bayeux? RHTTP? Long Poll?) > * where do we stuff permissions in this model? > * OGP/Teleport is not HyperGrid I think that's too early to answer and I think OGP as it is now will not be adopted by most other VW vendors anyway. We need to first find the common ground on which we can interoperate and then we should choose the best format by evaluating existing standards and new proposals. Then we can come up with a hopefully flexible enough solution which survives a bit. I doubt that anybody will come away with some substantial engineering effort to make thinks work. > * LLSD > * why is LLSD different from XDR? ASN.1? Google ProtocolBuffers? > * 128 bit integers? good enough? > * should LLSD be named something else? > * XML serialization > * maps are too much like apple plists in the XML serialization. The same applies here and IMHO should be deferred until we know better what problem we have to solve. > * MMOX Charter > * we should rename everything > * we should abandon interoperability in favor of general agreement > of model > * IETF > * Virtual Worlds in General As said earlier, I would like to broaden certain areas up to also include the web (and talk to those people working on the web side of things on such stuff, e.g. OAuth people. You might even meet them at the meeting, but I am not sure how this is organized and if cross-pollination on IETF meetings is happening. > * Previously Established Protocols > * HLA, DIS, IEEE-1278 and related protocols > * OLIVE > * MXP? > * VRML > * Representation of virtual objects > * meshes vs. prims > * interaction models for virtual objects > * Intellectual Property Regimes for Virtual Worlds > * Creative Commons (awesome gateway to free culture or the > ultimate embodiment of evil in the noosphere?) > * DRM (the only way i'll trust you with my content or the > ultimate embodiment of evil in the noosphere?) > * permissions regime > * MPEG-21? > * must we mandate the SL-style c/m/t permission? Again too early to say IMHO. The only thing which IMHO should be there is flexibility in that you may support various protocols to be future compatible but we limit the choice down now to a very small set of what MUST be implemented. Maybe it's even just one we define here but this could be replaced at some point (would be easy with a general means if service discovery as possible with e.g. XRD or POWDER). -- Christian -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From infinity@lindenlab.com Tue Feb 24 16:59:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E5D728C272 for ; Tue, 24 Feb 2009 16:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJpKB9orICLx for ; Tue, 24 Feb 2009 16:59:45 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 8DE7128C251 for ; Tue, 24 Feb 2009 16:59:45 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id F13263DBC44D; Tue, 24 Feb 2009 17:00:03 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Christian Scholz In-Reply-To: <49A48342.4020707@comlounge.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 17:00:02 -0800 References: <6B85E8A2-831E-43B1-B0AC-C504AB596B26@duke.edu> <49A48342.4020707@comlounge.net> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 00:59:48 -0000 cool. lemme put on my linden hat and throw out my US$0.02... in terms of identity, we have a strong preference for authenticating application to application. part of the reason we like this is we have a requirement that our HTTP traffic be able to flow over proxies (of both the SOCKSish variety and the squidish caching variety.) we are therefore paranoid that somewhere, somehow, transport layer authentication information would be "eaten" by a misconfigured or miscoded piece of required infrastructure. we understand that many people deploying VW applications may not have this requirement, but we kindly ask people to respect our requirements. but... just because we have defined an application-layer-endpoint to application-layer- endpoint authentication protocol does not mean we're going to try to ram it down everyone else's collective throats. OpenID, OAuth, PKIX client certs and even *shudder* gss-api all have a place in the world, and that place may include authenticating endpoints in virtual world interactions. in terms of non-second-life-like systems... yes... some people may remember that Zero and I are both "smalltalk people" and have been working with squeak from the early days. i mention it only to contextualize the discussion with respect to croquet and some the related commercial ventures (like qwaq.) personally, i like croquet and have for a while. like any system it has it's benefits and its drawbacks, but more germane to this discussion, uses an interaction model that is slightly different than the one second life uses. however... there's a statement in the draft charter identifying the focus of this group as being "application layer wire protocols," and to the degree that this statement survives the WG formation process... i would hope we could define wire protocols that were independent enough of the interaction model to at least allow some reuse of the PDUs. if there was a way to make TObjects look like REST-like resources we might be able to go further and reuse some of the interaction model. (but i'm just offering it as a suggestion! i'm not saying croquet has to change to be more SL like before we'll play nice with you!) and who knows... maybe after detailed investigation of both system's interaction models, we could find a way to denote them both with the same representational system. with respect to service discovery... the "SL mode" right now is to assume a list of services. ultimately this has got to change, and we know that. that was part of the motivation for the design behind OGP/ Auth. At the end of authentication, the client is in possession of a capability (protocol endpoint) from which it may request other capabilities (protocol endpoints) that address resources which may be accessed to request various services. all of the services CS mentions below could easily be implementable with this technique. i've heard from some quarters that capabilities give some people the willies and honestly... they gave me the willies too until i drank the kool-aide and started using BREW a couple years back. i would point out, however, that they've been in constant use with SL for over 5 years now and they tend to work quite well for us. ultimately, however, there are likely going to be some people who won't want to use them and sure... that's fine... what this means to me vis a vis protocol definition is we should separate the acquisition of a service endpoint from the service it enables. and this might be was CS was talking about below. or it might have been about service versioning that came up from time to time in the PyOGP list. fwiw... we tend to be "chunky" in our service deployment, meaning we prefer to not operate several versions of related services simultaneously, but i'm sure we can come up with a way to create a versioning system in MMOX, and i warn people up front that enabling such functionality would likely be a tough sell at linden, but we wouldn't stand in the way of other virtual worlds operators / client developers wanted to add it to a spec we claim we want to adhere to. but just keep in mind we're likely to either strongly request the feature was optional or use it in such a way that our grid always looks like it only has a single version of each service. merging social networking sites and virtual worlds sounds like a win, but i wonder if it's not a better idea for the two to develop separately and allow protocols in each area to reference each other. for example, OpenSocial is, as i understand it, currently implemented as a set of web-apis. i really like the idea of an opensocial app being able to "reach into the virtual world" and i like the idea of our virtual world supporting things like existing OpenSocial apps... let's just not make it a REQUIRED part of the protocol anytime soon. so... to paraphrase... to the degree that linden can be the 800 lb. gorilla in a room where virtual worlds are being discussed and blizzard hasn't shown up... i promise to use my secret powers for good. the lab has no interest in scuttling anyone else's product roadmap but we ask that the more agile participants in this group give us a little slack with what we're able to implement and how fast. compared to the open sim peeps, we must seem like dinosaurs, and compared to tao, we're probably stromatolites. i just ask that peeps here please keep in mind we have an onerous repository of legacy code and a large installed base we can't abandon, so there's a reason we're moving slower than people might like. -cheers -meadhbh On Feb 24, 2009, at 3:31 PM, Christian Scholz wrote: > Mark P. McCahill schrieb: >> +1 >> I really like the approach David is taking here. The first two items: >> * managing identity >> * naming and authenticating services in MMOX worlds >> are prerequisites for getting anywhere with cross-system >> interoperability, >> would benefit users of existing systems, and should be achievable >> in the >> fairly near term. Understanding how to negotiate these services is >> the >> place to start, rather than defining an abstract wire-level >> protocol, if >> the intent is to bring something other than Second Life-like worlds >> into >> the fold. > > +1 and I would actually list: > > - defining an identity endpoint > - service discovery to find services for this identity such as profile > definition, friends list, inventory server, ... > - distributed authorization > > Then having a way defined for services to be found and authorized > one could define the specifics of these services. > > I would extend this beyond MMOX worlds though because there is huge > interest in the web and social networking players as well. > > So maybe a seperate working group which has not the focus so much > just on virtual worlds for this part might make sense. But I have no > idea about the IETF process anyway at this time and if and how this > would be possible or wanted. > > -- Christian > > >> Mark McCahill >> On Feb 24, 2009, at 11:04 AM, David W Levine wrote: >>> >>> 1. The ability to manage one's identity when interacting in >>> multiple MMOX spaces. >>> a. Allowing presence information to be shared and >>> coordinated across >>> MMOX spaces >>> b. Permitting friends lists, and IMs to be shared >>> across spaces >>> c. Permitting MMOX spaces to share naming >>> d. Simple ways of allowing a consistent name, managed >>> by the user, and >>> verifiable by other users >>> e. Single sign on, mediated by multiple spaces, >>> within the policy constraints >>> of the spaces >>> f. A consistent appearance, within the constraints of >>> the various systems >>> g. The ability to manage the degree of visibility / >>> coupling between identities >>> in MMOX spaces >>> >>> Note that for all of these, there is no requirement to couple the >>> systems together >>> beyond managing identity, and share presence and IM information. >>> These use >>> cases don't speak to how you move between spaces. You may have to >>> shutdown >>> your client on one system and start another. This also is not a >>> "You must enable >>> this" this is very much a "Make it easy for spaces which want to >>> enable this to do >>> it." Also, note that "presence and messaging" speak to user needs, >>> and consitent >>> appearance and name (when desired by users) again speeks to >>> meeting user's >>> desires. >>> >>> 2. The ability for the services in an MMOX world to be >>> named, and authenticated >>> a. Services to associate virtual places and the >>> services which support them >>> with authentication and administrative domains >>> b. Services to permit a service to validate the >>> membership of a remote >>> service in one or more authentication and administrative >>> domains >>> >>> This is needed so that we can do essentially any of the >>> interoperability work. >>> Without some framework which lets us know who we are talking to, >>> it is >>> impossible to trust the behavior of distributed systems. >>> >>> 3. The ability to share content between MMOX spaces >>> a. Import and Export of content and models (This may >>> well leverage off of >>> existing work such as Collada) Static, import/export of >>> content while not >>> terribly dramatic is an important part of the value chain of >>> interoperability >>> b. Mark up schemes which recognize the existence of >>> multiple presentation >>> environments, but permit the sharing of content >>> i. Shared "type" information for the various >>> types of graphical >>> content which MMOX spaces contain >>> ii. Extensible, with a common registry, so >>> that we can understand the >>> types of contents a client can accept, and a >>> virtual space, or virtual >>> asset store can be asked to provide >>> c. A MMOX based, system independent asset addressing >>> scheme which includes >>> i. Content negotiation based on 2b >>> ii. Access Management based on (1) and (2) >>> >>> This is, to my mind, the key mid term deliverable >>> >>> 4. The affordances in MMOX to permit the creation of micro- >>> payment economies >>> a. Appropriate spots defined in MMOX protocols for >>> cost information >>> b. Appropriate spots defined in MMOX protocols for >>> reference to >>> micropayment systems >>> >>> 5. The ability to share "non immersive streams" between >>> spaces >>> a. Markup to permit the consistent sharing of stream >>> media such as voice, >>> and video, with shared start and synchronization >>> information to permit >>> "parallel" events between MMOX space >>> >>> 6. The ability to express Policy intent between MMOX >>> services and virtual spaces >>> a. Places in reserved in the MOX protocols for >>> expressing policy intent >>> b. One or more policy languages for expressing policy >>> >>> >>> The solution space: >>> >>> Most of the deployed solutions partition the software problem into >>> the following chunks. >>> >>> 1. Some form of a client which permits a user to interact >>> with the shared experience >>> 2. Virtual space servers which manage the state of a >>> portion of virtual space >>> 3. A set of supporting services used by the virtual space >>> servers >>> >>> Note that exactly how these three large chunks are assembled and >>> the granular nature of >>> the services can vary radically, even when serving very similar >>> environments. Some >>> environments push a large amount of rendering and management onto >>> complex clients, >>> others perform the bulk of rendering in the server portion of the >>> deployment. Some >>> implementations combine client and simulation into a single entity >>> which does some >>> simulation and some user presentation. Some distribute the >>> simulation, some centralize it. >>> >>> The heart of most of the solutions is managing to accept and merge >>> a stream of updates, >>> and then distribute the merged updates back to users. This can >>> happen at a range of >>> granularities. The two ends of the spectrum, are, roughly, sending >>> updates as a fully >>> merged audio visual stream, which the client merely displays, and >>> sending low level >>> changes to a underlying mode, which the client uses to assemble a >>> complete visual >>> representation of the scene. Variations include croquet and qwaq >>> which use an >>> underlying distributed object model to pass large amounts of >>> updates, and approaches >>> such as used by SecondLife and Protonsphere, where voice is >>> managed in a separate >>> service, with the merged state service merely letting the voice >>> service know where the >>> users are located. >>> >>> Closely related, are issues of representation and format of >>> content. This takes several, >>> separable forms. Import and Export of material to the core >>> environment, and, more >>> problematically, run time representations >>> >>> Approach >>> Our overall approach should be web centric, and web services >>> oriented. We can, and >>> should think of sets of related services which can be composed as >>> part of different >>> solutions which will enable varying degrees of interoperability. >>> We can, and should >>> attempt to provide as web like an approach to function as >>> possible. Content negotiation, >>> separation of protocol from security, separation of interface from >>> implementation and >>> other techniques. >>> >>> Our goal is not to enshrine any single virtual world as the >>> standard for all MMOX spaces, >>> but rather create a flexible, extensible set of services which >>> will allow us to grow larger >>> and large overlapping sets of capabilities. My expectation is that >>> we will see a lot of low >>> hanging fruit in the area of identity, authentication, >>> authorization and presence >>> management (Where a user is, and allowing messaging to them across >>> MMOX spaeces) >>> and initially, we will find a lot of format and content area >>> addressed by gateways, >>> markup, and content negotiation. I see nothing wrong with having a >>> URI which refers to >>> "A pretty maple tree with fall colors" which provides a way to >>> fetch the "Collada Style >>> version" the "3dMax Mesh version" the "Linden Lab 1.2 sculpty spec >>> version" such that >>> a virtual space can select, through content negotiation the one >>> most useful to it. >>> >>> We get value, when we have consistent ways of referring to all the >>> various forms of >>> content, and we get more value when we have ways of using existing >>> content negotiation >>> to allow a web light selection of an appropriate form. It is >>> equally possible to imagine >>> negotiating between a client and a virtual space, the desired form >>> of objects. There are >>> some deep challenges lurking, such as when two different >>> approaches have radically >>> different >>> >>> What I would encourage us, as a mailing list to do, is look >>> through the problem >>> statement, and interoperability goals I've put together here. They >>> are an attempt to >>> capture the various sentiments in the ongoing discussion. I am >>> sure I have missed points, >>> and I am sure some people will disagree with some of the points I >>> have made. >>> >>> I would ask people to look for "No, you missed X" and "Hey, I >>> don't think Y" is true. I >>> will attempt to capture all of those, and revise the document, >>> until we think it represents >>> something close to the general group consensus. (I am not looking >>> for 100% consensus, >>> but a "Yeah, this captures most of what we're trying to do." With >>> that in hand, I would >>> suggest we could then begin to enumerate the specific services and >>> markups we need to >>> support our goals, and begin to flesh out use cases to help us >>> understand the goals and >>> services. >>> >>> I do not expect this to yield a set of specs which Linden Lab, or >>> OpenSim, Or any one >>> virtual world vendor or project would implement whole. What I >>> expect it to yield is a set >>> of specs, which can be combined with existing projects and code >>> bases to drive us >>> towards a more interoperable future. >>> >>> Out of scope >>> >>> I also want to begin to accumulate a short list of "No, this is >>> out of scope" assertions >>> >>> 1. We will provide all the affordances necessary to permit >>> a broad range of >>> interaction policies. Appropriate policies for various deployed >>> solutions and >>> future deployed solutions is out of scope, beyond providing us use >>> cases which >>> highlight specific affordances we may wish to consider >>> 2. Whether or not immersive multi-party spaces are useful >>> and which specific >>> capabilities are required is out of scope. We aspire to support a >>> broad range of >>> possible capabilities, and we respect that different organizations >>> will have >>> different perspectives on what is required. Our goal is to define >>> broad, >>> interoperable frameworks which will enable a range of deployments, >>> not to define >>> the one true model for this space >>> 3. Propose additional statements here >>> >>> Closing comments >>> >>> I don't think our collective goal can be to take any one existing >>> spec or solution and >>> simply declare it the basis for our work going forward. At the >>> same time, we must base >>> our work in actually running code, showing real interoperability. >>> Our goal must be to >>> build supersets of function, based on existing products and >>> solutions which demonstrate >>> real interoperability. >>> >>> The IETF favors working code and growing consensus over blank >>> paper and blue sky >>> efforts. This is based in a history of success and failure in the >>> industry when it comes to >>> building, promoting and succeeding at standards work. Work at the >>> IETF is grounded in >>> working code. >>> >>> One way forward is to focus on several clusters of work. One: a >>> clear, broad framework, >>> which forms the basis for long term broad interoperation. Two: >>> Capturing the current set >>> of incompatible and overlapping formats and protocols in use, so >>> that we can create a >>> extensible and shared catalog of artifacts for sharing. (eg. "Here >>> is the canonical, >>> extensible list of graphic content types you might want to move >>> on a MMOX transport" >>> Three grow out proposed solutions such as LLSD, OGP, and others, >>> as they are >>> contributed towards a common superset which can be used to as the >>> basis for >>> demonstrating concrete progress towards interop goals. Four, >>> Identify places where we >>> simply want to use existing work, such as OpenID, OAuth, X.509 >>> and create a shared >>> profile for how we can use these protocols to further >>> interoperability. >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > > -- > Christian Scholz > Blog: http://mrtopf.de/blog > Company: http://comlounge.net > Podcasts: http://datawithoutborders.net, http://openweb-podcast.de > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Tue Feb 24 17:22:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22BA23A6816 for ; Tue, 24 Feb 2009 17:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=-1.453, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CjHSn0jUuEQ for ; Tue, 24 Feb 2009 17:22:01 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id E4EE43A680A for ; Tue, 24 Feb 2009 17:22:01 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 72BD23DBC44C; Tue, 24 Feb 2009 17:22:21 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49A44928.10307@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-17--480297736 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 17:22:19 -0800 References: <49A44928.10307@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 01:22:03 -0000 --Apple-Mail-17--480297736 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit ah! i think i see a bit of a disconnect here. jon, you're saying you want to be able to use common DOM apis to access data in an XML serialization. fwiw... that's the atypical use at the lab () and i mention it not to imply that this is the type of thing that should never be done, but simply to point out that the way LLSD XML serialization layer was intended to be used was as a container for something that got de-serialized before the application layer gets it's mitts on the data. so.. ya got your stack... (um.. i apologize for the graph... if you change the typeface to something vaguely monospace, it'll look much nicer) Application Application | "a" | "d" Presentation Presentation | "b" | "c" Transport <------ the great mysteries of the network -----> Transport it sounds like you want to do some processing at points "b" and "c". after it has been received by the transport and before it gets un- marshalled / de-serialized. is this just 'cause you're used to writing code that directly uses the DOM, or are you routing to specific application endpoints based on the contents of the stuff in the XML? and also... is this a requirement of your system? or just the way that seems right to you? (not trying to pick a fight... just curious) -cheers -meadhbh On Feb 24, 2009, at 11:23 AM, Jon Watte wrote: > Catherine Pfeffer wrote: >> (XML schema allows for checking that the data inside the tags >> conform to a certain syntax, for example that floats are made of >> digts and possibly of a decimal dot and a minus sign). >> > > But you don't actually know whether those digits are actual, valid > data until and unless that data hits some real executable code. > Additionally, we will likely deal with data types that are naturally > atomic ("vector3" or "quaternion") but that are not part of the XML > data type set. Sending a vector3 as "x name="y">yz" seems like a bad idea, > compared to "x,y,z". > > You wouldn't know whether "123000,-5000000,600000" is a proper > teleport destination, or under the surface of the earth, or outside > the allowed simulation coordinate space, until you treated that > coordinate in the target world space. Thus, the validation > capabilities of a possible XSD are limited at best anyway. > > I must admit that the main reason I want things in attributes is > brevity, and uniformity of handling. If I want to get a node set of > all property values of a given entity record, I can simply do: > > values = entityNode.getElementsByTagName("value"); > > Similarly, if I want to get a specific element, I can do: > > thePosition = entityNode.getElementById("pos"); > > This assumes that the "key" attribute is defined as an ID such that > the DOM implementation can recognize it. On the other hand, > depending on structure, it may mean that they key "pos" can't be > used on multiple objects in the same overall XML document, so it > might be better to get "matching attribute value" anyway: > > thePosition = entityNode.getElementPath("[@key='pos']") > > >> >> I have a similar list too ;-). Someone here has proposed a VWSD >> working group to separate high level concerns (like meshes versus >> prims) from low level concerns (like data types and >> serializations). If we are sure that xxSD is the way to go (and not >> ASN or whatever), I would volunteer to be part of such a group, and >> so would you, Jon, I guess ;-). > > > Personally, I think it's too early to really worry about it too > much. I first want rough consensus on the model we're using -- I > think most, but not all, participants on the list now understand > that interoperating virtutal world objects practically require > simulation hosts to talk to other simulation hosts. I also think > that most participants understand that a specified client/server > protocol would not actually solve interoperability between disparate > simulation systems. > > But how do we actually define and determine "rough consensus"? > Perhaps coming up with some metric for that would be a good first > step. > > Sincerely, > > jw > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-17--480297736 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable ah! i think i see a bit of a = disconnect here.

jon, you're saying you want to be = able to use common DOM apis to access data in an XML = serialization.

fwiw... that's the atypical use = at the lab (<insert comments here acknowledging that there's more the = the world than linden lab>) and i mention it not to imply that this is = the type of thing that should never be done, but simply to point out = that the way LLSD XML serialization layer was intended to be used was as = a container for something that got de-serialized before the application = layer gets it's mitts on the data.

so.. ya got = your stack... (um.. i apologize for the graph... if you change the = typeface to something vaguely monospace, it'll look much = nicer)

Application         =                     =                   =   Application
     | "a" =                  =                     =                  | = "d"
Presentation              =                     =             =   Presentation
     | "b"    =                     =                     =            | = "c" 
 Transport <------ the great = mysteries of the network -----> = Transport

it sounds like you want to do = some processing at points "b" and "c". after it has been received by the = transport and before it gets un-marshalled / = de-serialized.

is this just 'cause you're used = to writing code that directly uses the DOM, or are you routing to = specific application endpoints based on the contents of the stuff in the = XML?

and also... is this a requirement of your = system? or just the way that seems right to = you?

(not trying to pick a fight... just = curious)

-cheers
-meadhbh
On Feb 24, 2009, at 11:23 AM, Jon Watte = wrote:

Catherine Pfeffer wrote:
(XML schema allows for checking that the data inside the = tags conform to a certain syntax, for example that floats are made of = digts and possibly of a decimal dot and a minus = sign).


But = you don't actually know whether those digits are actual, valid data = until and unless that data hits some real executable code. Additionally, = we will likely deal with data types that are naturally atomic ("vector3" = or "quaternion") but that are not part of the XML data type set. Sending = a vector3 as "<float name=3D"x">x</float><float = name=3D"y">y</float><float name=3D"z">z</float>" seems like a = bad idea, compared to "<vector3>x,y,z</vector3>".

You = wouldn't know whether "123000,-5000000,600000" is a proper teleport = destination, or under the surface of the earth, or outside the allowed = simulation coordinate space, until you treated that coordinate in the = target world space. Thus, the validation capabilities of a possible XSD = are limited at best anyway.

I must admit that the main reason I = want things in attributes is brevity, and uniformity of handling. If I = want to get a node set of all property values of a given entity record, = I can simply do:

values =3D = entityNode.getElementsByTagName("value");

Similarly, if I want to = get a specific element, I can do:

thePosition =3D = entityNode.getElementById("pos");

This assumes that the "key" = attribute is defined as an ID such that the DOM implementation can = recognize it. On the other hand, depending on structure, it may mean = that they key "pos" can't be used on multiple objects in the same = overall XML document, so it might be better to get "matching attribute = value" anyway:

thePosition =3D = entityNode.getElementPath("[@key=3D'pos']")



I have a = similar list too ;-). Someone here has proposed a VWSD working group to = separate high level concerns (like meshes versus prims) from low level = concerns (like data types and serializations). If we are sure that xxSD = is the way to go (and not ASN or whatever), I would volunteer to be part = of such a group, and so would you, Jon, I guess = ;-).


Personally, I think it's too early to = really worry about it too much. I first want rough consensus on the = model we're using -- I think most, but not all, participants on the list = now understand that interoperating virtutal world objects practically = require simulation hosts to talk to other simulation hosts. I also think = that most participants understand that a specified client/server = protocol would not actually solve interoperability between disparate = simulation systems.

But how do we actually define and determine = "rough consensus"? Perhaps coming up with some metric for that would be = a good first = step.

Sincerely,

jw


_____________________________= __________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mmox

= --Apple-Mail-17--480297736-- From cathypfeffer@gmail.com Tue Feb 24 17:24:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AF33A6816 for ; Tue, 24 Feb 2009 17:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQkedKHeDaq5 for ; Tue, 24 Feb 2009 17:24:23 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id E79A13A680A for ; Tue, 24 Feb 2009 17:24:22 -0800 (PST) Received: by ewy8 with SMTP id 8so493191ewy.13 for ; Tue, 24 Feb 2009 17:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=IZuxA7RcjOK7rgIJwQpggI5Y/OPuCrgkvISAJF9U8uA=; b=nCG4NfyGQeZd+WgyXO9+lJraxXMez8z7PhUva2J2j44syxignYSUZOpwzzbkL6xPAY qmiEtDdYYGI9vxW+kuq0NKnT16yO6FupkeH7sY+KxuWuUuaURDJZuylWm/Ip/ga3c0gD YvXO9Co4AnM5bTqlLtK6XKXLIoBBkL41QDiXk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vWbhUngs0+zvePRSyVKDtzg78fTwIH3MYNL1mZT8xb6jKFStUJOvtqxVTZimklt7PT AusbvroPrGPzAI2M4yCx5UwOP8GehZbQyRRw4gszQpXuUpRkGMByirauSzf3pMRGUnpT FjD2i9OotgSRd+Ji0Z9EscLXDuPePwMQ/WN/c= MIME-Version: 1.0 Received: by 10.210.135.17 with SMTP id i17mr90661ebd.47.1235525080784; Tue, 24 Feb 2009 17:24:40 -0800 (PST) Date: Wed, 25 Feb 2009 02:24:40 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c11628d20d50463b4195e Subject: [mmox] Example of what could be a real XML LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 01:24:24 -0000 --0015174c11628d20d50463b4195e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, Here is a real LLSD packet. Below I'll show how it could look like if we would abandon the 1:1 mapping to binary serialization. If transposing 1:1 the binary encoding, the packet is 2688 bytes long. If doing it in a more xml-ish way, the packet is 1065 bytes long. That's 40 % of the length the current LLSD proposal generates. It's also more legible by humans, easier to validate and easier to parse. Those figures include 2 spaces of indentation at each tag level, and all the newline characters. First the "transposition of binary serialization" way: AgentData AgentId 81466fc7-276f-455d-9b72-8316e9712535 GroupId SessionId 4bbb6fa9-e649-4507-a709-8831c237c4ee ObjectData BypassRaycast 1 EveryoneMask AAAAAA== Flags AAAAAg== GroupMask AAAAAA== Material 3 NextOwnerMask AAjAAA== PCode 9 Path Begin 0 Curve 16 End 0 RadiusOffset 0 Revolutions 0 ScaleX 100 ScaleY 100 ShearX 0 ShearY 0 Skew 0 TaperX 0 TaperY 0 Twist 0 TwistBegin 0 Profile Begin 0 Curve 1 End 0 Hollow 0 RayEnd 42.9329986572265625 29.6600322723388671875 31.399318695068359375 RayEndIsIntersection 0 RayStart 48.281482696533203125 32.063152313232421875 34.092010498046875 RayTargetId Rotation 0 0 0 1 Scale 0.5 0.5 0.5 State 0 Now the "XML" way: Even better results could be achieved by using default values for some attributes. -- Cathy --0015174c11628d20d50463b4195e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 SGVsbG8sPGJyPjxicj5IZXJlIGlzIGEgcmVhbCBMTFNEIHBhY2tldC4gQmVsb3cgSSYjMzk7bGwg c2hvdyBob3cgaXQgY291bGQgbG9vayBsaWtlIGlmIHdlIHdvdWxkIGFiYW5kb24gdGhlIDE6MSBt YXBwaW5nIHRvIGJpbmFyeSBzZXJpYWxpemF0aW9uLjxicj48YnI+SWYgdHJhbnNwb3NpbmcgMTox IHRoZSBiaW5hcnkgZW5jb2RpbmcsIHRoZSBwYWNrZXQgaXMgMjY4OCBieXRlcyBsb25nLiBJZiBk b2luZyBpdCBpbiBhIG1vcmUgeG1sLWlzaCB3YXksIHRoZSBwYWNrZXQgaXMgMTA2NSBieXRlcyBs b25nLiBUaGF0JiMzOTtzIDQwICUgb2YgdGhlIGxlbmd0aCB0aGUgY3VycmVudCBMTFNEIHByb3Bv c2FsIGdlbmVyYXRlcy4gSXQmIzM5O3MgYWxzbyBtb3JlIGxlZ2libGUgYnkgaHVtYW5zLCBlYXNp ZXIgdG8gdmFsaWRhdGUgYW5kIGVhc2llciB0byBwYXJzZS4gVGhvc2UgZmlndXJlcyBpbmNsdWRl IDIgc3BhY2VzIG9mIGluZGVudGF0aW9uIGF0IGVhY2ggdGFnIGxldmVsLCBhbmQgYWxsIHRoZSBu ZXdsaW5lIGNoYXJhY3RlcnMuPGJyPgo8YnI+Rmlyc3QgdGhlICZxdW90O3RyYW5zcG9zaXRpb24g b2YgYmluYXJ5IHNlcmlhbGl6YXRpb24mcXVvdDsgd2F5Ojxicj48YnI+Jmx0O2xsc2QmZ3Q7PGJy PsKgICZsdDttYXAmZ3Q7PGJyPsKgwqDCoCAmbHQ7a2V5Jmd0O0FnZW50RGF0YSZsdDsva2V5Jmd0 Ozxicj7CoMKgwqAgJmx0O21hcCZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7a2V5Jmd0O0FnZW50SWQm bHQ7L2tleSZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7dXVpZCZndDs4MTQ2NmZjNy0yNzZmLTQ1NWQt OWI3Mi04MzE2ZTk3MTI1MzUmbHQ7L3V1aWQmZ3Q7PGJyPgrCoMKgwqDCoMKgICZsdDtrZXkmZ3Q7 R3JvdXBJZCZsdDsva2V5Jmd0Ozxicj7CoMKgwqDCoMKgICZsdDt1dWlkLyZndDs8YnI+wqDCoMKg wqDCoCAmbHQ7a2V5Jmd0O1Nlc3Npb25JZCZsdDsva2V5Jmd0Ozxicj7CoMKgwqDCoMKgICZsdDt1 dWlkJmd0OzRiYmI2ZmE5LWU2NDktNDUwNy1hNzA5LTg4MzFjMjM3YzRlZSZsdDsvdXVpZCZndDs8 YnI+wqDCoMKgICZsdDsvbWFwJmd0Ozxicj7CoMKgwqAgJmx0O2tleSZndDtPYmplY3REYXRhJmx0 Oy9rZXkmZ3Q7PGJyPgrCoMKgwqAgJmx0O21hcCZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7a2V5Jmd0 O0J5cGFzc1JheWNhc3QmbHQ7L2tleSZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7Ym9vbGVhbiZndDsx Jmx0Oy9ib29sZWFuJmd0Ozxicj7CoMKgwqDCoMKgICZsdDtrZXkmZ3Q7RXZlcnlvbmVNYXNrJmx0 Oy9rZXkmZ3Q7PGJyPsKgwqDCoMKgwqAgJmx0O2JpbmFyeSBlbmNvZGluZz0mcXVvdDtiYXNlNjQm cXVvdDsmZ3Q7QUFBQUFBPT0mbHQ7L2JpbmFyeSZndDs8YnI+CsKgwqDCoMKgwqAgJmx0O2tleSZn dDtGbGFncyZsdDsva2V5Jmd0Ozxicj7CoMKgwqDCoMKgICZsdDtiaW5hcnkgZW5jb2Rpbmc9JnF1 b3Q7YmFzZTY0JnF1b3Q7Jmd0O0FBQUFBZz09Jmx0Oy9iaW5hcnkmZ3Q7PGJyPsKgwqDCoMKgwqAg Jmx0O2tleSZndDtHcm91cE1hc2smbHQ7L2tleSZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7YmluYXJ5 IGVuY29kaW5nPSZxdW90O2Jhc2U2NCZxdW90OyZndDtBQUFBQUE9PSZsdDsvYmluYXJ5Jmd0Ozxi cj4KwqDCoMKgwqDCoCAmbHQ7a2V5Jmd0O01hdGVyaWFsJmx0Oy9rZXkmZ3Q7PGJyPsKgwqDCoMKg wqAgJmx0O2ludGVnZXImZ3Q7MyZsdDsvaW50ZWdlciZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7a2V5 Jmd0O05leHRPd25lck1hc2smbHQ7L2tleSZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7YmluYXJ5IGVu Y29kaW5nPSZxdW90O2Jhc2U2NCZxdW90OyZndDtBQWpBQUE9PSZsdDsvYmluYXJ5Jmd0Ozxicj7C oMKgwqDCoMKgICZsdDtrZXkmZ3Q7UENvZGUmbHQ7L2tleSZndDs8YnI+CsKgwqDCoMKgwqAgJmx0 O2ludGVnZXImZ3Q7OSZsdDsvaW50ZWdlciZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7a2V5Jmd0O1Bh dGgmbHQ7L2tleSZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7bWFwJmd0Ozxicj7CoMKgwqDCoMKgwqDC oCAmbHQ7a2V5Jmd0O0JlZ2luJmx0Oy9rZXkmZ3Q7PGJyPsKgwqDCoMKgwqDCoMKgICZsdDtpbnRl Z2VyJmd0OzAmbHQ7L2ludGVnZXImZ3Q7PGJyPsKgwqDCoMKgwqDCoMKgICZsdDtrZXkmZ3Q7Q3Vy dmUmbHQ7L2tleSZndDs8YnI+CsKgwqDCoMKgwqDCoMKgICZsdDtpbnRlZ2VyJmd0OzE2Jmx0Oy9p bnRlZ2VyJmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7a2V5Jmd0O0VuZCZsdDsva2V5Jmd0Ozxi cj7CoMKgwqDCoMKgwqDCoCAmbHQ7aW50ZWdlciZndDswJmx0Oy9pbnRlZ2VyJmd0Ozxicj7CoMKg wqDCoMKgwqDCoCAmbHQ7a2V5Jmd0O1JhZGl1c09mZnNldCZsdDsva2V5Jmd0Ozxicj7CoMKgwqDC oMKgwqDCoCAmbHQ7aW50ZWdlciZndDswJmx0Oy9pbnRlZ2VyJmd0Ozxicj7CoMKgwqDCoMKgwqDC oCAmbHQ7a2V5Jmd0O1Jldm9sdXRpb25zJmx0Oy9rZXkmZ3Q7PGJyPgrCoMKgwqDCoMKgwqDCoCAm bHQ7aW50ZWdlciZndDswJmx0Oy9pbnRlZ2VyJmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7a2V5 Jmd0O1NjYWxlWCZsdDsva2V5Jmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7aW50ZWdlciZndDsx MDAmbHQ7L2ludGVnZXImZ3Q7PGJyPsKgwqDCoMKgwqDCoMKgICZsdDtrZXkmZ3Q7U2NhbGVZJmx0 Oy9rZXkmZ3Q7PGJyPsKgwqDCoMKgwqDCoMKgICZsdDtpbnRlZ2VyJmd0OzEwMCZsdDsvaW50ZWdl ciZndDs8YnI+wqDCoMKgwqDCoMKgwqAgJmx0O2tleSZndDtTaGVhclgmbHQ7L2tleSZndDs8YnI+ CsKgwqDCoMKgwqDCoMKgICZsdDtpbnRlZ2VyJmd0OzAmbHQ7L2ludGVnZXImZ3Q7PGJyPsKgwqDC oMKgwqDCoMKgICZsdDtrZXkmZ3Q7U2hlYXJZJmx0Oy9rZXkmZ3Q7PGJyPsKgwqDCoMKgwqDCoMKg ICZsdDtpbnRlZ2VyJmd0OzAmbHQ7L2ludGVnZXImZ3Q7PGJyPsKgwqDCoMKgwqDCoMKgICZsdDtr ZXkmZ3Q7U2tldyZsdDsva2V5Jmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7aW50ZWdlciZndDsw Jmx0Oy9pbnRlZ2VyJmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7a2V5Jmd0O1RhcGVyWCZsdDsv a2V5Jmd0Ozxicj4KwqDCoMKgwqDCoMKgwqAgJmx0O2ludGVnZXImZ3Q7MCZsdDsvaW50ZWdlciZn dDs8YnI+wqDCoMKgwqDCoMKgwqAgJmx0O2tleSZndDtUYXBlclkmbHQ7L2tleSZndDs8YnI+wqDC oMKgwqDCoMKgwqAgJmx0O2ludGVnZXImZ3Q7MCZsdDsvaW50ZWdlciZndDs8YnI+wqDCoMKgwqDC oMKgwqAgJmx0O2tleSZndDtUd2lzdCZsdDsva2V5Jmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7 aW50ZWdlciZndDswJmx0Oy9pbnRlZ2VyJmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7a2V5Jmd0 O1R3aXN0QmVnaW4mbHQ7L2tleSZndDs8YnI+CsKgwqDCoMKgwqDCoMKgICZsdDtpbnRlZ2VyJmd0 OzAmbHQ7L2ludGVnZXImZ3Q7PGJyPsKgwqDCoMKgwqAgJmx0Oy9tYXAmZ3Q7PGJyPsKgwqDCoMKg wqAgJmx0O2tleSZndDtQcm9maWxlJmx0Oy9rZXkmZ3Q7PGJyPsKgwqDCoMKgwqAgJmx0O21hcCZn dDs8YnI+wqDCoMKgwqDCoMKgwqAgJmx0O2tleSZndDtCZWdpbiZsdDsva2V5Jmd0Ozxicj7CoMKg wqDCoMKgwqDCoCAmbHQ7aW50ZWdlciZndDswJmx0Oy9pbnRlZ2VyJmd0Ozxicj7CoMKgwqDCoMKg wqDCoCAmbHQ7a2V5Jmd0O0N1cnZlJmx0Oy9rZXkmZ3Q7PGJyPgrCoMKgwqDCoMKgwqDCoCAmbHQ7 aW50ZWdlciZndDsxJmx0Oy9pbnRlZ2VyJmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7a2V5Jmd0 O0VuZCZsdDsva2V5Jmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7aW50ZWdlciZndDswJmx0Oy9p bnRlZ2VyJmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7a2V5Jmd0O0hvbGxvdyZsdDsva2V5Jmd0 Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7aW50ZWdlciZndDswJmx0Oy9pbnRlZ2VyJmd0Ozxicj7C oMKgwqDCoMKgICZsdDsvbWFwJmd0Ozxicj4KwqDCoMKgwqDCoCAmbHQ7a2V5Jmd0O1JheUVuZCZs dDsva2V5Jmd0Ozxicj7CoMKgwqDCoMKgICZsdDthcnJheSZndDs8YnI+wqDCoMKgwqDCoMKgwqAg Jmx0O3JlYWwmZ3Q7NDIuOTMyOTk4NjU3MjI2NTYyNSZsdDsvcmVhbCZndDs8YnI+wqDCoMKgwqDC oMKgwqAgJmx0O3JlYWwmZ3Q7MjkuNjYwMDMyMjcyMzM4ODY3MTg3NSZsdDsvcmVhbCZndDs8YnI+ wqDCoMKgwqDCoMKgwqAgJmx0O3JlYWwmZ3Q7MzEuMzk5MzE4Njk1MDY4MzU5Mzc1Jmx0Oy9yZWFs Jmd0Ozxicj4KwqDCoMKgwqDCoCAmbHQ7L2FycmF5Jmd0Ozxicj7CoMKgwqDCoMKgICZsdDtrZXkm Z3Q7UmF5RW5kSXNJbnRlcnNlY3Rpb24mbHQ7L2tleSZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7Ym9v bGVhbiZndDswJmx0Oy9ib29sZWFuJmd0Ozxicj7CoMKgwqDCoMKgICZsdDtrZXkmZ3Q7UmF5U3Rh cnQmbHQ7L2tleSZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7YXJyYXkmZ3Q7PGJyPsKgwqDCoMKgwqDC oMKgICZsdDtyZWFsJmd0OzQ4LjI4MTQ4MjY5NjUzMzIwMzEyNSZsdDsvcmVhbCZndDs8YnI+CsKg wqDCoMKgwqDCoMKgICZsdDtyZWFsJmd0OzMyLjA2MzE1MjMxMzIzMjQyMTg3NSZsdDsvcmVhbCZn dDs8YnI+wqDCoMKgwqDCoMKgwqAgJmx0O3JlYWwmZ3Q7MzQuMDkyMDEwNDk4MDQ2ODc1Jmx0Oy9y ZWFsJmd0Ozxicj7CoMKgwqDCoMKgICZsdDsvYXJyYXkmZ3Q7PGJyPsKgwqDCoMKgwqAgJmx0O2tl eSZndDtSYXlUYXJnZXRJZCZsdDsva2V5Jmd0Ozxicj7CoMKgwqDCoMKgICZsdDt1dWlkLyZndDs8 YnI+wqDCoMKgwqDCoCAmbHQ7a2V5Jmd0O1JvdGF0aW9uJmx0Oy9rZXkmZ3Q7PGJyPgrCoMKgwqDC oMKgICZsdDthcnJheSZndDs8YnI+wqDCoMKgwqDCoMKgwqAgJmx0O3JlYWwmZ3Q7MCZsdDsvcmVh bCZndDs8YnI+wqDCoMKgwqDCoMKgwqAgJmx0O3JlYWwmZ3Q7MCZsdDsvcmVhbCZndDs8YnI+wqDC oMKgwqDCoMKgwqAgJmx0O3JlYWwmZ3Q7MCZsdDsvcmVhbCZndDs8YnI+wqDCoMKgwqDCoMKgwqAg Jmx0O3JlYWwmZ3Q7MSZsdDsvcmVhbCZndDs8YnI+wqDCoMKgwqDCoCAmbHQ7L2FycmF5Jmd0Ozxi cj7CoMKgwqDCoMKgICZsdDtrZXkmZ3Q7U2NhbGUmbHQ7L2tleSZndDs8YnI+CsKgwqDCoMKgwqAg Jmx0O2FycmF5Jmd0Ozxicj7CoMKgwqDCoMKgwqDCoCAmbHQ7cmVhbCZndDswLjUmbHQ7L3JlYWwm Z3Q7PGJyPsKgwqDCoMKgwqDCoMKgICZsdDtyZWFsJmd0OzAuNSZsdDsvcmVhbCZndDs8YnI+wqDC oMKgwqDCoMKgwqAgJmx0O3JlYWwmZ3Q7MC41Jmx0Oy9yZWFsJmd0Ozxicj7CoMKgwqDCoMKgICZs dDsvYXJyYXkmZ3Q7PGJyPsKgwqDCoMKgwqAgJmx0O2tleSZndDtTdGF0ZSZsdDsva2V5Jmd0Ozxi cj7CoMKgwqDCoMKgICZsdDtpbnRlZ2VyJmd0OzAmbHQ7L2ludGVnZXImZ3Q7PGJyPgrCoMKgwqAg Jmx0Oy9tYXAmZ3Q7PGJyPsKgICZsdDsvbWFwJmd0Ozxicj4mbHQ7L2xsc2QmZ3Q7PGJyPjxiciBj bGVhcj0iYWxsIj5Ob3cgdGhlICZxdW90O1hNTCZxdW90OyB3YXk6PGJyPjxicj4mbHQ7bGxzZCZn dDs8YnI+wqAgJmx0O0FnZW50RGF0YTxicj7CoMKgwqDCoMKgIEFnZW50SWQ9JnF1b3Q7ODE0NjZm YzctMjc2Zi00NTVkLTliNzItODMxNmU5NzEyNTM1JnF1b3Q7PGJyPsKgwqDCoMKgwqAgR3JvdXBJ ZD0mcXVvdDsmcXVvdDs8YnI+CsKgwqDCoMKgwqAgU2Vzc2lvbklkPSZxdW90OzRiYmI2ZmE5LWU2 NDktNDUwNy1hNzA5LTg4MzFjMjM3YzRlZSZxdW90OyAvJmd0Ozxicj7CoMKgwqAgJmx0O09iamVj dERhdGE8YnI+wqDCoMKgwqDCoMKgwqAgQnlwYXNzUmF5Y2FzdD0mcXVvdDsxJnF1b3Q7PGJyPsKg wqDCoMKgwqDCoMKgIEV2ZXJ5b25lTWFzaz0mcXVvdDsweDAwMDAwMDAwJnF1b3Q7PGJyPsKgIMKg IMKgIMKgIEZsYWdzPSZxdW90OzB4MDAwMDAwMDImcXVvdDs8YnI+CsKgwqDCoMKgwqDCoMKgIEdy b3VwTWFzaz0mcXVvdDsweDAwMDAwMDAwJnF1b3Q7PGJyPsKgwqDCoMKgwqDCoMKgIE1hdGVyaWFs PSZxdW90OzMmcXVvdDs8YnI+wqDCoMKgwqDCoMKgwqAgTmV4dE93bmVyTWFzaz0mcXVvdDsweDAw MDhDMDAwJnF1b3Q7PGJyPsKgwqDCoMKgwqDCoMKgIFBDb2RlPSZxdW90OzkmcXVvdDsmZ3Q7PGJy PsKgwqDCoMKgwqAgJmx0O1BhdGg8YnI+wqDCoMKgwqDCoMKgwqDCoMKgIEJlZ2luPSZxdW90OzAm cXVvdDs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgIEN1cnZlPSZxdW90OzE2JnF1b3Q7PGJyPgrCoMKg wqDCoMKgwqDCoMKgwqAgRW5kPSZxdW90OzAmcXVvdDs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgIFJh ZGl1c09mZnNldD0mcXVvdDswJnF1b3Q7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoCBSZXZvbHV0aW9u cz0mcXVvdDswJnF1b3Q7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoCBTY2FsZVg9JnF1b3Q7MTAwJnF1 b3Q7PGJyPsKgwqDCoMKgwqDCoMKgwqDCoCBTY2FsZVk9JnF1b3Q7MTAwJnF1b3Q7PGJyPsKgwqDC oMKgwqDCoMKgwqDCoCBTaGVhclg9JnF1b3Q7MCZxdW90Ozxicj7CoMKgwqDCoMKgwqDCoMKgwqAg U2hlYXJZPSZxdW90OzAmcXVvdDs8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoCBTa2V3PSZxdW90OzAm cXVvdDs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgIFRhcGVyWD0mcXVvdDswJnF1b3Q7PGJyPsKgwqDC oMKgwqDCoMKgwqDCoCBUYXBlclk9JnF1b3Q7MCZxdW90Ozxicj7CoMKgwqDCoMKgwqDCoMKgwqAg VHdpc3Q9JnF1b3Q7MCZxdW90Ozxicj7CoMKgwqDCoMKgwqDCoMKgwqAgVHdpc3RCZWdpbj0mcXVv dDswJnF1b3Q7IC8mZ3Q7PGJyPsKgwqDCoMKgwqDCoMKgICZsdDtQcm9maWxlPGJyPsKgwqDCoMKg wqDCoMKgwqDCoMKgIEJlZ2luPSZxdW90OzAmcXVvdDs8YnI+CsKgwqDCoMKgwqDCoMKgwqDCoMKg IEN1cnZlPSZxdW90OzEmcXVvdDs8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBFbmQ9JnF1b3Q7 MCZxdW90Ozxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEhvbGxvdz0mcXVvdDswJnF1b3Q7IC8m Z3Q7PGJyPsKgwqDCoMKgwqAgJmx0O1JheUVuZDxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHg9 JnF1b3Q7NDIuOTMyOTk4NjU3MjI2NTYyNSZxdW90Ozxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg IHk9JnF1b3Q7MjkuNjYwMDMyMjcyMzM4ODY3MTg3NSZxdW90Ozxicj4KwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCB6PSZxdW90OzMxLjM5OTMxODY5NTA2ODM1OTM3NSZxdW90Ozxicj7CoMKgwqDCoMKg wqDCoMKgwqDCoMKgIElzSW50ZXJzZWN0aW9uPSZxdW90OzAmcXVvdDsgLyZndDs8YnI+wqDCoMKg wqDCoCAmbHQ7UmF5U3RhcnQ8YnI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB4PSZxdW90OzQ4LjI4 MTQ4MjY5NjUzMzIwMzEyNSZxdW90Ozxicj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHk9JnF1b3Q7 MzIuMDYzMTUyMzEzMjMyNDIxODc1JnF1b3Q7PGJyPgrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIHo9 JnF1b3Q7MzQuMDkyMDEwNDk4MDQ2ODc1JnF1b3Q7IC8mZ3Q7PGJyPsKgwqDCoMKgwqAgJmx0O1Jh eVRhcmdldElkIHV1aWQ9JnF1b3Q7JnF1b3Q7IC8mZ3Q7PGJyPsKgwqDCoMKgwqAgJmx0O1JvdGF0 aW9uIHg9JnF1b3Q7MCZxdW90OyB5PSZxdW90OzAmcXVvdDsgej0mcXVvdDswJnF1b3Q7IHM9JnF1 b3Q7MSZxdW90OyAvJmd0Ozxicj7CoMKgwqDCoMKgICZsdDtTY2FsZSB4PSZxdW90OzAuNSZxdW90 OyB5PSZxdW90OzAuNSZxdW90OyB6PSZxdW90OzAuNSZxdW90OyAvJmd0Ozxicj4KwqDCoMKgwqDC oCAmbHQ7U3RhdGUgYm9vbD0mcXVvdDswJnF1b3Q7IC8mZ3Q7PGJyPsKgwqDCoCAmbHQ7L09iamVj dERhdGEmZ3Q7PGJyPiZsdDsvbGxzZCZndDs8YnI+PGJyPkV2ZW4gYmV0dGVyIHJlc3VsdHMgY291 bGQgYmUgYWNoaWV2ZWQgYnkgdXNpbmcgZGVmYXVsdCB2YWx1ZXMgZm9yIHNvbWUgYXR0cmlidXRl cy48YnI+PGJyPi0tIDxicj5DYXRoeTxicj4K --0015174c11628d20d50463b4195e-- From jwatte@gmail.com Tue Feb 24 17:36:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81A953A6928 for ; Tue, 24 Feb 2009 17:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zq4vKDAD0ND for ; Tue, 24 Feb 2009 17:36:53 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id A85E23A67EF for ; Tue, 24 Feb 2009 17:36:52 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so2611601ywh.49 for ; Tue, 24 Feb 2009 17:37:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=EEo3evrsMU58qfU7R54ti0DYVni565DsWdv66Ek7SLM=; b=A97vdwhhVe3Pd6aoWsQkKMt3G34J7r41FhqDRc4brzBKwo1pxHCKzb5jRw72kM9FwI FxuuzrzBPmswRvQ+mHSsk3nIVx02kXlmeSwMzKXuzixO4jSp/BLfnBBmvy7Yjp1PFtVR IAAKrLgwbEs2wm7Uny0yc08p43acXL1URgB6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qKKY5lRIczKTnCCCntUHaWDe5jYNEqvVhfKek5QVKKURw7VDFQhNSNSE9XtobgDuGP JRA2xT9Un+mdVZqXwnyeGS1Krpy87WwXplS6eQgeShBJgES5pJJ/akhKUv1S+rGoVsdz iLIOQ5Dy8o5scadjM2PzS7Pyhp17Osq73atzw= Received: by 10.100.133.1 with SMTP id g1mr190474and.106.1235525831195; Tue, 24 Feb 2009 17:37:11 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d38sm10511512and.49.2009.02.24.17.37.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 17:37:10 -0800 (PST) Message-ID: <49A4A0C4.3040908@gmail.com> Date: Tue, 24 Feb 2009 17:37:08 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <49A44928.10307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] XML serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 01:36:54 -0000 Meadhbh Hamrick (Infinity) wrote: > it sounds like you want to do some processing at points "b" and "c". > after it has been received by the transport and before it gets > un-marshalled / de-serialized. > Yes. In fact, my system may actually use the XML directly, without de-marshaling. The whole point of a data representation is that it is useful as-is, IMO :-) > > and also... is this a requirement of your system? or just the way that > seems right to you? > We currently have customer who do something similar based on data they get from us. Specifically, they get an entity data stream, and use semantically marked-up world geometry to do automated analysis of performance. One specific application is where their system will check whether soldiers traversing a street is exposing themselves too much to possible attack -- the output is qualitative information like "you put teammates 2 and 3 in the cone of fire from this doorway for too long at time 13:03 into the exercise" or "your team stacked against this structurally unsound wall at time 8:30 and stayed there for four minutes." That external application (not built or controlled by us) receives a text representation of entity data, and process that directly. It is not currently LLSD XML serialized data (for mostly obvious reasons :-), but if "MMSD" was capable of serving this use case in a useful (and not too chatty) way, then I would be all for it -- suitable standards are a good thing, and our customer would then also be able to tie their application into any virtual world that provides the same kind of data stream. Sincerely, jw From cathypfeffer@gmail.com Tue Feb 24 17:43:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FB883A67FC for ; Tue, 24 Feb 2009 17:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wubP28EMpqsv for ; Tue, 24 Feb 2009 17:43:21 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id DB6B23A677E for ; Tue, 24 Feb 2009 17:43:20 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 25so552724eya.31 for ; Tue, 24 Feb 2009 17:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=UBGRqF3qAw2bOPvOqse83g3/XDPuTZhajoRwd/ygzNA=; b=ORRUqg5DotiGK9E/Pk0xx+8VynD5lkZU1fKgBlG96jzX3Dcav7mqgYGXvKYxxf7PQ8 HAM7niyJ9kPaxtAo9CS//OpNScjVdtTDZxpSc/CVNVb1Jr1UUM8eoqNcv8YH9TGA4KV1 QZTV+kgLsijpvBe27UexVk9111iyOzGCJxGnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=q9SsoneidHGhe1GCzZupXM+ay98DdGlxtPu4Ezf7vNCDciANXzVF7mGkiAUPnSaFoR xryeamPgnqDFyNSfys5oxMHJj5OagWV/W48FtBmyaY0jSxzTepgkVTtrCtYof+lS4xHE QKnjBlRQURX4Q/tIQfMaxXVYctUAwxE/imzvQ= MIME-Version: 1.0 Received: by 10.210.17.14 with SMTP id 14mr125643ebq.181.1235526219645; Tue, 24 Feb 2009 17:43:39 -0800 (PST) Date: Wed, 25 Feb 2009 02:43:39 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174be6ea6ec19d0463b45dca Subject: [mmox] Details proposal X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 01:43:22 -0000 --0015174be6ea6ec19d0463b45dca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all, Infinity asked me to write down proposals to make LLSD a bit better. Honestly, I don't think it is really the way to go. I think the previous message has shown how much the current XML serialization is unsatisfying, due to the 1:1 paradigm. But I have promised to do such a proposal, so here we go: 1 - change the name from LLSD to VWSD 2 - add provision for different sizes for integers and floats. In XML that could mean an extra size="" attribute with a default to 32 bits so it needs not be specified in the majority of cases, in binary serialization that would mean new data codes 3 - add provision for unsigned data. In XML that would mean an extra signed="" attribute with a default to "yes" so it needs not be specified in the majority of cases, in the binary serialization that calls for more data codes too 4 - allow some shortcuts for an array of three reals and an array of 4 reals 5 - embed map entries into ... tags That's almost the same points as the ones that Jon has listed. But again, to do it in a real XML-ish way, the data types like should move to the DTD. I don't see any justification for them in an XML file. -- Cathy --0015174be6ea6ec19d0463b45dca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all,

Infinity asked me to write down proposals to make LLSD a bit= better.

Honestly, I don't think it is really the way to go. I t= hink the previous message has shown how much the current XML serialization = is unsatisfying, due to the 1:1 paradigm.

But I have promised to do such a proposal, so here we go:
1 - change= the name from LLSD to VWSD
2 - add provision for different sizes for in= tegers and floats. In XML that could mean an extra size=3D"" attr= ibute with a default to 32 bits so it needs not be specified in the majorit= y of cases, in binary serialization that would mean new data codes
3 - add provision for unsigned data. In XML that would mean an extra signed= =3D"" attribute with a default to "yes" so it needs not= be specified in the majority of cases, in the binary serialization that ca= lls for more data codes too
4 - allow some shortcuts for an array of three reals <vector> and an = array of 4 reals <quat>
5 - embed map entries into <e> ... &= lt;/e> tags

That's almost the same points as the ones that Jo= n has listed.

But again, to do it in a real XML-ish way, the data types like <inte= ger> should move to the DTD. I don't see any justification for them = in an XML file.

--
Cathy
--0015174be6ea6ec19d0463b45dca-- From cathypfeffer@gmail.com Tue Feb 24 17:53:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396263A63EC for ; Tue, 24 Feb 2009 17:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn0BT5tMBi+U for ; Tue, 24 Feb 2009 17:53:49 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id 0364F3A677E for ; Tue, 24 Feb 2009 17:53:48 -0800 (PST) Received: by ewy8 with SMTP id 8so499308ewy.13 for ; Tue, 24 Feb 2009 17:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Hhm2qV4t7XIza9sOwPtAgVKFqKkJnN2tpwDzZ03StW0=; b=e/zRjO+EhmdGJ5OJW185vkr64Xgsauy73UIGWjzIT7NwzHjEqisj7H45lW8pJd48fn cm2oDDL9XEe4NjFX1VPq6nOAIQNjUybA7H7BNDYXAUtvzQERuzyGO4l58+omG7sQ2VBR 3WtjSOg5hBEKTK5n+6PideYRppdo7oK+K9e3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vqtxfoPp+2P0mnxELuUPiKVNwefxoBEzG83bXgLMbBh9rtdsRAyHmGpBRbwpAX0yLC 5rCG6kup8b6nUJrmVfeXQB+EcMX6XQAAYr8azWKV8Zrp6xtzbbhlG7hdNzuoS1w5lO6d sz+ZDHItf1DFIhQahXyiuyYLjQYB+IWwpDzdE= MIME-Version: 1.0 Received: by 10.210.18.18 with SMTP id 18mr127072ebr.71.1235526847370; Tue, 24 Feb 2009 17:54:07 -0800 (PST) Date: Wed, 25 Feb 2009 02:54:07 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c0f24d916c90463b482c0 Subject: [mmox] unefficient binary serialization ? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 01:53:50 -0000 --0015174c0f24d916c90463b482c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Jon said: > They are in good hands. Direct3D, OLIVE, and a lot of other 3D systems > use XYZW. It's a bit like the question of row vectors on the left (D3D) > or column vectors on the right (OpenGL). There are two ways to do it, > and the world is split about equally. ;-), ok, good point. > But my point is that the binary serialization does not serve the needs > of what a binary serialization should do, which is save transmission > space. It contains both key and datatype, where the verbose key name is > typically inlined instead of sent by reference-to-external-schema. If > you can describe things with external schema, then you can save a LOT of > transmission space where it matters, which is in the binary serialization. That's precisely all the HUGE strength of LLSD. Having information about what the data is intermingled with the data itself makes it very flexible and future-proof. It allows for heterogeneous grids, even within a single provider. That's what enabled LL to stop shutting down their grid when they wanted to upgrade their servers, now they simply do smooth "rolling restarts". And of course that would make the interconnection of completly different virtual worlds WAY easier. Honestly, here, the bandwidth is not lost, compared to the advantages. In summary, their binary serialization is as flexible as XML data. Perhaps I'm wrong, but to me it's an unique case in all computer science of a binary format that would be so flexible. -- Cathy --0015174c0f24d916c90463b482c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jon said:
> They are in good hands. Direct3D, OLIVE, and a lot of oth= er 3D systems
> use XYZW. It's a bit like the question of row ve= ctors on the left (D3D)
> or column vectors on the right (OpenGL). T= here are two ways to do it,
> and the world is split about equally.

;-), ok, good point.

> But my point is that the binary serialization does no= t serve the needs
> of what a binary serialization should do, which = is save transmission
> space. It contains both key and datatype, where the verbose key name i= s
> typically inlined instead of sent by reference-to-external-schem= a. If
> you can describe things with external schema, then you can s= ave a LOT of
> transmission space where it matters, which is in the binary serializat= ion.

That's precisely all the HUGE strength of LLSD. Having info= rmation about what the data is intermingled with the data itself makes it v= ery flexible and future-proof. It allows for heterogeneous grids, even with= in a single provider. That's what enabled LL to stop shutting down thei= r grid when they wanted to upgrade their servers, now they simply do smooth= "rolling restarts". And of course that would make the interconne= ction of completly different virtual worlds WAY easier.

Honestly, here, the bandwidth is not lost, compared to the advantages.<= br>
In summary, their binary serialization is as flexible as XML data. P= erhaps I'm wrong, but to me it's an unique case in all computer sci= ence of a binary format that would be so flexible.

--
Cathy
--0015174c0f24d916c90463b482c0-- From cathypfeffer@gmail.com Tue Feb 24 18:00:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C61A3A6AE7 for ; Tue, 24 Feb 2009 18:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGusIkNmlJK9 for ; Tue, 24 Feb 2009 18:00:07 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id 77B3A3A6A90 for ; Tue, 24 Feb 2009 18:00:07 -0800 (PST) Received: by ewy8 with SMTP id 8so500600ewy.13 for ; Tue, 24 Feb 2009 18:00:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=DSAf81oPvgf9dI7up2bEllSFJ+9Fh/HbutaantVV/bU=; b=wI/WN5MdMlAG1cplywZ6WwrqZa342GgXDRdBrxnxsRGUexPYHquKMukdJ6um+H0acs G5qEV+907fEyebTQE8eXPE0T+jqohEFHam/LK82EM2t8M9dErKu+47t0EfeqVyIQ54JB nMxpJQ4GZSq92og2z4Vu5aS59dQZs/YmEDeBQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=fKPBWYbJBpdhfwR+0XFp06/SYbByyniaMRgOQro3sIZp+WpEmd7nTL7BD1QavSOQ+d HsL4NRsnDEzJQW5hy/8oTSca7zC9CJdwzfwQDqv/iQXXUa7+79P1UXYgcYQ9AFyXilU/ EElqppHBZKhzjNTdPpkIBMnjY8/BX4Mal6Bx8= MIME-Version: 1.0 Received: by 10.210.65.17 with SMTP id n17mr122700eba.130.1235527225266; Tue, 24 Feb 2009 18:00:25 -0800 (PST) Date: Wed, 25 Feb 2009 03:00:25 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c16de5f54520463b4996d Subject: [mmox] Bad effects of validation X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 02:00:08 -0000 --0015174c16de5f54520463b4996d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Lisa wrote: > > 1 - be easy to validate with a schema or DTD > > This is something we (in IETF) have found to be a *drawback* in an > extensible standard. Yes. Thanks. -- Cathy --0015174c16de5f54520463b4996d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lisa wrote:
> > 1 - be easy to validate with a schema or DTD
&g= t;
> This is something we (in IETF) have found to be a *drawback* in = an
> extensible standard.=C2=A0

Yes. Thanks.
--
Cathy
--0015174c16de5f54520463b4996d-- From jwatte@gmail.com Tue Feb 24 18:07:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF773A68B2 for ; Tue, 24 Feb 2009 18:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siKbwYfsuIC6 for ; Tue, 24 Feb 2009 18:07:24 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 07FC23A6857 for ; Tue, 24 Feb 2009 18:07:23 -0800 (PST) Received: by gxk22 with SMTP id 22so7948689gxk.13 for ; Tue, 24 Feb 2009 18:07:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0+PBFfsmlIT7dEcDeY2aZt+jU6KNIeHFybk4nfR4TcM=; b=k6MGN5Bp4E8vSA5H4BZW3vtHlZ475mHdzKkuiqZFjpc+R9XtMkctfdaPzA03v9kZrd +XaR/rJjpW0mcS1j9vwEmYM84D2ciLrLE9FguSCZUOStuJzcgUmfgfVbGf3t+9nZnUJA R84WvUUtI8orFeybhlR+GqICGG9Ma8XMcRR34= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TWMRl1qxu/TIdyRWQNplkVk1KnTGZORAx6+8crgIOQc5eMXkzsWvhtaeX+mXpKV73B K4Cwdx6qa/l/ZzcAXFXqgwSnGBlmTMGKARMyi6nKI9uKR0XR+dilZBbHMJtHCXvH1nhD /XiOX+hUb/XBFYwOvFOxX0j9CavKJlxPHFF/g= Received: by 10.100.13.6 with SMTP id 6mr406828anm.9.1235527662826; Tue, 24 Feb 2009 18:07:42 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c29sm1463543anc.43.2009.02.24.18.07.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 18:07:42 -0800 (PST) Message-ID: <49A4A7EB.2000905@gmail.com> Date: Tue, 24 Feb 2009 18:07:39 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Details proposal X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 02:07:25 -0000 Catherine Pfeffer wrote: > But again, to do it in a real XML-ish way, the data types like > should move to the DTD. I don't see any justification for > them in an XML file. Can you view a "xxSD" specification file as an alternative DTD? I e, the output of a specific xxSD file could be one or more of the following: 1) C++ source code that can marshal/demarshal structs to various serializations 2) An XML DTD 3) Python code that uses module "struct" and "xml.dom.minidom" to translate between XML and struct formats ... However, I think that you still haven't addressed one big concern, which is the schema-dependent transmission format. Given your XML-ish version of a packet, in binary, it could look something like: 1 byte 1 byte 1 byte 16 bytes 1 byte 1 byte 1 byte 16 bytes 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte (!) 1 byte 1 byte 1 byte 1 byte 1 byte 3 bytes 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte < vari-int: 16> 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 8 bytes 8 bytes 8 bytes 1 byte 1 byte 8 bytes 8 bytes 8 bytes 1 byte 16 bytes 1 byte 2 bytes 2 bytes 2 bytes 2 bytes 1 byte 2 bytes 2 bytes 2 bytes 1 byte 1 byte If I have counted right, that's 184 bytes, for a nice 600% savings over the XML-ish form, which in turn is a 250% savings over the "straight serialization" version. You could easily cut it in half or more by not sending default/empty properties, and by sending fp32, not double, for data values. Note that this encoding saves space in a few ways: 1) It uses the knowledge that the destination will have the schema to encode property references using small, context-dependent integers. 2) It uses the knowledge that each property has a defined type to avoid encoding the type explicitly. 3) It uses vari-int encoding (basically Google protocol buffers, but putting a sign bit in the first byte if the value is not in the 0..127 "optimized" range). 4) It uses fp16 for quaternions. There really is no reason to use more than that -- in fact, a fixed-point representation could probably get away with even less. For example 10 bits each for three components in the range [-0.78..0.78], and 2 bits telling you which component was dropped (you drop the biggest component, so the second-biggest is known to be smaller than sqrt(2)), and then re-construct by knowing it's normalized. But maybe going to that extreme for that particular datatype is overkill in the interoperability context :-) I think that the implicit knowledge of 1) and 2) are the important concepts to take away here, because they account for most of the savings. Sincerely, jw From jwatte@gmail.com Tue Feb 24 18:11:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02CDD3A68B2 for ; Tue, 24 Feb 2009 18:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dv+d161iSfLp for ; Tue, 24 Feb 2009 18:11:55 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 1C3653A68CE for ; Tue, 24 Feb 2009 18:11:55 -0800 (PST) Received: by gxk22 with SMTP id 22so7954324gxk.13 for ; Tue, 24 Feb 2009 18:12:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Jc+NzrQ5c0UQtlpvC9X8OnYImXrAYgfDTWL1cs9a6dk=; b=aI2bBbhDHhaKbMptxUe6CtKuQZsLrDCRxpNBRi+I8GUcpZ9GVge0UnOMC2VjSdH2Ea 8rkrXrffXfwxvMrLQ7sGdHxn282CZSJJMUuFlqFHsAeQKBggFKLy7xloSAudKbjN7XIv c/+81jwkvxlRpPrVMglsXPsN7B7KzK2tJyfik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=XTXzXPQqbBMI4pgO/CizYWNIZXPg1fPhRlgcDf0gzJnpiSz3LZ9wH98MSR5if2LhWq gAS+BTkg8jQqqypyGJ5HYs/f+w2bJwUqXfw+fWclSMTnzkVXZ9SwVkooxwTRlkXWTuOT LQLb+ACloPayCNAFI1fHUb2fwEH53KrvdwSnY= Received: by 10.100.120.15 with SMTP id s15mr129159anc.112.1235527933282; Tue, 24 Feb 2009 18:12:13 -0800 (PST) Received: from ?192.168.168.109? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b29sm7766343ana.11.2009.02.24.18.12.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Feb 2009 18:12:12 -0800 (PST) Message-ID: <49A4A8FA.607@gmail.com> Date: Tue, 24 Feb 2009 18:12:10 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] unefficient binary serialization ? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 02:11:56 -0000 Catherine Pfeffer wrote: > That's precisely all the HUGE strength of LLSD. Having information > about what the data is intermingled with the data itself makes it very > flexible and future-proof. But that is simply not necessary. If you transmit a reference to the schema you use when you initiate connection, then all future transmissions during that connection session can use the knowledge of that schema to highly optimize traffic. Network traffic is actually one of the scarce resources when you start scaling up really large virtual worlds. There are cases where an entire office (20 people or more) share a single T1 connection to the Internet, and expect to have a good virtual world experience for multiple users at the same time. > > Honestly, here, the bandwidth is not lost, compared to the advantages. > I think it is, because the size difference is quite significant. > In summary, their binary serialization is as flexible as XML data. > Perhaps I'm wrong, but to me it's an unique case in all computer > science of a binary format that would be so flexible. Don't overextend yourself :-) AIFF/RIFF has pretty much the same flexibility, as does TLV (also used in OSCAR), a number of "binary XML" proposals, and a number of protocols that have all done more or less the same thing ever since computers were interconnected on a larger scale in the '80s. Sincerely, jw From dyerbrookme@juno.com Tue Feb 24 18:17:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D032B3A68CE for ; Tue, 24 Feb 2009 18:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-Hkm-mYusW6 for ; Tue, 24 Feb 2009 18:17:00 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id E78A53A68B2 for ; Tue, 24 Feb 2009 18:17:00 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail20.vgs.untd.com [10.181.12.160]) by smtpout05.vgs.untd.com with SMTP id AABE4KLTBA2FY5GS for (sender ); Tue, 24 Feb 2009 18:17:05 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNz8bM2EFYIiKxwTl9+1P0qg== Received: (from dyerbrookme@juno.com) by webmail20.vgs.untd.com (jqueuemail) id N98AJXRV; Tue, 24 Feb 2009 18:16:14 PST Received: from [68.161.198.3] by webmail20.vgs.untd.com with HTTP: Wed, 25 Feb 2009 02:15:35 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Wed, 25 Feb 2009 02:15:35 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090224.211535.153.0@webmail20.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:3:2071281147 X-MAIL-INFO: 3205515951a001018060e55960f0751d9dd0f494bd6434d09d9d6d9dcdb9b90cb910c900591951104541c019ada0f0ad9075497560ad0d042d71156115c07500b14540 X-UNTD-Peer-Info: 10.181.12.160|webmail20.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 140 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 02:17:01 -0000 Christian, >I think we should start with a collection of use cases, see where we ca= n find common ground on these and then try to find which protocol or for= mat is best suited for it. We have proposals on the table which we can d= iscuss and weight the pro and cons of each. We also should IMHO wherever= we can use existing protocols instead of inventing our own. Good Lord, this is the most sensible thing I have ever seen on this list= ! Very sound advice. If you look here, for example: http://wiki.secondlife.com/wiki/Architecture_Working_Group#Design_Docume= nts in vain will you find any use cases, or at least not use cases discussed= in any sort of robust, community-supported manner. What are the use cases? *Thinks*. Um, I don't have any. I just make a new avatar when I go to ot= her worlds like There or SmallWorlds or Metaplace or OpenLife. It takes = a second. I can use the same name or a variant. I don't need my SL inven= tory in those other worlds because they have their own stuff that goes w= ith those worlds, and that's fine. = So, back to you. ____________________________________________________________ Click to get free auto insurance quotes from top companies. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTImHa16gnxj0sfrxZBGxxQ= iBVOmrhBkGzyP5qJt4RA08yNCxkVFKI/ From cathypfeffer@gmail.com Tue Feb 24 18:54:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C31053A69BA for ; Tue, 24 Feb 2009 18:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caP2w0nEUBKb for ; Tue, 24 Feb 2009 18:54:58 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id C2BE93A69A0 for ; Tue, 24 Feb 2009 18:54:57 -0800 (PST) Received: by ewy8 with SMTP id 8so511355ewy.13 for ; Tue, 24 Feb 2009 18:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=hvhwYcDxIxS+34URjRSE17s5qsJgL4gooakSS0Gf2fU=; b=nXBnYJ5Oka+YXBFBq0gKyBtjTRCu7vSJrz4WbAjOKEZaeuqtRHRxl0YEdEdt4pljmr ZG2MF3vs1A1CMEMpC/a8o1UvRN0RS+pvkCHATHdZzeWaV/q77Qmj4xuTqqWyaptufXu0 Tw7bE8Tpi5l6tfkfkfvzpGHpE+dmno2mESIZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ayop9vPyEzopYZI2/yZaNXQWAlEbNGnJYwVrkZAxz3V1lpFjmB2KCZ8XLP8Jwlasc+ EN3bmf1eOjmPvWHwuQiSc4fstu/3mLK1KPl4HIXNqEUjSx4wgiCcev0JLpBnPhnNf0sF rkOIE+e47Eritrp04OcCrzNzygF51y67O7r3o= MIME-Version: 1.0 Received: by 10.211.196.13 with SMTP id y13mr195249ebp.171.1235530516487; Tue, 24 Feb 2009 18:55:16 -0800 (PST) Date: Wed, 25 Feb 2009 03:55:16 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c0cec8b5e240463b55dbc Subject: [mmox] Even more compact binary serialization? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 02:54:59 -0000 --0015174c0cec8b5e240463b55dbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Can you view a "xxSD" specification file as an alternative DTD? I e, the > output of a specific xxSD file could be one or more of the following: > 1) C++ source code that can marshal/demarshal structs to various > serializations > 2) An XML DTD > 3) Python code that uses module "struct" and "xml.dom.minidom" to > translate between XML and struct formats > ... I am not sure I understand this question. I apologize, but English is not my language and I sometimes miss a few things. If the question is "could we build a DTD or a schema to describe the tags (, , etc.)", of course we could do it. That would even be the whole point of all subsequent works in this mailing list: describe the tags and their semantics to allow for virtual worlds interoperability. If your question is "Catherine, could you please write the DTD or the schema for this packet (the existing ObjectAdd packet)?" yes I could do this boring work, but I don't really see the point. > However, I think that you still haven't addressed one big concern, which > is the schema-dependent transmission format. Given your XML-ish version > of a packet, in binary, it could look something like: Why would we need two serializations? My point is, the current binary serialization is very good and could be used unchanged (with a few data type additions). I would even call it "binary XML" since it achieves the same goals of interoperability and flexibility as XML ;-). And it does it with the same mechanism by the way: by transporting both the data and the markup in one single file. But if we were to go for XML, then it should be real XML, and not a "dummy" transposition of the very good binary serialization, because the result does not match the paradigms behind XML, and is also very inefficient from a bandwidth point of view. > 1) It uses the knowledge that the destination will have the schema to > encode property references using small, context-dependent integers. Your binary serialization is very compact because it replaces a key (like "Taper_X" or "NextOwnerMask") with a small number (like 384 or 17). But the price to pay in terms of flexibility is also very high. Such "tags are numbers" approach reminds me of ISO 2709 ( http://en.wikipedia.org/wiki/ISO_2709). It's remarkable that such a standard has been written in the sixties, when room on a magnetic tape was very limited. As always, engineering is a matter of compromises. Given the high number of data types implied, the speed of evolution of virtual worlds, the huge dimensions of some grids, and the number and heterogeneity of worlds to interconnect, I think we should pay a lot of attention to flexibility, even though bandwidth concerns should not be forgotten. -- Cathy --0015174c0cec8b5e240463b55dbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Can you view a "xxSD" specification file as an alternative D= TD? I e, the
> output of a specific xxSD file could be one or more o= f the following:
> 1) C++ source code that can marshal/demarshal stru= cts to various
> serializations
> 2) An XML DTD
> 3) Python code that uses = module "struct" and "xml.dom.minidom" to
> trans= late between XML and struct formats
> ...

I am not sure I unde= rstand this question. I apologize, but English is not my language and I som= etimes miss a few things.

If the question is "could we build a DTD or a schema to describe t= he tags (<ObjectData>, <Path>, etc.)", of course we could = do it. That would even be the whole point of all subsequent works in this m= ailing list: describe the tags and their semantics to allow for virtual wor= lds interoperability.

If your question is "Catherine, could you please write the DTD or = the schema for this packet (the existing ObjectAdd packet)?" yes I cou= ld do this boring work, but I don't really see the point.


> However, I think that you still haven't addressed one big concern,= which
> is the schema-dependent transmission format. Given your XML= -ish version
> of a packet, in binary, it could look something like:=

Why would we need two serializations?

My point is, the current b= inary serialization is very good and could be used unchanged (with a few da= ta type additions). I would even call it "binary XML" since it ac= hieves the same goals of interoperability and flexibility as XML ;-). And i= t does it with the same mechanism by the way: by transporting both the data= and the markup in one single file.

But if we were to go for XML, then it should be real XML, and not a &qu= ot;dummy" transposition of the very good binary serialization, because= the result does not match the paradigms behind XML, and is also very ineff= icient from a bandwidth point of view.


> 1) It uses the knowledge that the destination will have the sc= hema to
> encode property references using small, context-dependent = integers.

Your binary serialization is very compact because it repla= ces a key (like "Taper_X" or "NextOwnerMask") with a sm= all number (like 384 or 17). But the price to pay in terms of flexibility i= s also very high.

Such "tags are numbers" approach reminds me of ISO 2709 (http://en.wikipedia.org/wiki/= ISO_2709). It's remarkable that such a standard has been written in= the sixties, when room on a magnetic tape was very limited.

As always, engineering is a matter of compromises. Given the high numbe= r of data types implied, the speed of evolution of virtual worlds, the huge= dimensions of some grids, and the number and heterogeneity of worlds to in= terconnect, I think we should pay a lot of attention to flexibility, even t= hough bandwidth concerns should not be forgotten.


--
Cathy
--0015174c0cec8b5e240463b55dbc-- From cathypfeffer@gmail.com Tue Feb 24 19:00:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A5E3A6874 for ; Tue, 24 Feb 2009 19:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiLNcVixJshK for ; Tue, 24 Feb 2009 19:00:15 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id A566D3A67AF for ; Tue, 24 Feb 2009 19:00:15 -0800 (PST) Received: by ewy8 with SMTP id 8so512285ewy.13 for ; Tue, 24 Feb 2009 19:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=cPPZi/Y0QGcQMx2EhYsAHuz+IOyAc00EhC4f/Wr9LvE=; b=owUPTM/BwL+9CQ7VEwBP6s5E5Su9/6JYZht8PyO7MZdbP+/C5FkxTk4fW15O5bawTz 32uubu+R8BKNrU44IW7C8+jq2uJLNJiZTNb58Y9MfNeC3CQLUqF2ByrKj9aYd3I17mDF sbfEeG4OBlO1VPy25DuTCHlbJS+aafdEl78Ms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=g6iyrbgWLPUS2KClc35Ntyyyx4mggerlYrd79/MoAY8Epwd/cdHOjymuJ1300RT+mW AUYdLi0pAMQZWpFM9dXtkK9Gtuwtf1rVL5GfwngTkISVQRUD7NNvefj+dMVSoq9jvcsa FIFgW/gGE4krlIkU8VwVdrpffvJQGk7H8qQ5M= MIME-Version: 1.0 Received: by 10.210.60.3 with SMTP id i3mr161757eba.189.1235530834016; Tue, 24 Feb 2009 19:00:34 -0800 (PST) Date: Wed, 25 Feb 2009 04:00:34 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c1d907878230463b57072 Subject: [mmox] Existing flexible binary standards X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:00:16 -0000 --0015174c1d907878230463b57072 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > > Perhaps I'm wrong, but to me it's an unique case in all computer > > science of a binary format that would be so flexible. > > Don't overextend yourself :-) Rather take it as a proof of my ignorance of many existing standards ;-). -- Cathy --0015174c1d907878230463b57072 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > Perhaps I'm wrong, but to me it's an unique case in all c= omputer
> > science of a binary format that would be so flexible.=
>
> Don't overextend yourself :-)

Ra= ther take it as a proof of my ignorance of many existing standards ;-).

--
Cathy
--0015174c1d907878230463b57072-- From infinity@lindenlab.com Tue Feb 24 19:45:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9ABD3A67DD for ; Tue, 24 Feb 2009 19:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdszXv4k4ZGq for ; Tue, 24 Feb 2009 19:45:09 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 13F9E3A67B2 for ; Tue, 24 Feb 2009 19:45:09 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 785C93DBC44B; Tue, 24 Feb 2009 19:45:28 -0800 (PST) Message-Id: <5DDFEDF9-139B-4F0D-B490-D83A7F244063@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Catherine Pfeffer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 19:45:26 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: [mmox] Changing the Name [was: Re: Details proposal] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:45:09 -0000 so... hope you don't mind.. i'm responding to different aspects of this proposal with different emails i'm sure some of my co-workers will pelt me with rotten vegetables for giving in, but sure, an affiliation neutral name ending in "SD" is something we can probably live with and is probably also appropriate. however.... i believe that to avoid confusion, we may want to keep the draft-llsd-hamrick-XX.txt naming scheme for just the FILE NAMES used in the ID repository. these things disappear after 6 months, so a year after we find consensus and the RFC goes through, we'll all have forgotten we ever considered the LLSD name. with tongue firmly in cheek, however, i might also suggest "XXSD" as it seems to have also gotten some mention in emails lately. On Feb 24, 2009, at 5:43 PM, Catherine Pfeffer wrote: > Hi all, > > Infinity asked me to write down proposals to make LLSD a bit better. > > Honestly, I don't think it is really the way to go. I think the > previous message has shown how much the current XML serialization is > unsatisfying, due to the 1:1 paradigm. > > But I have promised to do such a proposal, so here we go: > 1 - change the name from LLSD to VWSD > 2 - add provision for different sizes for integers and floats. In > XML that could mean an extra size="" attribute with a default to 32 > bits so it needs not be specified in the majority of cases, in > binary serialization that would mean new data codes > 3 - add provision for unsigned data. In XML that would mean an extra > signed="" attribute with a default to "yes" so it needs not be > specified in the majority of cases, in the binary serialization that > calls for more data codes too > 4 - allow some shortcuts for an array of three reals and an > array of 4 reals > 5 - embed map entries into ... tags > > That's almost the same points as the ones that Jon has listed. > > But again, to do it in a real XML-ish way, the data types like > should move to the DTD. I don't see any justification for > them in an XML file. > > -- > Cathy > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Tue Feb 24 19:49:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B6133A6A07 for ; Tue, 24 Feb 2009 19:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSN8hobjj9WQ for ; Tue, 24 Feb 2009 19:49:30 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 44DF33A69D7 for ; Tue, 24 Feb 2009 19:49:30 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 2B6943DBC44B; Tue, 24 Feb 2009 19:49:50 -0800 (PST) Message-Id: <1E712A17-6D23-471C-A827-CD86C1EDE59D@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Catherine Pfeffer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 19:49:47 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: [mmox] Representing Number Types [Was: Re: Details proposal] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 03:49:31 -0000 about sizes of ints as attributes. let me pose the question... what is the difference in terms of processing expectations if one sends '12' vs. sending '12' ? do we want to be in the business of mandating that the receiver actually check to see if the value is representable with the number of bits given, or do we just want to store the value somewhere? and what about '12' ? and what about "12"? if we allow that last fragment, and we require receivers to honor the size, then implementers MUST use arbitrary lengthed integers (i.e. bignum packages.) and it's hard to say things like "we're concerned about the efficiency of the XML parsing" while you're also saying "yeah... all ints should be bignums." but if we say something like.. "all right, we'll just limit the size to being a max of 128 bits," then we're effectively doing the same thing because not all languages that people would want to use (like python and PHP) support even native 64 bit ints. so unless we say that ints are at most 32 bits, then our python and PHP LLSD implementations will REQUIRE the use of bignums. so let me now pose another the question... what would happen if we just remove the bit width of number types from the proposal all together? would that kill anyone? it would, i believe, mandate an error condition be signaled should the remote peer send an encoding of an integer that you can't represent. or maybe you just do some magic behind the scenes and dynamically convert to a bignum if you're language supports it. or maybe we just drop that value on the floor? we say... "if you pass some pre-defined limit, you get the default value" this might be doable if everyone understood that when you're connecting to second life, we have so much python and PHP we're gonna freak if you start using 64 bit ints and double double floats, but when you connect to OSGrid, 64 bit ints are fine. or you could do some sort of negotiation up front asking the peer, "what's your preferred and maximum integer and float size?" it is unfortunate that all of these options are sub-optimal, but that's what it looks like to me. about signedness assuming we can all find agreement that the machines we're using all use 2's complement notation, the main difference between signed and unsigned seems to be behavior when a right shift operation occurs. couldn't we just say that when an endpoint needs a value to be a signed value, it stores it in a signed integral container and when it needs it to be an unsigned value, it stores it in an unsigned integral container? On Feb 24, 2009, at 5:43 PM, Catherine Pfeffer wrote: > Hi all, > > Infinity asked me to write down proposals to make LLSD a bit better. > > Honestly, I don't think it is really the way to go. I think the > previous message has shown how much the current XML serialization is > unsatisfying, due to the 1:1 paradigm. > > But I have promised to do such a proposal, so here we go: > 1 - change the name from LLSD to VWSD > 2 - add provision for different sizes for integers and floats. In > XML that could mean an extra size="" attribute with a default to 32 > bits so it needs not be specified in the majority of cases, in > binary serialization that would mean new data codes > 3 - add provision for unsigned data. In XML that would mean an extra > signed="" attribute with a default to "yes" so it needs not be > specified in the majority of cases, in the binary serialization that > calls for more data codes too > 4 - allow some shortcuts for an array of three reals and an > array of 4 reals > 5 - embed map entries into ... tags > > That's almost the same points as the ones that Jon has listed. > > But again, to do it in a real XML-ish way, the data types like > should move to the DTD. I don't see any justification for > them in an XML file. > > -- > Cathy > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From eh2th-mmox@yahoo.com Tue Feb 24 20:19:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99E663A69D7 for ; Tue, 24 Feb 2009 20:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qybUEP3gJiWe for ; Tue, 24 Feb 2009 20:19:11 -0800 (PST) Received: from web65709.mail.ac4.yahoo.com (web65709.mail.ac4.yahoo.com [76.13.9.101]) by core3.amsl.com (Postfix) with SMTP id 3E35E3A67CF for ; Tue, 24 Feb 2009 20:19:11 -0800 (PST) Received: (qmail 95745 invoked by uid 60001); 25 Feb 2009 04:19:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=bE1kKH/nNtEwvmx4eY+gfW5CV9vAXinYh+TPwLigbf5KzO5ERlgz5JGkOtptNYfuMYEQaT+ESpQSEqAg3YnFt4fR0RBDIUTGZfBt44cEyU9xLRePRQfjNZgWYGa8SGnlvCcbMuhF7MSmxXdypEZUn4CT6xuYbpTxPwS65+pa6hI=; X-YMail-OSG: 6kZqIsYVM1kLAh5WRIBXmBA52fTZ0Tv4hCf2P_lLlEq23Yf_g6sj9jVslOPE3giIKQl2iUmENpDDgS14Zm5I7cxcWWJjkbx3KVuyDrJJFd0s6lyxgx982lGVfOruSx_iX.evr.SU83CZsrmUBWPG6Vi3a.9yLSmBbKepwjcGasfmCQ6oKYPpJgH5XQV_Q_GAot2BZnr61yoweUcuW9Wh40cp6A-- Received: from [72.220.236.152] by web65709.mail.ac4.yahoo.com via HTTP; Tue, 24 Feb 2009 20:19:30 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: Date: Tue, 24 Feb 2009 20:19:30 -0800 (PST) From: eh2th-mmox@yahoo.com To: Catherine Pfeffer , mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1580952824-1235535570=:94038" Message-ID: <256728.94038.qm@web65709.mail.ac4.yahoo.com> Subject: Re: [mmox] Example of what could be a real XML LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 04:19:12 -0000 --0-1580952824-1235535570=:94038 Content-Type: text/plain; charset=us-ascii Apologies if I missed the answer if it was in an earlier message... The "XML way" message appears to be loosly typed. How could a parser create an object from that XML data and know the difference between an integer and a float, or a UUID and a string? --Tom ________________________________ From: Catherine Pfeffer To: mmox@ietf.org Sent: Tuesday, February 24, 2009 5:24:40 PM Subject: [mmox] Example of what could be a real XML LLSD Hello, Here is a real LLSD packet. Below I'll show how it could look like if we would abandon the 1:1 mapping to binary serialization. If transposing 1:1 the binary encoding, the packet is 2688 bytes long. If doing it in a more xml-ish way, the packet is 1065 bytes long. That's 40 % of the length the current LLSD proposal generates. It's also more legible by humans, easier to validate and easier to parse. Those figures include 2 spaces of indentation at each tag level, and all the newline characters. First the "transposition of binary serialization" way: AgentData AgentId 81466fc7-276f-455d-9b72-8316e9712535 GroupId SessionId 4bbb6fa9-e649-4507-a709-8831c237c4ee ObjectData BypassRaycast 1 EveryoneMask AAAAAA== Flags AAAAAg== GroupMask AAAAAA== Material 3 NextOwnerMask AAjAAA== PCode 9 Path Begin 0 Curve 16 End 0 RadiusOffset 0 Revolutions 0 ScaleX 100 ScaleY 100 ShearX 0 ShearY 0 Skew 0 TaperX 0 TaperY 0 Twist 0 TwistBegin 0 Profile Begin 0 Curve 1 End 0 Hollow 0 RayEnd 42.9329986572265625 29.6600322723388671875 31.399318695068359375 RayEndIsIntersection 0 RayStart 48.281482696533203125 32.063152313232421875 34.092010498046875 RayTargetId Rotation 0 0 0 1 Scale 0.5 0.5 0.5 State 0 Now the "XML" way: Even better results could be achieved by using default values for some attributes. -- Cathy --0-1580952824-1235535570=:94038 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Apologies if I missed the answer if it was in an earlier message.= ..

The "XML way" message appears to be loosly type= d. How could a parser create an object from that XML data and know the diff= erence between an integer and a float, or a UUID and a string?=A0

--Tom

From: Catherine Pfe= ffer <cathypfeffer@gmail.com>
T= o: mmox@ietf.org
Sent:<= /span> Tuesday, February 24, 2009 5:24:40 PM
Subject: [mmox] Example of what could be a real XML LLSD=

=0AHello,

Here is a real LLSD packet. Below I'll show= how it could look like if we would abandon the 1:1 mapping to binary seria= lization.

If transposing 1:1 the binary encoding, the packet is 2688= bytes long. If doing it in a more xml-ish way, the packet is 1065 bytes lo= ng. That's 40 % of the length the current LLSD proposal generates. It's als= o more legible by humans, easier to validate and easier to parse. Those fig= ures include 2 spaces of indentation at each tag level, and all the newline= characters.
=0A
First the "transposition of binary serialization" wa= y:

<llsd>
=A0 <map>
=A0=A0=A0 <key>AgentData</key>=
=A0=A0=A0 <map>
=A0=A0=A0=A0=A0 <key>AgentId</key>
=A0= =A0=A0=A0=A0 <uuid>81466fc7-276f-455d-9b72-8316e9712535</uuid>
=0A= =A0=A0=A0=A0=A0 <key>GroupId</key>
=A0=A0=A0=A0=A0 <uuid/>
= =A0=A0=A0=A0=A0 <key>SessionId</key>
=A0=A0=A0=A0=A0 <uuid>4bbb= 6fa9-e649-4507-a709-8831c237c4ee</uuid>
=A0=A0=A0 </map>
=A0=A0= =A0 <key>ObjectData</key>
=0A=A0=A0=A0 <map>
=A0=A0=A0=A0=A0= <key>BypassRaycast</key>
=A0=A0=A0=A0=A0 <boolean>1</boolea= n>
=A0=A0=A0=A0=A0 <key>EveryoneMask</key>
=A0=A0=A0=A0=A0 <= binary encoding=3D"base64">AAAAAA=3D=3D</binary>
=0A=A0=A0=A0=A0=A0 &= lt;key>Flags</key>
=A0=A0=A0=A0=A0 <binary encoding=3D"base64">AAA= AAg=3D=3D</binary>
=A0=A0=A0=A0=A0 <key>GroupMask</key>
=A0= =A0=A0=A0=A0 <binary encoding=3D"base64">AAAAAA=3D=3D</binary>
=0A= =A0=A0=A0=A0=A0 <key>Material</key>
=A0=A0=A0=A0=A0 <integer>3&= lt;/integer>
=A0=A0=A0=A0=A0 <key>NextOwnerMask</key>
=A0=A0=A0= =A0=A0 <binary encoding=3D"base64">AAjAAA=3D=3D</binary>
=A0=A0=A0= =A0=A0 <key>PCode</key>
=0A=A0=A0=A0=A0=A0 <integer>9</integ= er>
=A0=A0=A0=A0=A0 <key>Path</key>
=A0=A0=A0=A0=A0 <map>=A0=A0=A0=A0=A0=A0=A0 <key>Begin</key>
=A0=A0=A0=A0=A0=A0=A0 <= integer>0</integer>
=A0=A0=A0=A0=A0=A0=A0 <key>Curve</key>
= =0A=A0=A0=A0=A0=A0=A0=A0 <integer>16</integer>
=A0=A0=A0=A0=A0=A0= =A0 <key>End</key>
=A0=A0=A0=A0=A0=A0=A0 <integer>0</integer= >
=A0=A0=A0=A0=A0=A0=A0 <key>RadiusOffset</key>
=A0=A0=A0=A0=A0= =A0=A0 <integer>0</integer>
=A0=A0=A0=A0=A0=A0=A0 <key>Revoluti= ons</key>
=0A=A0=A0=A0=A0=A0=A0=A0 <integer>0</integer>
=A0= =A0=A0=A0=A0=A0=A0 <key>ScaleX</key>
=A0=A0=A0=A0=A0=A0=A0 <int= eger>100</integer>
=A0=A0=A0=A0=A0=A0=A0 <key>ScaleY</key>
= =A0=A0=A0=A0=A0=A0=A0 <integer>100</integer>
=A0=A0=A0=A0=A0=A0=A0= <key>ShearX</key>
=0A=A0=A0=A0=A0=A0=A0=A0 <integer>0</inte= ger>
=A0=A0=A0=A0=A0=A0=A0 <key>ShearY</key>
=A0=A0=A0=A0=A0=A0= =A0 <integer>0</integer>
=A0=A0=A0=A0=A0=A0=A0 <key>Skew</ke= y>
=A0=A0=A0=A0=A0=A0=A0 <integer>0</integer>
=A0=A0=A0=A0=A0= =A0=A0 <key>TaperX</key>
=0A=A0=A0=A0=A0=A0=A0=A0 <integer>0<= ;/integer>
=A0=A0=A0=A0=A0=A0=A0 <key>TaperY</key>
=A0=A0=A0=A0= =A0=A0=A0 <integer>0</integer>
=A0=A0=A0=A0=A0=A0=A0 <key>Twist= </key>
=A0=A0=A0=A0=A0=A0=A0 <integer>0</integer>
=A0=A0=A0= =A0=A0=A0=A0 <key>TwistBegin</key>
=0A=A0=A0=A0=A0=A0=A0=A0 <in= teger>0</integer>
=A0=A0=A0=A0=A0 </map>
=A0=A0=A0=A0=A0 <ke= y>Profile</key>
=A0=A0=A0=A0=A0 <map>
=A0=A0=A0=A0=A0=A0=A0 <= ;key>Begin</key>
=A0=A0=A0=A0=A0=A0=A0 <integer>0</integer>
= =A0=A0=A0=A0=A0=A0=A0 <key>Curve</key>
=0A=A0=A0=A0=A0=A0=A0=A0 &l= t;integer>1</integer>
=A0=A0=A0=A0=A0=A0=A0 <key>End</key>
= =A0=A0=A0=A0=A0=A0=A0 <integer>0</integer>
=A0=A0=A0=A0=A0=A0=A0 &= lt;key>Hollow</key>
=A0=A0=A0=A0=A0=A0=A0 <integer>0</integer><= br>=A0=A0=A0=A0=A0 </map>
=0A=A0=A0=A0=A0=A0 <key>RayEnd</key><= br>=A0=A0=A0=A0=A0 <array>
=A0=A0=A0=A0=A0=A0=A0 <real>42.93299865= 72265625</real>
=A0=A0=A0=A0=A0=A0=A0 <real>29.6600322723388671875= </real>
=A0=A0=A0=A0=A0=A0=A0 <real>31.399318695068359375</real= >
=0A=A0=A0=A0=A0=A0 </array>
=A0=A0=A0=A0=A0 <key>RayEndIsInte= rsection</key>
=A0=A0=A0=A0=A0 <boolean>0</boolean>
=A0=A0= =A0=A0=A0 <key>RayStart</key>
=A0=A0=A0=A0=A0 <array>
=A0=A0= =A0=A0=A0=A0=A0 <real>48.281482696533203125</real>
=0A=A0=A0=A0=A0= =A0=A0=A0 <real>32.063152313232421875</real>
=A0=A0=A0=A0=A0=A0=A0= <real>34.092010498046875</real>
=A0=A0=A0=A0=A0 </array>
= =A0=A0=A0=A0=A0 <key>RayTargetId</key>
=A0=A0=A0=A0=A0 <uuid/><= br>=A0=A0=A0=A0=A0 <key>Rotation</key>
=0A=A0=A0=A0=A0=A0 <arra= y>
=A0=A0=A0=A0=A0=A0=A0 <real>0</real>
=A0=A0=A0=A0=A0=A0=A0 &= lt;real>0</real>
=A0=A0=A0=A0=A0=A0=A0 <real>0</real>
=A0=A0= =A0=A0=A0=A0=A0 <real>1</real>
=A0=A0=A0=A0=A0 </array>
=A0= =A0=A0=A0=A0 <key>Scale</key>
=0A=A0=A0=A0=A0=A0 <array>
=A0= =A0=A0=A0=A0=A0=A0 <real>0.5</real>
=A0=A0=A0=A0=A0=A0=A0 <real= >0.5</real>
=A0=A0=A0=A0=A0=A0=A0 <real>0.5</real>
=A0=A0=A0= =A0=A0 </array>
=A0=A0=A0=A0=A0 <key>State</key>
=A0=A0=A0= =A0=A0 <integer>0</integer>
=0A=A0=A0=A0 </map>
=A0 </map= >
</llsd>

Now the "XML" way:

<llsd>=A0 <AgentData
=A0=A0=A0=A0=A0 AgentId=3D"81466fc7-276f-455d-9b72-83= 16e9712535"
=A0=A0=A0=A0=A0 GroupId=3D""
=0A=A0=A0=A0=A0=A0 SessionId= =3D"4bbb6fa9-e649-4507-a709-8831c237c4ee" />
=A0=A0=A0 <ObjectData=A0=A0=A0=A0=A0=A0=A0 BypassRaycast=3D"1"
=A0=A0=A0=A0=A0=A0=A0 Everyon= eMask=3D"0x00000000"
=A0 =A0 =A0 =A0 Flags=3D"0x00000002"
=0A=A0=A0= =A0=A0=A0=A0=A0 GroupMask=3D"0x00000000"
=A0=A0=A0=A0=A0=A0=A0 Material= =3D"3"
=A0=A0=A0=A0=A0=A0=A0 NextOwnerMask=3D"0x0008C000"
=A0=A0=A0= =A0=A0=A0=A0 PCode=3D"9">
=A0=A0=A0=A0=A0 <Path
=A0=A0=A0=A0=A0=A0= =A0=A0=A0 Begin=3D"0"
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Curve=3D"16"
=0A=A0= =A0=A0=A0=A0=A0=A0=A0=A0 End=3D"0"
=A0=A0=A0=A0=A0=A0=A0=A0=A0 RadiusOff= set=3D"0"
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Revolutions=3D"0"
=A0=A0=A0=A0= =A0=A0=A0=A0=A0 ScaleX=3D"100"
=A0=A0=A0=A0=A0=A0=A0=A0=A0 ScaleY=3D"100= "
=A0=A0=A0=A0=A0=A0=A0=A0=A0 ShearX=3D"0"
=A0=A0=A0=A0=A0=A0=A0=A0= =A0 ShearY=3D"0"
=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0 Skew=3D"0"
=A0=A0=A0= =A0=A0=A0=A0=A0=A0 TaperX=3D"0"
=A0=A0=A0=A0=A0=A0=A0=A0=A0 TaperY=3D"0"=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Twist=3D"0"
=A0=A0=A0=A0=A0=A0=A0=A0=A0 = TwistBegin=3D"0" />
=A0=A0=A0=A0=A0=A0=A0 <Profile
=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Begin=3D"0"
=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Curve=3D"1= "
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 End=3D"0"
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 Hollow=3D"0" />
=A0=A0=A0=A0=A0 <RayEnd
=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 x=3D"42.9329986572265625"
=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 y=3D"29.6600322723388671875"
=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 z=3D"31.399318695068359375"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IsInte= rsection=3D"0" />
=A0=A0=A0=A0=A0 <RayStart
=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 x=3D"48.281482696533203125"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 y=3D"32.063152313232421875"
=0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 z= =3D"34.092010498046875" />
=A0=A0=A0=A0=A0 <RayTargetId uuid=3D"" /><= br>=A0=A0=A0=A0=A0 <Rotation x=3D"0" y=3D"0" z=3D"0" s=3D"1" />
=A0= =A0=A0=A0=A0 <Scale x=3D"0.5" y=3D"0.5" z=3D"0.5" />
=0A=A0=A0=A0=A0= =A0 <State bool=3D"0" />
=A0=A0=A0 </ObjectData>
</llsd>
=
Even better results could be achieved by using default values for some = attributes.

--
Cathy
=0A
--0-1580952824-1235535570=:94038-- From dcolivares@gmail.com Tue Feb 24 21:04:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5563A67E9 for ; Tue, 24 Feb 2009 21:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eKLqZNP4ZmD for ; Tue, 24 Feb 2009 21:04:01 -0800 (PST) Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 7289A3A685F for ; Tue, 24 Feb 2009 21:03:59 -0800 (PST) Received: by bwz5 with SMTP id 5so6422014bwz.13 for ; Tue, 24 Feb 2009 21:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7ssxn62JC62fB/XuJXvERVoFGm0MB9EZQdObqHiO3RE=; b=DzuYP9X/967wBTUblQCsRYB+TNry5JcJaHydhpmc8uCuwbGf4b3fB7ffe1RgIjLQuT BSjjUFyHrRG04FKL/UwWLUvzuEajXRGCwKxqz03p9rLq5aNfDAWzoZqb0xr+F3lW25nL 5fAnCNp1rpCbIDj+CwDREbVLad5uqx0YAOzqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RsNmAX7/0qzCs/WvFozH+fY/tI8TupDgdjhCuDplKVN+6GXsIhrmlvN4crY1k+WmZR dAf+51VFnN+PFhwFzsS+RLLDVXvlOmnUhaMt2gqqSPKLL+AKhIBdNdTkavofg2fxgVNO GNxnFrwRQ7AoA9cTb32qH5DeKD5Wf7bubr/WA= MIME-Version: 1.0 Received: by 10.103.172.9 with SMTP id z9mr140975muo.109.1235538258661; Tue, 24 Feb 2009 21:04:18 -0800 (PST) In-Reply-To: <1E712A17-6D23-471C-A827-CD86C1EDE59D@lindenlab.com> References: <1E712A17-6D23-471C-A827-CD86C1EDE59D@lindenlab.com> Date: Wed, 25 Feb 2009 00:04:18 -0500 Message-ID: From: Dan Olivares To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] Representing Number Types [Was: Re: Details proposal] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 05:04:02 -0000 To understand why there would be a request for this, you also have to understand some of the issues that people have delt with when working with LLSD. Take boolean values encoded uints for instance. Often times in the current use of LLSD, uints are used to transfer several bit values encoded into a 32 bit unsigned integer. Additionally, there's currently no way to represent an unsigned integer in LLSD. This means that you must represent it as a base64 encoded byte array and often results in ugly, non human readable XML Serializations, for example, in parcels; ParcelFlagsfiAESw=3D=3D Then, you also have a single uint value that represents the ID of the auction associated with the parcel that is also encoded as a base64 encoded object. This is not a group of encoded boolean values, this is a single value. AuctionIDAAAAAA=3D=3D Then, you have 64 bit unsigned integers (aka, bignums) that are represented with base64 encoded binary; HandleAAIkAAAEJAA=3D Then, you have IP addresses that are represented with base64 encoded binary= ; IP2FIQPA=3D=3D Then, you have Timestamps that are represented with base64 encoded binary; TimeStampSLs0lw=3D=3D Then, you have bitmap data, that is also represented with base64 encoded bi= nary; BitmapAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= AAAAAAAAAAAAAAAwD8AAAAAAADAPwAAAAAAAMA/AAAAAAAAwD8AAAAAAADAPwAAAAAAAMA/AAAA= AAAAwD8AAAAAAADAPwAAAAAAAMA/AAAAAAAAwD8AAAAAAADAPwAAAAAAAOA/AAAAAAAA4D8AAAA= AAADgPwAAAAAAAAAAAAAAAAAAAAA=3D Do you see how ambiguous the "binary" type is?. In my opinion, the only valid use of it in an XML encoding listed above, is the bitmap. XML encodings are /meant/ to be as human readable as possible. Then, you have boolean values that are represented as integers; MediaAutoScale1 Then, in addition to having timestamp values represented in the binary encoding, you also have unix time since epoch values represented as a 'real' start_time1232962915.3859558 In terms of a 'parcel' on LLGrid (which is a cut unit of land where you can define specific settings as well as sell, purchase, ban, etc), the settings of the parcel are represented by a set of boolean values. These boolean values are encoded into a 32 bit unsigned integer called "ParcelFlags". (A few of of the 32 acceptable boolean values are: AllowDamage AllowAPrimitiveEntry AllowDeedToGroup AllowFly CreateObjects ForSale AllowGroupScripts). over LLSD, this looks like; ParcelFlagsfiAESw=3D=3D. However, if that wasn't complicated and unreadable enough.. It turns out that all unsigned integer values are also represented /big endian/ and integers are represented /little endian/. Therefore, to be able to actually use those values, you have to; 1. Know the agreed upon encoding, (which bits refer to which boolean flags) 2. You must convert it from the non human readable "fiAESw=3D=3D" into an array of bytes 3. You must convert it to your system's 'endian-ness' 4. You must use bitwise operations to decode the flags. There are a plethora of types of values that use this human non-readable boolean value encoding on things ranging from region settings, to object data, to permissions. They're all over the place. So, that's the issue that I'm trying to solve when I ask for more datatypes and more specific data types. There's also use consistancy issues and mentioned above and key naming consistency issues in existing uses of LLSD. Something can be named 'AgentID' in one CAP name/value key, and named 'agent_id' in another. Best Regards Daniel Olivares On Tue, Feb 24, 2009 at 10:49 PM, Meadhbh Hamrick (Infinity) wrote: > about sizes of ints as attributes. > > let me pose the question... what is the difference in terms of processing > expectations if one sends > > '12' > > vs. sending > > '12' ? > > do we want to be in the business of mandating that the receiver actually > check to see if the value is representable with the number of bits given,= or > do we just want to store the value somewhere? > > and what about '12' ? and what about " size=3D"4096">12"? > > if we allow that last fragment, and we require receivers to honor the siz= e, > then implementers MUST use arbitrary lengthed integers (i.e. bignum > packages.) and it's hard to say things like "we're concerned about the > efficiency of the XML parsing" while you're also saying "yeah... all ints > should be bignums." > > but if we say something like.. "all right, we'll just limit the size to > being a max of 128 bits," then we're effectively doing the same thing > because not all languages that people would want to use (like python and > PHP) support even native 64 bit ints. > > so unless we say that ints are at most 32 bits, then our python and PHP L= LSD > implementations will REQUIRE the use of bignums. > > so let me now pose another the question... > > what would happen if we just remove the bit width of number types from th= e > proposal all together? would that kill anyone? > > it would, i believe, mandate an error condition be signaled should the > remote peer send an encoding of an integer that you can't represent. or > maybe you just do some magic behind the scenes and dynamically convert to= a > bignum if you're language supports it. > > or maybe we just drop that value on the floor? we say... "if you pass som= e > pre-defined limit, you get the default value" > > this might be doable if everyone understood that when you're connecting t= o > second life, we have so much python and PHP we're gonna freak if you star= t > using 64 bit ints and double double floats, but when you connect to OSGri= d, > 64 bit ints are fine. > > or you could do some sort of negotiation up front asking the peer, "what'= s > your preferred and maximum integer and float size?" > > it is unfortunate that all of these options are sub-optimal, but that's w= hat > it looks like to me. > > about signedness > > assuming we can all find agreement that the machines we're using all use = 2's > complement notation, the main difference between signed and unsigned seem= s > to be behavior when a right shift operation occurs. > > couldn't we just say that when an endpoint needs a value to be a signed > value, it stores it in a signed integral container and when it needs it t= o > be an unsigned value, it stores it in an unsigned integral container? > > On Feb 24, 2009, at 5:43 PM, Catherine Pfeffer wrote: > >> Hi all, >> >> Infinity asked me to write down proposals to make LLSD a bit better. >> >> Honestly, I don't think it is really the way to go. I think the previous >> message has shown how much the current XML serialization is unsatisfying= , >> due to the 1:1 paradigm. >> >> But I have promised to do such a proposal, so here we go: >> 1 - change the name from LLSD to VWSD >> 2 - add provision for different sizes for integers and floats. In XML th= at >> could mean an extra size=3D"" attribute with a default to 32 bits so it = needs >> not be specified in the majority of cases, in binary serialization that >> would mean new data codes >> 3 - add provision for unsigned data. In XML that would mean an extra >> signed=3D"" attribute with a default to "yes" so it needs not be specifi= ed in >> the majority of cases, in the binary serialization that calls for more d= ata >> codes too >> 4 - allow some shortcuts for an array of three reals and an arr= ay >> of 4 reals >> 5 - embed map entries into ... tags >> >> That's almost the same points as the ones that Jon has listed. >> >> But again, to do it in a real XML-ish way, the data types like >> should move to the DTD. I don't see any justification for them in an XML >> file. >> >> -- >> Cathy >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From dcolivares@gmail.com Tue Feb 24 21:17:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3731828C11A for ; Tue, 24 Feb 2009 21:17:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ORaevg6vJFa for ; Tue, 24 Feb 2009 21:17:15 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 429CB3A6AA0 for ; Tue, 24 Feb 2009 21:17:13 -0800 (PST) Received: by fxm11 with SMTP id 11so3432863fxm.13 for ; Tue, 24 Feb 2009 21:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zryyQNhAWPmaemXMhf2DjdHIMf9D/dr+iLAoCYDZ9k4=; b=G5IKrDwTFoxRsXNVFGHQNQPns/EJHCivdMLDcsbd9EzxnhU/sl6EK20nb1iFkxTeOj vgzWTns86WhOJoHfLNm3dLuNbGgxXN2dNRngwOcmNZ83S++Bx+vV8b/IrupjfkdzuX7Y /G2VWwS+u4nG8GvpzsOh1Zt9+2mnSUI48y5hQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QOqbhpKn8Oursr/wEz10yZcNGRIl5rBxgkC9gVmDCuvYCFmUWv964uTKZ71wDZdJAn GYy1/9c/xQ2H/hnrZ3/ctIa4VYHghkIOu4gKj3SMhWKhQb/eKbLg+opkVGkohRT28rpf 2gKs+ky1v8rApHx2gN5pdjzct4z+jvEW9pSPg= MIME-Version: 1.0 Received: by 10.103.240.15 with SMTP id s15mr134634mur.82.1235539051657; Tue, 24 Feb 2009 21:17:31 -0800 (PST) In-Reply-To: <5DDFEDF9-139B-4F0D-B490-D83A7F244063@lindenlab.com> References: <5DDFEDF9-139B-4F0D-B490-D83A7F244063@lindenlab.com> Date: Wed, 25 Feb 2009 00:17:31 -0500 Message-ID: From: Dan Olivares To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Changing the Name [was: Re: Details proposal] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 05:17:16 -0000 I'm good either way here really. LLSD, XXSD, VWSD. The naming really doesn't matter much to me. Changing it from LLSD to XXSD might make more people feel comfortable that it isn't 'weighted' in the direction of Linden Lab. This may also have an effect on uptake. Best Regards Daniel Olivares On Tue, Feb 24, 2009 at 10:45 PM, Meadhbh Hamrick (Infinity) wrote: > so... hope you don't mind.. i'm responding to different aspects of this > proposal with different emails > > i'm sure some of my co-workers will pelt me with rotten vegetables for > giving in, but sure, an affiliation neutral name ending in "SD" is something > we can probably live with and is probably also appropriate. however.... i > believe that to avoid confusion, we may want to keep the > draft-llsd-hamrick-XX.txt naming scheme for just the FILE NAMES used in the > ID repository. these things disappear after 6 months, so a year after we > find consensus and the RFC goes through, we'll all have forgotten we ever > considered the LLSD name. > > with tongue firmly in cheek, however, i might also suggest "XXSD" as it > seems to have also gotten some mention in emails lately. > > On Feb 24, 2009, at 5:43 PM, Catherine Pfeffer wrote: > >> Hi all, >> >> Infinity asked me to write down proposals to make LLSD a bit better. >> >> Honestly, I don't think it is really the way to go. I think the previous >> message has shown how much the current XML serialization is unsatisfying, >> due to the 1:1 paradigm. >> >> But I have promised to do such a proposal, so here we go: >> 1 - change the name from LLSD to VWSD >> 2 - add provision for different sizes for integers and floats. In XML that >> could mean an extra size="" attribute with a default to 32 bits so it needs >> not be specified in the majority of cases, in binary serialization that >> would mean new data codes >> 3 - add provision for unsigned data. In XML that would mean an extra >> signed="" attribute with a default to "yes" so it needs not be specified in >> the majority of cases, in the binary serialization that calls for more data >> codes too >> 4 - allow some shortcuts for an array of three reals and an array >> of 4 reals >> 5 - embed map entries into ... tags >> >> That's almost the same points as the ones that Jon has listed. >> >> But again, to do it in a real XML-ish way, the data types like >> should move to the DTD. I don't see any justification for them in an XML >> file. >> >> -- >> Cathy >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From infinity@lindenlab.com Tue Feb 24 21:41:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F5653A6811 for ; Tue, 24 Feb 2009 21:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.478 X-Spam-Level: X-Spam-Status: No, score=-3.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0cQFaBOup-x for ; Tue, 24 Feb 2009 21:41:05 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 535933A659B for ; Tue, 24 Feb 2009 21:41:04 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id A09123DBC44B; Tue, 24 Feb 2009 21:41:24 -0800 (PST) Message-Id: <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49A4A8FA.607@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 21:41:22 -0800 References: <49A4A8FA.607@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: [mmox] The Structure and Interpretation of LLSD Messages [Was: Re: unefficient binary serialization ?] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 05:41:06 -0000 but here's one reason we like LLSD... imagine you have two systems that are interoperating... one is owned my me, the other is owned by catherine. cathy's customers are all banks and insurance companies and are very conservative, so cathy want's to err on the side of caution in terms of when she deploys new features. i on the other hand throw caution to the wind because my customers are all first person shooter fanatics between the ages of 13 and 21 who demand the latest features as soon as possible (otherwise they use david's server) it's not hard to see we're eventually going to introduce version slew which will make it difficult for cathy and i to participate in the unregulated business of marketing virtual life insurance policies to my customers. in this example, i'm trying to point out that the both the option to retain version parity with cathy and the option to upgrade to the latest version are not without drawbacks. now.. imagine we have a PDU with three members while the second version adds a member. for simplicity's sake, let's say they're all integers. if used the DTD to define the validation for the message, the first version of the message might look like: 13 42 93 while the new version would look like this: 13 42 93 161 so when i (expecting the new version) consume the old version, i do not see qux. but my parser doesn't complain because instead of the DTD of the new PDU, i see a reference to the old PDU and say to myself... "it's okay... it's just an older version," and i do whatever i have to do to continue processing in the absence of the qux member i was expecting. even if i'm doing validation, it's okay, i'm pulling the DTD from the old definition, so we're cool. now... when cathy consumes the new PDU, something similar happens. she see's a DTD she's not familiar with, but it's all good.. she grabs teh DTD from URL specified in teh DOCTYPE and moves on with her life, hoping that new version PDU didn't change the semantics of the three values (foo, bar and baz) she's familiar with. and then one day she receives this from david: 13 2008-12-15T13:17:23.235Z 93 161 aha! david, trying to steal my core demographic away from me has upgraded to the most recent beta version of the software (now with 13% more explosions) but this is now a serious problem for cathy. the "shape" of the structured data now does not match. what does she do? how does she convert that date into an integer? and this is the question we keep running into as we deploy "loosely coupled" systems. how do we fail gracefully and ensure robustness in the presence of PDU schema mismatches? the way linden answered this question was to develop LLSD, an abstract type system with conversions and defaults. the way we would probably have defined the message above would have been something like: foo 13 bar 2008-12-15T13:17:23.235Z baz 93 qux 161 we don't include the doctype id 'cause our DTD never changes. in this example the LLSD message is shorter 'cause we don't include the DOCTYPE id, but even after removing the DOCTYPE id and changing the outer element to llsd, the compressed version of the LLSD message is only seven bytes larger. (an increase from 154 bytes to 161 bytes, an efficiency loss of 4.5%) however, i can guarantee you that it took a lot less time to code the parser because.. well.. we already had a parser that knew how to unwrap LLSD messages. but we haven't got to the interesting part yet. there is a processing expectation with LLSD. we assume we're de- serializing a message into a dynamic language like ECMAScript or Python. For languages like C++ and Java we create a class that emulates this feature. so.. all LLSD PDUs are de-serialized into these LLSD objects, and inside our application(s), it's these objects that get passed around. so we might have code that looks like: public foo ( string message ) { LLSD llsd; llsd = LLSD.From( message, LLSD.XML_SERIALIZATION ); System.err.println( "hey! foo was %d.\n", (int) llsd.at( "foo" ).asInteger() ); if( ( (int) llsd.at("bar").asInteger() > 100 ) || ( (int) llsd.at("bar").asInteger() < 0 ) ) { System.err.println( "bar is not a percentage\n" ); System.haltAndCatchFire(); } if( (int) llsd.at("bar").asInteger() < 40 ) { System.err.println( "sorry, this percent margin is way too small for me to be interested.\n" ); System.haltAndCatchFire(); } . . . } forgive the javaisms, the alternative was smalltalk and well... let's not go there. for the sake of argument let's say we had already determined it was in XML format by looking at the Content-Type: header from the request. so what we're doing here is not out of the ordinary... we create an instance of the LLSD class from the serialization. and we print some logging messages. and we then try to see if bar is between 0 an 100. but the object representing "foo" is a date, not an integer. what happens? in our current implementation of LLSD, we attempt to convert, but notice that the conversion from date to integer has no semantic meaning. because the conversion is "illegal," the default value is returned. the result of running this fragment would be something like hey! foo was 0. sorry, this percent margin is way too small for me to be interested. the important feature here is that we did not allow the "presentation layer" to create an error. we did the best we could to interpret the sense of the message, even to the point of making a nonsensical conversion. we allow this to happen because we assume that at the application layer, we're going to do parameter checking. so the reasoning was... if we're going to be doing parameter checking anyway, why would we want to allow the presentation layer to fail a message that would have generated a result that could be checked at the application layer? i hope you've enjoyed this installment of "the structure and interpretation of LLSD messages." and i hope it helps explain our motivations for designing LLSD and it's serializations the way we did... and while we have a metric tonne of code that uses the existing LLSD DTD, ultimately, any additional serialization format that preserves these processing expectations could be wedged into the system. serialization formats that did not support these processing expectations would cause considerable heart burn. -cheers -meadhbh On Feb 24, 2009, at 6:12 PM, Jon Watte wrote: > Catherine Pfeffer wrote: >> That's precisely all the HUGE strength of LLSD. Having information >> about what the data is intermingled with the data itself makes it >> very flexible and future-proof. > But that is simply not necessary. If you transmit a reference to the > schema you use when you initiate connection, then all future > transmissions during that connection session can use the knowledge > of that schema to highly optimize traffic. Network traffic is > actually one of the scarce resources when you start scaling up > really large virtual worlds. There are cases where an entire office > (20 people or more) share a single T1 connection to the Internet, > and expect to have a good virtual world experience for multiple > users at the same time. > >> >> Honestly, here, the bandwidth is not lost, compared to the >> advantages. >> > > I think it is, because the size difference is quite significant. > >> In summary, their binary serialization is as flexible as XML data. >> Perhaps I'm wrong, but to me it's an unique case in all computer >> science of a binary format that would be so flexible. > > Don't overextend yourself :-) AIFF/RIFF has pretty much the same > flexibility, as does TLV (also used in OSCAR), a number of "binary > XML" proposals, and a number of protocols that have all done more or > less the same thing ever since computers were interconnected on a > larger scale in the '80s. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From dcolivares@gmail.com Tue Feb 24 22:27:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9A0C3A6919 for ; Tue, 24 Feb 2009 22:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.14 X-Spam-Level: X-Spam-Status: No, score=-1.14 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_61=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iczaw7M5vjEO for ; Tue, 24 Feb 2009 22:27:03 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id A950B3A68A5 for ; Tue, 24 Feb 2009 22:27:02 -0800 (PST) Received: by fxm11 with SMTP id 11so3461481fxm.13 for ; Tue, 24 Feb 2009 22:27:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=H9RrZJT/J2qRNbttyx7/sEkAqoLU1dMOEcF1K+verLo=; b=ni4ZxpQYguJXw3KKB9umE53gmAxt2doeXthRyFPz/JVKehWcKhpUBbMZWAkhp8S/DU QfZcUTdTEq1LtKTtjcdaCMGIsR2TMMo94sPLfnKKAGyZl9oq5SlmsIJXwqJQ2LLJZ2jL 5P3dTb56BdCdK/JLRiks+TSVY7DMVmGdMsZVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cOujEUZS6kYRiZ094mPz4AsLU0sANZjkU81T1XIsjKnDkQqi72JNFObWtD1ILsmVoZ U5TY4jPWbKkijCQJ9xp6KL+n/xGwlThSV1VPyumQXnCKGx5YWeMQ3tGXznDGBEDyi4NM aqnaQlQS6OanJbWdSUBkUARKfyrCKsgRfBJ6U= MIME-Version: 1.0 Received: by 10.103.244.4 with SMTP id w4mr160983mur.90.1235543237965; Tue, 24 Feb 2009 22:27:17 -0800 (PST) In-Reply-To: <49A4563A.5060008@gmail.com> References: <49A4563A.5060008@gmail.com> Date: Wed, 25 Feb 2009 01:27:17 -0500 Message-ID: From: Dan Olivares To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] Compact Binary Serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 06:27:04 -0000 Hmm, Just one thing to point out here; 127,255,127 100.0,75.3,28.6 0.5,-0.5,0.5,0.5 might seem ok, however, consider what happens when someone in a locale with a different way of displaying the number tries to figure out what this means? In the United States, the following number format applies: (-)123,456,789.= 00 In Germany, the following number format applies: 123.456.789,00 In Russia and Finland, the following number format applies: 123=A0456=A0789= ,00 This, in my opinion, is the case for separating them with explicit separations within the syntax using non-ambiguious terms Is 127,255,127, one hundred twenty seven million two hundred fifty five thousand one hundred twenty seven? Is 100.0,75.3,28.6 one hundred thousand and seventy five tenths? Best Regards Daniel Olivares On Tue, Feb 24, 2009 at 3:19 PM, Jon Watte wrote: > Catherine Pfeffer wrote: >> >> (in the order x, y, z, s and not math's order s, x, y, z, that's one of >> Second Life's strangenesses) >> > > They are in good hands. Direct3D, OLIVE, and a lot of other 3D systems us= e > XYZW. It's a bit like the question of row vectors on the left (D3D) or > column vectors on the right (OpenGL). There are two ways to do it, and th= e > world is split about equally. > > >> LLSD (simplifying): >> =A0 =A0 LLIDL says: nose orientation is an array of four fp32s >> =A0 =A0 LLSD data over the wire: 0.5,-0.5,0.5,0.5 >> > > Why do you need to send "floats" at all? > >> >> I see this as another example of "Yeah, that's strange XML, but it maps >> 1:1 to a nice and natural binary serialization" :-(. >> > > I think the binary serialization in LLSD is too verbose. My suggestion wa= s > to allow the SD language to express type information to the point where y= ou > can assume the data types from the context. For example, to update > properties on an object, you would need to send, in binary, something lik= e: > > > ( ) * > > "number-of-updates" is a small integer, so will typically fit in a byte. > "property-id" is a small integer in the context of "object-id" and thus w= ill > typically take one byte. "data-for-property" for a quaternion stored as f= our > fp16 is 8 bytes. Thus, the actual storage for this one property (in the > context of where it's used) is 9 bytes; the total message size (assuming > there is only one property value) is 10 bytes plus the size of an object > identifier. > > Note that "data-for-property" is ONLY the raw data, not with any indicati= on > of what that data is. The schema for the entity already describes what th= at > data is, so you don't need to send that with every binary packet you send= . > Thus, in that form of binary serialization, you optimize for transmission > size, which is important for interactive, real-time transmissions. When y= ou > want a more "resilient" format, and size doesn't matter, you simply use X= ML > instead. > > To clarify: object of id has some type. That type has some > schema, that maps small-integer property-id values to string-name and > data-type. Typically, when you encounter an object, you will understand t= he > type/structure of that object once, but you will see changes to propertie= s > many times. And, in systems which have fewer types than objects (which is > most systems except for SL, I think), you have additional savings by only > needing to encounter a type once, and then that work is re-used for each > object of the same type. > > In this context, the schema for the object type would be described in som= e > data description language. That language could perhaps be one area where > something like LLSD would make sense -- but LLSD, as it stands, is not up= to > the task IMO. Hence, my suggestions (one of which is to support external > schema for transfer encoding efficiency). > > Btw: if you know that you will have the schema when you > serialize/de-serialize objects, then the "more natural" XML encoding woul= d > also map easily to the internal binary format, because all the data you n= eed > about whether things are arrays or ints or whatnot is available through t= he > schema, so the more natural "1,2,3,4= " > XML serialization would also be possible (and, IMO, desirable). > >> Now back to your question: "should we move the type information to the >> schema, as all people do in XML?". The answer is probably: "no, because = we >> want to keep a simple 1:1 mapping with the binary serialization". >> > > But my point is that the binary serialization does not serve the needs of > what a binary serialization should do, which is save transmission space. = It > contains both key and datatype, where the verbose key name is typically > inlined instead of sent by reference-to-external-schema. If you can descr= ibe > things with external schema, then you can save a LOT of transmission spac= e > where it matters, which is in the binary serialization. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From infinity@lindenlab.com Tue Feb 24 22:27:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6CB3A6B51 for ; Tue, 24 Feb 2009 22:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b30x5qDdFNwo for ; Tue, 24 Feb 2009 22:27:15 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 883A03A68A5 for ; Tue, 24 Feb 2009 22:27:15 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id DE3CD3DBC44D; Tue, 24 Feb 2009 22:27:34 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Catherine Pfeffer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 22:27:33 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Example of what could be a real XML LLSD X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 06:27:16 -0000 again... getting back to the discussion of efficiency... if we were concerned about the size of XML messages being sent over HTTP, i would suspect the first thing we would do would be to use the "Content- Encoding: gzip" header. Without changing the data, this would result in a Content-Length of 635 octets for the first (traditional LLSD) message and a Content-Length of 547 octets for the second (XMLish PDU), a full 86% of the traditional LLSD. which, not surprisingly is about the same percentage if you remove whitespace from both messages and remove the superfluous encoding attributes to the binaries. however... you can be a little more radical... if you preserve the LLSD processing expectations described in a previous message and you remove the elements that are defaults, you wind up with a message that is 462 octets after compression. fwiw.. i did the same thing to the JSON encoding and came up with a 477 octet message. so.. without resorting to radicality, the new PDU style saves you 14% but comes at the price of requiring you to write a specialized XML parser that understands how to take data out of the new PDU and into a data structure of some sort. -cheers -meadhbh On Feb 24, 2009, at 5:24 PM, Catherine Pfeffer wrote: > Hello, > > Here is a real LLSD packet. Below I'll show how it could look like > if we would abandon the 1:1 mapping to binary serialization. > > If transposing 1:1 the binary encoding, the packet is 2688 bytes > long. If doing it in a more xml-ish way, the packet is 1065 bytes > long. That's 40 % of the length the current LLSD proposal generates. > It's also more legible by humans, easier to validate and easier to > parse. Those figures include 2 spaces of indentation at each tag > level, and all the newline characters. > > First the "transposition of binary serialization" way: > > > > AgentData > > AgentId > 81466fc7-276f-455d-9b72-8316e9712535 > GroupId > > SessionId > 4bbb6fa9-e649-4507-a709-8831c237c4ee > > ObjectData > > BypassRaycast > 1 > EveryoneMask > AAAAAA== > Flags > AAAAAg== > GroupMask > AAAAAA== > Material > 3 > NextOwnerMask > AAjAAA== > PCode > 9 > Path > > Begin > 0 > Curve > 16 > End > 0 > RadiusOffset > 0 > Revolutions > 0 > ScaleX > 100 > ScaleY > 100 > ShearX > 0 > ShearY > 0 > Skew > 0 > TaperX > 0 > TaperY > 0 > Twist > 0 > TwistBegin > 0 > > Profile > > Begin > 0 > Curve > 1 > End > 0 > Hollow > 0 > > RayEnd > > 42.9329986572265625 > 29.6600322723388671875 > 31.399318695068359375 > > RayEndIsIntersection > 0 > RayStart > > 48.281482696533203125 > 32.063152313232421875 > 34.092010498046875 > > RayTargetId > > Rotation > > 0 > 0 > 0 > 1 > > Scale > > 0.5 > 0.5 > 0.5 > > State > 0 > > > > > Now the "XML" way: > > > AgentId="81466fc7-276f-455d-9b72-8316e9712535" > GroupId="" > SessionId="4bbb6fa9-e649-4507-a709-8831c237c4ee" /> > BypassRaycast="1" > EveryoneMask="0x00000000" > Flags="0x00000002" > GroupMask="0x00000000" > Material="3" > NextOwnerMask="0x0008C000" > PCode="9"> > Begin="0" > Curve="16" > End="0" > RadiusOffset="0" > Revolutions="0" > ScaleX="100" > ScaleY="100" > ShearX="0" > ShearY="0" > Skew="0" > TaperX="0" > TaperY="0" > Twist="0" > TwistBegin="0" /> > Begin="0" > Curve="1" > End="0" > Hollow="0" /> > x="42.9329986572265625" > y="29.6600322723388671875" > z="31.399318695068359375" > IsIntersection="0" /> > x="48.281482696533203125" > y="32.063152313232421875" > z="34.092010498046875" /> > > > > > > > > Even better results could be achieved by using default values for > some attributes. > > -- > Cathy > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From morgaine.dinova@googlemail.com Tue Feb 24 22:45:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1619A3A6919 for ; Tue, 24 Feb 2009 22:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQoV0RjZlgBz for ; Tue, 24 Feb 2009 22:45:31 -0800 (PST) Received: from mail-fx0-f167.google.com (mail-fx0-f167.google.com [209.85.220.167]) by core3.amsl.com (Postfix) with ESMTP id 4016E28C120 for ; Tue, 24 Feb 2009 22:45:29 -0800 (PST) Received: by fxm11 with SMTP id 11so3470190fxm.13 for ; Tue, 24 Feb 2009 22:45:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QOt8OBN3GvqMvhiHdTm/5uETV5E55mrRR7/sgcnXP+Y=; b=I2SzZTNbkUozamLLcHze3WbxSMVhcGKBQVNYPE/EHUCnzElkufCmWfdCpMxnMdqEbd X1mci7mF5RFWf5HBwaDOSHEigJxHdPm2nEUEE++qRSecpRd6mpDvAVsy1hEx4y/gXCdt U1gP/Oc4zL3Feku6VSWmwrw90y/MbYC9b1Ue0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rXQ1y2r2sak888z+WoDwOaTdvZDuZ40/2H5dIIV1zLw/ZRuTYnatCIVoxz+51buaDJ Ra8nk7By/HeSwcpc2TGOD14GsKAcauR3UCcc7M88nHHmWlywTLU3G6f8HIZzHABopN+1 1tzIroJvc066c5GE3tZGDphWCRL7nP46oLeLE= MIME-Version: 1.0 Received: by 10.181.200.6 with SMTP id c6mr214315bkq.44.1235544348305; Tue, 24 Feb 2009 22:45:48 -0800 (PST) In-Reply-To: <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> References: <49A4A8FA.607@gmail.com> <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> Date: Wed, 25 Feb 2009 06:45:48 +0000 Message-ID: From: Morgaine To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=001636c5a444fc2b8a0463b8955f Cc: mmox@ietf.org Subject: Re: [mmox] The Structure and Interpretation of LLSD Messages [Was: Re: unefficient binary serialization ?] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 06:45:33 -0000 --001636c5a444fc2b8a0463b8955f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Excellent background on LLSD, Infinity! It raises a question: On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: while we have a metric tonne of code that uses the existing LLSD DTD, > ultimately, any additional serialization format that preserves these > processing expectations could be wedged into the system. serialization > formats that did not support these processing expectations would cause > considerable heart burn. > > One serialization format that many have mentioned here is Google's Protocol Buffers. While I have barely started to examine PB myself, it is very clear that this serialization is extraordinarily efficient on-the-wire and also at both ends of the wire, as well as catering for the continual change that is inherent in large, evolving systems. A interest in extending the 3-way serialization of XXSD to Protocol Buffers follows naturally. The question that is raised by the quoted paragraph is whether Protocol Buffers "*preserves these processing expectations*". If it does then extending the set of serializations to PB is work that could be done by those interested in it, as an open project, and picked up by other users of XXSD if they wish. Potentially, the acceleration could be quite significant, and hence the benefit to Limited Capability Clients very important. On the other hand, if it does not "*preserve these processing expectations*" then there could be a problem. Do Lindens (or anyone else here) have any insight on this? Morgaine. On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > but here's one reason we like LLSD... > > imagine you have two systems that are interoperating... one is owned my me, > the other is owned by catherine. > > cathy's customers are all banks and insurance companies and are very > conservative, so cathy want's to err on the side of caution in terms of when > she deploys new features. > > i on the other hand throw caution to the wind because my customers are all > first person shooter fanatics between the ages of 13 and 21 who demand the > latest features as soon as possible (otherwise they use david's server) > > it's not hard to see we're eventually going to introduce version slew which > will make it difficult for cathy and i to participate in the unregulated > business of marketing virtual life insurance policies to my customers. in > this example, i'm trying to point out that the both the option to retain > version parity with cathy and the option to upgrade to the latest version > are not without drawbacks. > > now.. imagine we have a PDU with three members while the second version > adds a member. for simplicity's sake, let's say they're all integers. > > if used the DTD to define the validation for the message, the first version > of the message might look like: > > > 1.0//EN" "http://example.com/pdu/1.0/pdutastic.dtd"> > > 13 > 42 > 93 > > > while the new version would look like this: > > > 1.1//EN" "http://example.com/pdu/1.1/pdutastic.dtd"> > > 13 > 42 > 93 > 161 > > > so when i (expecting the new version) consume the old version, i do not see > qux. but my parser doesn't complain because instead of the DTD of the new > PDU, i see a reference to the old PDU and say to myself... "it's okay... > it's just an older version," and i do whatever i have to do to continue > processing in the absence of the qux member i was expecting. even if i'm > doing validation, it's okay, i'm pulling the DTD from the old definition, so > we're cool. > > now... when cathy consumes the new PDU, something similar happens. she > see's a DTD she's not familiar with, but it's all good.. she grabs teh DTD > from URL specified in teh DOCTYPE and moves on with her life, hoping that > new version PDU didn't change the semantics of the three values (foo, bar > and baz) she's familiar with. > > and then one day she receives this from david: > > > 1.2//EN" "http://example.com/pdu/1.2/pdutastic.dtd"> > > 13 > 2008-12-15T13:17:23.235Z > 93 > 161 > > > aha! david, trying to steal my core demographic away from me has upgraded > to the most recent beta version of the software (now with 13% more > explosions) > > but this is now a serious problem for cathy. the "shape" of the structured > data now does not match. what does she do? how does she convert that date > into an integer? > > and this is the question we keep running into as we deploy "loosely > coupled" systems. how do we fail gracefully and ensure robustness in the > presence of PDU schema mismatches? > > the way linden answered this question was to develop LLSD, an abstract type > system with conversions and defaults. > > the way we would probably have defined the message above would have been > something like: > > > > > foo > 13 > bar > 2008-12-15T13:17:23.235Z > baz > 93 > qux > 161 > > > > we don't include the doctype id 'cause our DTD never changes. in this > example the LLSD message is shorter 'cause we don't include the DOCTYPE id, > but even after removing the DOCTYPE id and changing the outer element to > llsd, the compressed version of the LLSD message is only seven bytes larger. > (an increase from 154 bytes to 161 bytes, an efficiency loss of 4.5%) > however, i can guarantee you that it took a lot less time to code the parser > because.. well.. we already had a parser that knew how to unwrap LLSD > messages. > > but we haven't got to the interesting part yet. > > there is a processing expectation with LLSD. we assume we're de-serializing > a message into a dynamic language like ECMAScript or Python. For languages > like C++ and Java we create a class that emulates this feature. so.. all > LLSD PDUs are de-serialized into these LLSD objects, and inside our > application(s), it's these objects that get passed around. so we might have > code that looks like: > > public foo ( string message ) { > LLSD llsd; > > llsd = LLSD.From( message, LLSD.XML_SERIALIZATION ); > > System.err.println( "hey! foo was %d.\n", (int) llsd.at( "foo" > ).asInteger() ); > > if( ( (int) llsd.at("bar").asInteger() > 100 ) || ( (int) llsd.at("bar").asInteger() > < 0 ) ) { > System.err.println( "bar is not a percentage\n" ); > System.haltAndCatchFire(); > } > > > if( (int) llsd.at("bar").asInteger() < 40 ) { > System.err.println( "sorry, this percent margin is way too > small for me to be interested.\n" ); > System.haltAndCatchFire(); > } > . > . > . > } > > forgive the javaisms, the alternative was smalltalk and well... let's not > go there. > > for the sake of argument let's say we had already determined it was in XML > format by looking at the Content-Type: header from the request. > > so what we're doing here is not out of the ordinary... we create an > instance of the LLSD class from the serialization. > > and we print some logging messages. > > and we then try to see if bar is between 0 an 100. > > but the object representing "foo" is a date, not an integer. what happens? > > in our current implementation of LLSD, we attempt to convert, but notice > that the conversion from date to integer has no semantic meaning. because > the conversion is "illegal," the default value is returned. > > the result of running this fragment would be something like > > hey! foo was 0. > sorry, this percent margin is way too small for me to be interested. > > the important feature here is that we did not allow the "presentation > layer" to create an error. we did the best we could to interpret the sense > of the message, even to the point of making a nonsensical conversion. we > allow this to happen because we assume that at the application layer, we're > going to do parameter checking. so the reasoning was... if we're going to be > doing parameter checking anyway, why would we want to allow the presentation > layer to fail a message that would have generated a result that could be > checked at the application layer? > > i hope you've enjoyed this installment of "the structure and interpretation > of LLSD messages." and i hope it helps explain our motivations for designing > LLSD and it's serializations the way we did... and while we have a metric > tonne of code that uses the existing LLSD DTD, ultimately, any additional > serialization format that preserves these processing expectations could be > wedged into the system. serialization formats that did not support these > processing expectations would cause considerable heart burn. > > -cheers > -meadhbh > > On Feb 24, 2009, at 6:12 PM, Jon Watte wrote: > > Catherine Pfeffer wrote: >> >>> That's precisely all the HUGE strength of LLSD. Having information about >>> what the data is intermingled with the data itself makes it very flexible >>> and future-proof. >>> >> But that is simply not necessary. If you transmit a reference to the >> schema you use when you initiate connection, then all future transmissions >> during that connection session can use the knowledge of that schema to >> highly optimize traffic. Network traffic is actually one of the scarce >> resources when you start scaling up really large virtual worlds. There are >> cases where an entire office (20 people or more) share a single T1 >> connection to the Internet, and expect to have a good virtual world >> experience for multiple users at the same time. >> >> >>> Honestly, here, the bandwidth is not lost, compared to the advantages. >>> >>> >> I think it is, because the size difference is quite significant. >> >> In summary, their binary serialization is as flexible as XML data. >>> Perhaps I'm wrong, but to me it's an unique case in all computer science of >>> a binary format that would be so flexible. >>> >> >> Don't overextend yourself :-) AIFF/RIFF has pretty much the same >> flexibility, as does TLV (also used in OSCAR), a number of "binary XML" >> proposals, and a number of protocols that have all done more or less the >> same thing ever since computers were interconnected on a larger scale in the >> '80s. >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --001636c5a444fc2b8a0463b8955f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Excellent background on LLSD, Infinity!=A0 It raises a question:

On = Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) = <infinity@lindenlab.com>= ; wrote:

while we have= a metric tonne of code that uses the existing LLSD DTD, ultimately, any additional serialization format that preserves these processing expectations could be wedged into the system. serialization formats that did not support these processing expectations would cause considerable heart burn.
=A0

One serialization format that many have mentioned here= is Google's Protocol Buffers.=A0 While I have barely started to examin= e PB myself, it is very clear that this serialization is extraordinarily ef= ficient on-the-wire and also at both ends of the wire, as well as catering = for the continual change that is inherent in large, evolving systems.=A0 A = interest in extending the 3-way serialization of XXSD to Protocol Buffers f= ollows naturally.

The question that is raised by the quoted paragraph is whether Protocol= Buffers "preserves these processing expectations".=A0 If = it does then extending the set of serializations to PB is work that could b= e done by those interested in it, as an open project, and picked up by othe= r users of XXSD if they wish.=A0 Potentially, the acceleration could be qui= te significant, and hence the benefit to Limited Capability Clients very im= portant.

On the other hand, if it does not "preserve these processing ex= pectations" then there could be a problem.

Do Lindens (or a= nyone else here) have any insight on this?

Morgaine.







On Wed, Feb 25, 2009 at 5:41= AM, Meadhbh Hamrick (Infinity) <infinity@lindenlab.com> wrote:
but here's one reason we like LLSD...

imagine you have two systems that are interoperating... one is owned my me,= the other is owned by catherine.

cathy's customers are all banks and insurance companies and are very co= nservative, so cathy want's to err on the side of caution in terms of w= hen she deploys new features.

i on the other hand throw caution to the wind because my customers are all = first person shooter fanatics between the ages of 13 and 21 who demand the = latest features as soon as possible (otherwise they use david's server)=

it's not hard to see we're eventually going to introduce version sl= ew which will make it difficult for cathy and i to participate in the unreg= ulated business of marketing virtual life insurance policies to my customer= s. in this example, i'm trying to point out that the both the option to= retain version parity with cathy and the option to upgrade to the latest v= ersion are not without drawbacks.

now.. imagine we have a PDU with three members while the second version add= s a member. for simplicity's sake, let's say they're all intege= rs.

if used the DTD to define the validation for the message, the first version= of the message might look like:

<?xml version=3D"1.0"?>
<!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined Derivatives ML = PDU 1.0//EN" "http://example.com/pdu/1.0/pdutastic.dtd"><= br> <pdutastic>
=A0<foo type=3D"integer">13</foo>
=A0<bar type=3D"integer">42</bar>
=A0<baz type=3D"integer">93</baz>
</pdutastic>

while the new version would look like this:

<?xml version=3D"1.0"?>
<!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined Derivatives ML = PDU 1.1//EN" "http://example.com/pdu/1.1/pdutastic.dtd"><= br> <pdutastic>
=A0<foo type=3D"integer">13</foo>
=A0<bar type=3D"integer">42</bar>
=A0<baz type=3D"integer">93</baz>
=A0<qux type=3D"integer">161</qux>
</pdutastic>

so when i (expecting the new version) consume the old version, i do not see= qux. but my parser doesn't complain because instead of the DTD of the = new PDU, i see a reference to the old PDU and say to myself... "it'= ;s okay... it's just an older version," and i do whatever i have t= o do to continue processing in the absence of the qux member i was expectin= g. even if i'm doing validation, it's okay, i'm pulling the DTD= from the old definition, so we're cool.

now... when cathy consumes the new PDU, something similar happens. she see&= #39;s a DTD she's not familiar with, but it's all good.. she grabs = teh DTD from URL specified in teh DOCTYPE and moves on with her life, hopin= g that new version PDU didn't change the semantics of the three values = (foo, bar and baz) she's familiar with.

and then one day she receives this from david:

<?xml version=3D"1.0"?>
<!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined Derivatives ML = PDU 1.2//EN" "http://example.com/pdu/1.2/pdutastic.dtd"><= br> <pdutastic>
=A0<foo type=3D"integer">13</foo>
=A0<bar type=3D"date">2008-12-15T13:17:23.235Z</bar>=
=A0<baz type=3D"integer">93</baz>
=A0<qux type=3D"integer">161</qux>
</pdutastic>

aha! david, trying to steal my core demographic away from me has upgraded t= o the most recent beta version of the software (now with 13% more explosion= s)

but this is now a serious problem for cathy. the "shape" of the s= tructured data now does not match. what does she do? how does she convert t= hat date into an integer?

and this is the question we keep running into as we deploy "loosely co= upled" systems. how do we fail gracefully and ensure robustness in the= presence of PDU schema mismatches?

the way linden answered this question was to develop LLSD, an abstract type= system with conversions and defaults.

the way we would probably have defined the message above would have been so= mething like:

<?xml version=3D"1.0"?>
<llsd>
=A0<map>
=A0 =A0<key>foo</key>
=A0 =A0<integer>13</integer>
=A0 =A0<key>bar</key>
=A0 =A0<date>2008-12-15T13:17:23.235Z</date>
=A0 =A0<key>baz</key>
=A0 =A0<integer>93</integer>
=A0 =A0<key>qux</key>
=A0 =A0<integer>161</integer>
=A0</map>
</llsd>

we don't include the doctype id 'cause our DTD never changes. in th= is example the LLSD message is shorter 'cause we don't include the = DOCTYPE id, but even after removing the DOCTYPE id and changing the outer e= lement to llsd, the compressed version of the LLSD message is only seven by= tes larger. (an increase from 154 bytes to 161 bytes, an efficiency loss of= 4.5%) however, i can guarantee you that it took a lot less time to code th= e parser because.. well.. we already had =A0a parser that knew how to unwra= p LLSD messages.

but we haven't got to the interesting part yet.

there is a processing expectation with LLSD. we assume we're de-seriali= zing a message into a dynamic language like ECMAScript or Python. For langu= ages like C++ and Java we create a class that emulates this feature. so.. a= ll LLSD PDUs are de-serialized into these LLSD objects, and inside our appl= ication(s), it's these objects that get passed around. so we might have= code that looks like:

public foo ( string message ) {
=A0 =A0 =A0 =A0LLSD llsd;

=A0 =A0 =A0 =A0llsd =3D LLSD.From( message, LLSD.XML_SERIALIZATION );

=A0 =A0 =A0 =A0System.err.println( "hey! foo was %d.\n", (int) <= a href=3D"http://llsd.at" target=3D"_blank">llsd.at( "foo" ).= asInteger() );

=A0 =A0 =A0 =A0if( ( (int) ll= sd.at("bar").asInteger() > 100 ) || ( (int) llsd.at("bar").asInteger() <= ; 0 ) ) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0System.err.println( "bar is not a perc= entage\n" );
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0System.haltAndCatchFire();
=A0 =A0 =A0 =A0}


=A0 =A0 =A0 =A0if( (int) llsd= .at("bar").asInteger() < 40 ) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0System.err.println( "sorry, this perce= nt margin is way too small for me to be interested.\n" );
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0System.haltAndCatchFire();
=A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0.
}

forgive the javaisms, the alternative was smalltalk and well... let's n= ot go there.

for the sake of argument let's say we had already determined it was in = XML format by looking at the Content-Type: header from the request.

so what we're doing here is not out of the ordinary... we create an ins= tance of the LLSD class from the serialization.

and we print some logging messages.

and we then try to see if bar is between 0 an 100.

but the object representing "foo" is a date, not an integer. what= happens?

in our current implementation of LLSD, we attempt to convert, but notice th= at the conversion from date to integer has no semantic meaning. =A0because = the conversion is "illegal," the default value is returned.

the result of running this fragment would be something like

=A0 =A0 =A0 =A0hey! foo was 0.
=A0 =A0 =A0 =A0sorry, this percent margin is way too small for me to be in= terested.

the important feature here is that we did not allow the "presentation = layer" to create an error. we did the best we could to interpret the s= ense of the message, even to the point of making a nonsensical conversion. = we allow this to happen because we assume that at the application layer, we= 're going to do parameter checking. so the reasoning was... if we'r= e going to be doing parameter checking anyway, why would we want to allow t= he presentation layer to fail a message that would have generated a result = that could be checked at the application layer?

i hope you've enjoyed this installment of "the structure and inter= pretation of LLSD messages." and i hope it helps explain our motivatio= ns for designing LLSD and it's serializations the way we did... and whi= le we have a metric tonne of code that uses the existing LLSD DTD, ultimate= ly, any additional serialization format that preserves these processing exp= ectations could be wedged into the system. serialization formats that did n= ot support these processing expectations would cause considerable heart bur= n.

-cheers
-meadhbh

On Feb 24, 2009, at 6:12 PM, Jon Watte wrote:

Catherine Pfeffer wrote:
That's precisely all the HUGE strength of LLSD. Having information abou= t what the data is intermingled with the data itself makes it very flexible= and future-proof.
But that is simply not necessary. If you transmit a reference to the schema= you use when you initiate connection, then all future transmissions during= that connection session can use the knowledge of that schema to highly opt= imize traffic. Network traffic is actually one of the scarce resources when= you start scaling up really large virtual worlds. There are cases where an= entire office (20 people or more) share a single T1 connection to the Inte= rnet, and expect to have a good virtual world experience for multiple users= at the same time.


Honestly, here, the bandwidth is not lost, compared to the advantages.


I think it is, because the size difference is quite significant.

In summary, their binary serialization is as flexible as XML data. Perhaps = I'm wrong, but to me it's an unique case in all computer science of= a binary format that would be so flexible.

Don't overextend yourself :-) AIFF/RIFF has pretty much the same flexib= ility, as does TLV (also used in OSCAR), a number of "binary XML"= proposals, and a number of protocols that have all done more or less the s= ame thing ever since computers were interconnected on a larger scale in the= '80s.

Sincerely,

jw

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--001636c5a444fc2b8a0463b8955f-- From infinity@lindenlab.com Tue Feb 24 22:45:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A074328C133 for ; Tue, 24 Feb 2009 22:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFqlRECfE2p4 for ; Tue, 24 Feb 2009 22:45:48 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 4BE6428C135 for ; Tue, 24 Feb 2009 22:45:48 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 11F053DBC44B; Tue, 24 Feb 2009 22:46:08 -0800 (PST) Message-Id: <52815265-FCB5-486B-985F-1A7867D124F5@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Dan Olivares In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 22:46:06 -0800 References: <1E712A17-6D23-471C-A827-CD86C1EDE59D@lindenlab.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Representing Number Types [Was: Re: Details proposal] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 06:45:51 -0000 okay. you've sold me! i propose we don't do this again and i will seek out and pelt with rotten vegetables the linden developer who wants to perpetuate **** like this. * there are very good reasons why parcel flags should be an array or map of booleans. not the least of which is you can do something like this in the code: if( parcelFlags.at("allow_fly").asBoolean() ) { System.out.println( "you may now fly about the parcel.\n"); } * we're thinking that auctions should be represented by URIs in the future. * we're also thinking about eliminating 64 bit ints from the protocol. in most places where the 64 bit ints were used, UUIDs were more appropriate. * IP addresses? krikey! how 'bout URIs! * timestamps? we have a date type, let's use it! * and a bitmap? if it was any larger i would recommend we reference the URI where the peer could find the resource (which is nice, cause we also get the mime type) but... i'm not trying to give flip answers here, only to say: * yes. our protocol is "sub optimal." irrespective of what happens here, we're changing it to be more optimal. * if we can honestly say we've come to the point where our biggest concern is 64-bit ints, and not stuff like what you pulled out of the bag of pain below, i will be very, very happy -cheers -meadhbh On Feb 24, 2009, at 9:04 PM, Dan Olivares wrote: > To understand why there would be a request for this, you also have to > understand some of the issues that people have delt with when working > with LLSD. > > Take boolean values encoded uints for instance. Often times in the > current use of LLSD, uints are used to transfer several bit values > encoded into a 32 bit unsigned integer. Additionally, there's > currently no way to represent an unsigned integer in LLSD. This means > that you must represent it as a base64 encoded byte array and often > results in ugly, non human readable XML Serializations, for example, > in parcels; > ParcelFlagsfiAESw== > > Then, you also have a single uint value that represents the ID of the > auction associated with the parcel that is also encoded as a base64 > encoded object. This is not a group of encoded boolean values, this > is a single value. > AuctionIDAAAAAA== > > Then, you have 64 bit unsigned integers (aka, bignums) that are > represented with base64 encoded binary; > HandleAAIkAAAEJAA= > > Then, you have IP addresses that are represented with base64 encoded > binary; > IP2FIQPA== > > Then, you have Timestamps that are represented with base64 encoded > binary; > TimeStampSLs0lw== > > Then, you have bitmap data, that is also represented with base64 > encoded binary; > Bitmap encoding="base64">AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwD8AAAAAAADAPwAAAAAAAMA/AAAAAAAAwD8AAAAAAADAPwAAAAAAAMA/AAAAAAAAwD8AAAAAAADAPwAAAAAAAMA/AAAAAAAAwD8AAAAAAADAPwAAAAAAAOA/AAAAAAAA4D8AAAAAAADgPwAAAAAAAAAAAAAAAAAAAAA= > > Do you see how ambiguous the "binary" type is?. In my opinion, the > only valid use of it in an XML encoding listed above, is the bitmap. > XML encodings are /meant/ to be as human readable as possible. > > Then, you have boolean values that are represented as integers; > MediaAutoScale1 > > Then, in addition to having timestamp values represented in the binary > encoding, you also have unix time since epoch values represented as a > 'real' > start_time1232962915.3859558 > > In terms of a 'parcel' on LLGrid (which is a cut unit of land where > you can define specific settings as well as sell, purchase, ban, etc), > the settings of the parcel are represented by a set of boolean values. > These boolean values are encoded into a 32 bit unsigned integer > called "ParcelFlags". (A few of of the 32 acceptable boolean values > are: AllowDamage AllowAPrimitiveEntry AllowDeedToGroup AllowFly > CreateObjects ForSale AllowGroupScripts). > over LLSD, this looks like; > ParcelFlagsfiAESw==. > > However, if that wasn't complicated and unreadable enough.. It > turns out that all unsigned integer values are also represented /big > endian/ and integers are represented /little endian/. Therefore, to > be able to actually use those values, you have to; > > 1. Know the agreed upon encoding, (which bits refer to which boolean > flags) > 2. You must convert it from the non human readable "fiAESw==" into an > array of bytes > 3. You must convert it to your system's 'endian-ness' > 4. You must use bitwise operations to decode the flags. > > There are a plethora of types of values that use this human > non-readable boolean value encoding on things ranging from region > settings, to object data, to permissions. They're all over the place. > > So, that's the issue that I'm trying to solve when I ask for more > datatypes and more specific data types. There's also use consistancy > issues and mentioned above and key naming consistency issues in > existing uses of LLSD. Something can be named 'AgentID' in one CAP > name/value key, and named 'agent_id' in another. > > Best Regards > > Daniel Olivares > > > > > On Tue, Feb 24, 2009 at 10:49 PM, Meadhbh Hamrick (Infinity) > wrote: >> about sizes of ints as attributes. >> >> let me pose the question... what is the difference in terms of >> processing >> expectations if one sends >> >> '12' >> >> vs. sending >> >> '12' ? >> >> do we want to be in the business of mandating that the receiver >> actually >> check to see if the value is representable with the number of bits >> given, or >> do we just want to store the value somewhere? >> >> and what about '12' ? and what about >> "> size="4096">12"? >> >> if we allow that last fragment, and we require receivers to honor >> the size, >> then implementers MUST use arbitrary lengthed integers (i.e. bignum >> packages.) and it's hard to say things like "we're concerned about >> the >> efficiency of the XML parsing" while you're also saying "yeah... >> all ints >> should be bignums." >> >> but if we say something like.. "all right, we'll just limit the >> size to >> being a max of 128 bits," then we're effectively doing the same thing >> because not all languages that people would want to use (like >> python and >> PHP) support even native 64 bit ints. >> >> so unless we say that ints are at most 32 bits, then our python and >> PHP LLSD >> implementations will REQUIRE the use of bignums. >> >> so let me now pose another the question... >> >> what would happen if we just remove the bit width of number types >> from the >> proposal all together? would that kill anyone? >> >> it would, i believe, mandate an error condition be signaled should >> the >> remote peer send an encoding of an integer that you can't >> represent. or >> maybe you just do some magic behind the scenes and dynamically >> convert to a >> bignum if you're language supports it. >> >> or maybe we just drop that value on the floor? we say... "if you >> pass some >> pre-defined limit, you get the default value" >> >> this might be doable if everyone understood that when you're >> connecting to >> second life, we have so much python and PHP we're gonna freak if >> you start >> using 64 bit ints and double double floats, but when you connect to >> OSGrid, >> 64 bit ints are fine. >> >> or you could do some sort of negotiation up front asking the peer, >> "what's >> your preferred and maximum integer and float size?" >> >> it is unfortunate that all of these options are sub-optimal, but >> that's what >> it looks like to me. >> >> about signedness >> >> assuming we can all find agreement that the machines we're using >> all use 2's >> complement notation, the main difference between signed and >> unsigned seems >> to be behavior when a right shift operation occurs. >> >> couldn't we just say that when an endpoint needs a value to be a >> signed >> value, it stores it in a signed integral container and when it >> needs it to >> be an unsigned value, it stores it in an unsigned integral container? >> >> On Feb 24, 2009, at 5:43 PM, Catherine Pfeffer wrote: >> >>> Hi all, >>> >>> Infinity asked me to write down proposals to make LLSD a bit better. >>> >>> Honestly, I don't think it is really the way to go. I think the >>> previous >>> message has shown how much the current XML serialization is >>> unsatisfying, >>> due to the 1:1 paradigm. >>> >>> But I have promised to do such a proposal, so here we go: >>> 1 - change the name from LLSD to VWSD >>> 2 - add provision for different sizes for integers and floats. In >>> XML that >>> could mean an extra size="" attribute with a default to 32 bits so >>> it needs >>> not be specified in the majority of cases, in binary serialization >>> that >>> would mean new data codes >>> 3 - add provision for unsigned data. In XML that would mean an extra >>> signed="" attribute with a default to "yes" so it needs not be >>> specified in >>> the majority of cases, in the binary serialization that calls for >>> more data >>> codes too >>> 4 - allow some shortcuts for an array of three reals and >>> an array >>> of 4 reals >>> 5 - embed map entries into ... tags >>> >>> That's almost the same points as the ones that Jon has listed. >>> >>> But again, to do it in a real XML-ish way, the data types like >>> >>> should move to the DTD. I don't see any justification for them in >>> an XML >>> file. >>> >>> -- >>> Cathy >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> From infinity@lindenlab.com Tue Feb 24 23:06:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F323A6B55 for ; Tue, 24 Feb 2009 23:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnR-tGEFGy+q for ; Tue, 24 Feb 2009 23:06:20 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 9AE2D3A6B51 for ; Tue, 24 Feb 2009 23:06:20 -0800 (PST) Received: from infinity.vpn.lindenlab.com (infinity.vpn.lindenlab.com [10.0.254.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id A89AF3DBC44B; Tue, 24 Feb 2009 23:06:39 -0800 (PST) Message-Id: <497C7FD9-BF36-458F-98C0-BEECAE611E1A@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Morgaine In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-18--459639796 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 24 Feb 2009 23:06:37 -0800 References: <49A4A8FA.607@gmail.com> <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] The Structure and Interpretation of LLSD Messages [Was: Re: unefficient binary serialization ?] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 07:06:23 -0000 --Apple-Mail-18--459639796 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit i looked at Google PB when i was writing mobile phone software and went back to using DBUS. but honestly... that was a radically different problem space. GooglePB's kinda sorta fall down in the way i believe that representing PDUs with message specific DTDs / Schemas fall down. you have to define a message specific .proto file and run it through the protocol buffer compiler that makes the stub. i'm a bit of a CORBA fan, so this doesn't scare me. the part that scares me is that you have to use integers for unique names. this is important thusly... imagine you have a .proto file like: message Person { required string name = 1; required int32 id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; } repeated PhoneNumber phone = 4; } and the next rev of the protocol is: message Person { required string name = 1; required int32 id = 2; optional string email = 3; enum PhoneType { MOBILE = 0; HOME = 1; WORK = 2; } enum PhoneUsage { VOICE = 0; FAX = 1; MODEM = 2; } message PhoneNumber { required string number = 1; optional PhoneType type = 2 [default = HOME]; optional PhoneUsage type = 3 [default = VOICE]; } repeated PhoneNumber phone = 4; } the problem is that if a endpoint expecting the former consumes the latter, the serialization engine barfs. and you (in the application layer) don't receive the message in order to try to pick it apart manually (which kind of defeats the purpose of the serialization.) however, it _is_ an open source project, so we could probably create a version of the library that adds a "fail silently" mode. there are also semantics for extending messages, so maybe.. i'd have to look at it a little more before passing judgement. On Feb 24, 2009, at 10:45 PM, Morgaine wrote: > Excellent background on LLSD, Infinity! It raises a question: > > On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) > wrote: > > while we have a metric tonne of code that uses the existing LLSD > DTD, ultimately, any additional serialization format that preserves > these processing expectations could be wedged into the system. > serialization formats that did not support these processing > expectations would cause considerable heart burn. > > > One serialization format that many have mentioned here is Google's > Protocol Buffers. While I have barely started to examine PB myself, > it is very clear that this serialization is extraordinarily > efficient on-the-wire and also at both ends of the wire, as well as > catering for the continual change that is inherent in large, > evolving systems. A interest in extending the 3-way serialization > of XXSD to Protocol Buffers follows naturally. > > The question that is raised by the quoted paragraph is whether > Protocol Buffers "preserves these processing expectations". If it > does then extending the set of serializations to PB is work that > could be done by those interested in it, as an open project, and > picked up by other users of XXSD if they wish. Potentially, the > acceleration could be quite significant, and hence the benefit to > Limited Capability Clients very important. > > On the other hand, if it does not "preserve these processing > expectations" then there could be a problem. > > Do Lindens (or anyone else here) have any insight on this? > > Morgaine. > > > > > > > > On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) > wrote: > but here's one reason we like LLSD... > > imagine you have two systems that are interoperating... one is owned > my me, the other is owned by catherine. > > cathy's customers are all banks and insurance companies and are very > conservative, so cathy want's to err on the side of caution in terms > of when she deploys new features. > > i on the other hand throw caution to the wind because my customers > are all first person shooter fanatics between the ages of 13 and 21 > who demand the latest features as soon as possible (otherwise they > use david's server) > > it's not hard to see we're eventually going to introduce version > slew which will make it difficult for cathy and i to participate in > the unregulated business of marketing virtual life insurance > policies to my customers. in this example, i'm trying to point out > that the both the option to retain version parity with cathy and the > option to upgrade to the latest version are not without drawbacks. > > now.. imagine we have a PDU with three members while the second > version adds a member. for simplicity's sake, let's say they're all > integers. > > if used the DTD to define the validation for the message, the first > version of the message might look like: > > > PDU 1.0//EN" "http://example.com/pdu/1.0/pdutastic.dtd"> > > 13 > 42 > 93 > > > while the new version would look like this: > > > PDU 1.1//EN" "http://example.com/pdu/1.1/pdutastic.dtd"> > > 13 > 42 > 93 > 161 > > > so when i (expecting the new version) consume the old version, i do > not see qux. but my parser doesn't complain because instead of the > DTD of the new PDU, i see a reference to the old PDU and say to > myself... "it's okay... it's just an older version," and i do > whatever i have to do to continue processing in the absence of the > qux member i was expecting. even if i'm doing validation, it's okay, > i'm pulling the DTD from the old definition, so we're cool. > > now... when cathy consumes the new PDU, something similar happens. > she see's a DTD she's not familiar with, but it's all good.. she > grabs teh DTD from URL specified in teh DOCTYPE and moves on with > her life, hoping that new version PDU didn't change the semantics of > the three values (foo, bar and baz) she's familiar with. > > and then one day she receives this from david: > > > PDU 1.2//EN" "http://example.com/pdu/1.2/pdutastic.dtd"> > > 13 > 2008-12-15T13:17:23.235Z > 93 > 161 > > > aha! david, trying to steal my core demographic away from me has > upgraded to the most recent beta version of the software (now with > 13% more explosions) > > but this is now a serious problem for cathy. the "shape" of the > structured data now does not match. what does she do? how does she > convert that date into an integer? > > and this is the question we keep running into as we deploy "loosely > coupled" systems. how do we fail gracefully and ensure robustness in > the presence of PDU schema mismatches? > > the way linden answered this question was to develop LLSD, an > abstract type system with conversions and defaults. > > the way we would probably have defined the message above would have > been something like: > > > > > foo > 13 > bar > 2008-12-15T13:17:23.235Z > baz > 93 > qux > 161 > > > > we don't include the doctype id 'cause our DTD never changes. in > this example the LLSD message is shorter 'cause we don't include the > DOCTYPE id, but even after removing the DOCTYPE id and changing the > outer element to llsd, the compressed version of the LLSD message is > only seven bytes larger. (an increase from 154 bytes to 161 bytes, > an efficiency loss of 4.5%) however, i can guarantee you that it > took a lot less time to code the parser because.. well.. we already > had a parser that knew how to unwrap LLSD messages. > > but we haven't got to the interesting part yet. > > there is a processing expectation with LLSD. we assume we're de- > serializing a message into a dynamic language like ECMAScript or > Python. For languages like C++ and Java we create a class that > emulates this feature. so.. all LLSD PDUs are de-serialized into > these LLSD objects, and inside our application(s), it's these > objects that get passed around. so we might have code that looks like: > > public foo ( string message ) { > LLSD llsd; > > llsd = LLSD.From( message, LLSD.XML_SERIALIZATION ); > > System.err.println( "hey! foo was %d.\n", (int) > llsd.at( "foo" ).asInteger() ); > > if( ( (int) llsd.at("bar").asInteger() > 100 ) || ( (int) > llsd.at("bar").asInteger() < 0 ) ) { > System.err.println( "bar is not a percentage\n" ); > System.haltAndCatchFire(); > } > > > if( (int) llsd.at("bar").asInteger() < 40 ) { > System.err.println( "sorry, this percent margin is > way too small for me to be interested.\n" ); > System.haltAndCatchFire(); > } > . > . > . > } > > forgive the javaisms, the alternative was smalltalk and well... > let's not go there. > > for the sake of argument let's say we had already determined it was > in XML format by looking at the Content-Type: header from the request. > > so what we're doing here is not out of the ordinary... we create an > instance of the LLSD class from the serialization. > > and we print some logging messages. > > and we then try to see if bar is between 0 an 100. > > but the object representing "foo" is a date, not an integer. what > happens? > > in our current implementation of LLSD, we attempt to convert, but > notice that the conversion from date to integer has no semantic > meaning. because the conversion is "illegal," the default value is > returned. > > the result of running this fragment would be something like > > hey! foo was 0. > sorry, this percent margin is way too small for me to be > interested. > > the important feature here is that we did not allow the > "presentation layer" to create an error. we did the best we could to > interpret the sense of the message, even to the point of making a > nonsensical conversion. we allow this to happen because we assume > that at the application layer, we're going to do parameter checking. > so the reasoning was... if we're going to be doing parameter > checking anyway, why would we want to allow the presentation layer > to fail a message that would have generated a result that could be > checked at the application layer? > > i hope you've enjoyed this installment of "the structure and > interpretation of LLSD messages." and i hope it helps explain our > motivations for designing LLSD and it's serializations the way we > did... and while we have a metric tonne of code that uses the > existing LLSD DTD, ultimately, any additional serialization format > that preserves these processing expectations could be wedged into > the system. serialization formats that did not support these > processing expectations would cause considerable heart burn. > > -cheers > -meadhbh > > On Feb 24, 2009, at 6:12 PM, Jon Watte wrote: > > Catherine Pfeffer wrote: > That's precisely all the HUGE strength of LLSD. Having information > about what the data is intermingled with the data itself makes it > very flexible and future-proof. > But that is simply not necessary. If you transmit a reference to the > schema you use when you initiate connection, then all future > transmissions during that connection session can use the knowledge > of that schema to highly optimize traffic. Network traffic is > actually one of the scarce resources when you start scaling up > really large virtual worlds. There are cases where an entire office > (20 people or more) share a single T1 connection to the Internet, > and expect to have a good virtual world experience for multiple > users at the same time. > > > Honestly, here, the bandwidth is not lost, compared to the advantages. > > > I think it is, because the size difference is quite significant. > > In summary, their binary serialization is as flexible as XML data. > Perhaps I'm wrong, but to me it's an unique case in all computer > science of a binary format that would be so flexible. > > Don't overextend yourself :-) AIFF/RIFF has pretty much the same > flexibility, as does TLV (also used in OSCAR), a number of "binary > XML" proposals, and a number of protocols that have all done more or > less the same thing ever since computers were interconnected on a > larger scale in the '80s. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --Apple-Mail-18--459639796 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable i = looked at Google PB when i was writing mobile phone software and went = back to using DBUS.

but = honestly... that was a radically different problem = space.

GooglePB's kinda sorta fall down in the way i believe that = representing PDUs with message specific DTDs / Schemas fall down. you = have to define a message specific .proto file and run it through the = protocol buffer compiler that makes the stub. i'm a bit of a CORBA fan, = so this doesn't scare me. the part that scares me is that you have to = use integers for unique names. this is important = thusly...

imagine you have a .proto file = like:
message Person =
{
  required string name =3D 1;
  required int32 id =3D 2;
  optional string email =3D 3;

  enum PhoneType {
    MOBILE =3D 0;
    HOME =3D 1;
    WORK =3D 2;
  }

  message PhoneNumber {
    required string number =3D 1;
    optional PhoneType type =3D 2 [default =3D HOME];
  }

  repeated PhoneNumber phone =3D 4;
}
and the next rev of the protocol =
is:
message Person =
{
  required string name =3D 1;
  required int32 id =3D 2;
  optional string email =3D 3;

  enum PhoneType {
    MOBILE =3D 0;
    HOME =3D 1;
    WORK =3D 2;
  }

  enum =
PhoneUsage {
    VOICE =3D 0;
    FAX =3D =
1;
    MODEM =3D 2;
  }
  message PhoneNumber {
    required string number =3D 1;
    optional PhoneType type =3D 2 [default =3D =
HOME];
    optional PhoneUsage type =3D 3 =
[default =3D VOICE];
  }

  repeated PhoneNumber phone =3D 4;
}

the = problem is that if a endpoint expecting the former consumes the latter, = the serialization engine barfs. and you (in the application layer) don't = receive the message in order to try to pick it apart manually (which = kind of defeats the purpose of the = serialization.)

however, it _is_ an open source project, so we could = probably create a version of the library that adds a "fail silently" = mode.

there are also semantics for extending messages, so = maybe.. i'd have to look at it a little more before passing = judgement.


On Feb 24, 2009, at 10:45 PM, = Morgaine wrote:

Excellent background on LLSD, Infinity!  It raises a = question:

On Wed, Feb = 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) <infinity@lindenlab.com> = wrote:

while we have = a metric tonne of code that uses the existing LLSD DTD, ultimately, any = additional serialization format that preserves these processing = expectations could be wedged into the system. serialization formats that = did not support these processing expectations would cause considerable = heart burn.
 

One serialization format that many have mentioned = here is Google's Protocol Buffers.  While I have barely started to = examine PB myself, it is very clear that this serialization is = extraordinarily efficient on-the-wire and also at both ends of the wire, = as well as catering for the continual change that is inherent in large, = evolving systems.  A interest in extending the 3-way serialization = of XXSD to Protocol Buffers follows naturally.
=
The question that is raised by the quoted = paragraph is whether Protocol Buffers "preserves these processing = expectations".  If it does then extending the set of serializations = to PB is work that could be done by those interested in it, as an open = project, and picked up by other users of XXSD if they wish.  = Potentially, the acceleration could be quite significant, and hence the = benefit to Limited Capability Clients very important.

On the other hand, if it does not = "preserve these processing expectations" then there could be a = problem.

Do Lindens = (or anyone else here) have any insight on this?

Morgaine.







On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick = (Infinity) <infinity@lindenlab.com> wrote:
= but here's one reason we like LLSD...

imagine you have two systems that are = interoperating... one is owned my me, the other is owned by = catherine.

cathy's = customers are all banks and insurance companies and are very = conservative, so cathy want's to err on the side of caution in terms of = when she deploys new features.

i on the other hand throw caution to the wind because my = customers are all first person shooter fanatics between the ages of 13 = and 21 who demand the latest features as soon as possible (otherwise = they use david's server)

it's not hard to see we're eventually going to introduce = version slew which will make it difficult for cathy and i to participate = in the unregulated business of marketing virtual life insurance policies = to my customers. in this example, i'm trying to point out that the both = the option to retain version parity with cathy and the option to upgrade = to the latest version are not without drawbacks.
=
now.. imagine we have a PDU with three = members while the second version adds a member. for simplicity's sake, = let's say they're all integers.

if used the DTD to define the validation for the message, = the first version of the message might look like:

<?xml version=3D"1.0"?>
<!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly = Defined Derivatives ML PDU 1.0//EN" = "http://example.com/pdu/1.0/pdutastic.dtd">
= <pdutastic>
 <foo = type=3D"integer">13</foo>
 <bar = type=3D"integer">42</bar>
 <baz = type=3D"integer">93</baz>
= </pdutastic>

= while the new version would look like this:
=
<?xml version=3D"1.0"?>
<!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined = Derivatives ML PDU 1.1//EN" = "http://example.com/pdu/1.1/pdutastic.dtd">
= <pdutastic>
 <foo = type=3D"integer">13</foo>
 <bar = type=3D"integer">42</bar>
 <baz = type=3D"integer">93</baz>
 <qux = type=3D"integer">161</qux>
= </pdutastic>

so = when i (expecting the new version) consume the old version, i do not see = qux. but my parser doesn't complain because instead of the DTD of the = new PDU, i see a reference to the old PDU and say to myself... "it's = okay... it's just an older version," and i do whatever i have to do to = continue processing in the absence of the qux member i was expecting. = even if i'm doing validation, it's okay, i'm pulling the DTD from the = old definition, so we're cool.

now... when cathy consumes the new PDU, something similar = happens. she see's a DTD she's not familiar with, but it's all good.. = she grabs teh DTD from URL specified in teh DOCTYPE and moves on with = her life, hoping that new version PDU didn't change the semantics of the = three values (foo, bar and baz) she's familiar with.

and then one day she receives = this from david:

= <?xml version=3D"1.0"?>
<!DOCTYPE = pdutastic PUBLIC "-//MMOX//Poorly Defined Derivatives ML PDU 1.2//EN" = "http://example.com/pdu/1.2/pdutastic.dtd">
= <pdutastic>
 <foo = type=3D"integer">13</foo>
 <bar = type=3D"date">2008-12-15T13:17:23.235Z</bar>
=  <baz type=3D"integer">93</baz>
=  <qux type=3D"integer">161</qux>
= </pdutastic>

= aha! david, trying to steal my core demographic away from me has = upgraded to the most recent beta version of the software (now with 13% = more explosions)

= but this is now a serious problem for cathy. the "shape" of the = structured data now does not match. what does she do? how does she = convert that date into an integer?

and this is the question we keep running into as = we deploy "loosely coupled" systems. how do we fail gracefully and = ensure robustness in the presence of PDU schema mismatches?

the way linden answered this = question was to develop LLSD, an abstract type system with conversions = and defaults.

the = way we would probably have defined the message above would have been = something like:

= <?xml version=3D"1.0"?>
<llsd>
 <map>
  =  <key>foo</key>
  =  <integer>13</integer>
  =  <key>bar</key>
  =  <date>2008-12-15T13:17:23.235Z</date>
   <key>baz</key>
=    <integer>93</integer>
=    <key>qux</key>
  =  <integer>161</integer>
=  </map>
</llsd>

we don't include the doctype id = 'cause our DTD never changes. in this example the LLSD message is = shorter 'cause we don't include the DOCTYPE id, but even after removing = the DOCTYPE id and changing the outer element to llsd, the compressed = version of the LLSD message is only seven bytes larger. (an increase = from 154 bytes to 161 bytes, an efficiency loss of 4.5%) however, i can = guarantee you that it took a lot less time to code the parser because.. = well.. we already had  a parser that knew how to unwrap LLSD = messages.

but we = haven't got to the interesting part yet.

there is a processing expectation with LLSD. we = assume we're de-serializing a message into a dynamic language like = ECMAScript or Python. For languages like C++ and Java we create a class = that emulates this feature. so.. all LLSD PDUs are de-serialized into = these LLSD objects, and inside our application(s), it's these objects = that get passed around. so we might have code that looks like:

public foo ( string = message ) {
       LLSD = llsd;

    =    llsd =3D LLSD.From( message, LLSD.XML_SERIALIZATION );

      =  System.err.println( "hey! foo was %d.\n", (int) llsd.at( "foo" = ).asInteger() );

=        if( ( (int) llsd.at("bar").asInteger() > 100 = ) || ( (int) llsd.at("bar").asInteger() < 0 ) ) {
              =  System.err.println( "bar is not a percentage\n" );
              =  System.haltAndCatchFire();
    =    }


       if( (int) = llsd.at("bar").asInteger() < 40 ) {
  =              System.err.println( = "sorry, this percent margin is way too small for me to be interested.\n" = );
            =    System.haltAndCatchFire();
  =      }
      =          .
  =              .
               .
}

forgive the javaisms, the alternative was smalltalk and = well... let's not go there.

for the sake of argument let's say we had already determined = it was in XML format by looking at the Content-Type: header from the = request.

so what = we're doing here is not out of the ordinary... we create an instance of = the LLSD class from the serialization.

and we print some logging messages.

and we then try to see if bar is = between 0 an 100.

= but the object representing "foo" is a date, not an integer. what = happens?

in our = current implementation of LLSD, we attempt to convert, but notice that = the conversion from date to integer has no semantic meaning. =  because the conversion is "illegal," the default value is = returned.

the = result of running this fragment would be something like

       hey! = foo was 0.
       sorry, = this percent margin is way too small for me to be interested.

the important feature = here is that we did not allow the "presentation layer" to create an = error. we did the best we could to interpret the sense of the message, = even to the point of making a nonsensical conversion. we allow this to = happen because we assume that at the application layer, we're going to = do parameter checking. so the reasoning was... if we're going to be = doing parameter checking anyway, why would we want to allow the = presentation layer to fail a message that would have generated a result = that could be checked at the application layer?
=
i hope you've enjoyed this installment of = "the structure and interpretation of LLSD messages." and i hope it helps = explain our motivations for designing LLSD and it's serializations the = way we did... and while we have a metric tonne of code that uses the = existing LLSD DTD, ultimately, any additional serialization format that = preserves these processing expectations could be wedged into the system. = serialization formats that did not support these processing expectations = would cause considerable heart burn.

-cheers
-meadhbh

On Feb 24, 2009, at = 6:12 PM, Jon Watte wrote:

Catherine Pfeffer wrote:
That's = precisely all the HUGE strength of LLSD. Having information about what = the data is intermingled with the data itself makes it very flexible and = future-proof.
But that is simply not = necessary. If you transmit a reference to the schema you use when you = initiate connection, then all future transmissions during that = connection session can use the knowledge of that schema to highly = optimize traffic. Network traffic is actually one of the scarce = resources when you start scaling up really large virtual worlds. There = are cases where an entire office (20 people or more) share a single T1 = connection to the Internet, and expect to have a good virtual world = experience for multiple users at the same time.
=

Honestly, here, = the bandwidth is not lost, compared to the advantages.


I = think it is, because the size difference is quite significant.

In summary, their = binary serialization is as flexible as XML data. Perhaps I'm wrong, but = to me it's an unique case in all computer science of a binary format = that would be so flexible.

Don't overextend yourself :-) AIFF/RIFF has pretty much the = same flexibility, as does TLV (also used in OSCAR), a number of "binary = XML" proposals, and a number of protocols that have all done more or = less the same thing ever since computers were interconnected on a larger = scale in the '80s.

= Sincerely,

jw

= _______________________________________________
= mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox

= _______________________________________________
= mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox


= --Apple-Mail-18--459639796-- From morgaine.dinova@googlemail.com Tue Feb 24 23:18:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB553A6B5C for ; Tue, 24 Feb 2009 23:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgwUTpmmtLFz for ; Tue, 24 Feb 2009 23:18:11 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id C364F3A686C for ; Tue, 24 Feb 2009 23:18:10 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so1916788fkf.5 for ; Tue, 24 Feb 2009 23:18:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=W/TIC0EH59Fh05HgGfLKzQ9g1StwZvtOKGf99PqpGGI=; b=RCyRvGbuFM+Dzdt3HKwE7rwXVpLYBCY1x/V+87/aSi8XnIs5uKXks6uUuTzKuOo/M7 jnnubn5dzT7DBq4+1hktvmVnAKAbs+K0Cm518YHPuEyeV6l455GOE1fUQoRnwtijOC6X afHeSsTbpITIUsNB1HLm1mbUMXvN5ckpkm9ek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Y/quDlM0FdYojhm5E//aZoqDxlgoTbKuDHIF59yjfE6q8yecxC3+SxCKFHNoUdWvcg zg3CCe6rJNF6hesSIChKBlIC0SArripW/MgdKhgrB7TdBRB5UAWIFDVcyK0VG8KuQ1W0 VEFvvn9E5yoPRmjwMZquBqaRWHrfeDh1cpKF4= MIME-Version: 1.0 Received: by 10.180.231.17 with SMTP id d17mr223689bkh.37.1235546309232; Tue, 24 Feb 2009 23:18:29 -0800 (PST) In-Reply-To: <61dbdd7d0902232240v7be93f0dpd6310ecd7db0902a@mail.gmail.com> References: <27a487810902231225l6698b519rdc6f1d53ba215024@mail.gmail.com> <61dbdd7d0902232240v7be93f0dpd6310ecd7db0902a@mail.gmail.com> Date: Wed, 25 Feb 2009 07:18:29 +0000 Message-ID: From: Morgaine To: Gareth Nelson Content-Type: multipart/alternative; boundary=0016368e29ebdd87c40463b90a4d Cc: mmox@ietf.org, William George Subject: Re: [mmox] Permissions (Gareth Nelson) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 07:18:12 -0000 --0016368e29ebdd87c40463b90a4d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Gareth, although you've withdrawn your proposal, it addresses interesting issues so I'd like to make a brief comment on your last point: On Tue, Feb 24, 2009 at 6:40 AM, Gareth Nelson wrote: > Essentially, you'd need to look at each sub-component and then > evaluate what the restrictions are, applying the restrictions on > sub-components to the collected whole (since they're part of the > whole). While such examination is just about feasible at interop time in SL's non-hierarchical scheme for objects, it is totally impractical for the hierarchical objects that would be the norm in a world without those highly SL-dependent restrictions on object composition. An object will in general be composed of an arbitrary number of other objects arranged in an arbitrary tree, just like objects are composed of smaller components in the real world. This is the basis of engineering and the key to riding on the shoulders of giants. "Arbitrary number" could be hundreds for virtual objects with current-day levels of complexity, or thousands or more as our means of object production improve. Consequently, such piecemeal examination of permissions cannot be done realistically at interop time, but must be done at object construction time instead, propagating permissions up the composition tree as required. All we then need to do at interop time is to look at the root of the object tree and no deeper. Hierarchical objects are rather central to the success of the virtual object concept in VWs, and they are a linch-pin for the expansion of virtual economies with more complex technology too, so they're coming. More on this from the SL perspective is available here: https://wiki.secondlife.com/wiki/Prim_and_Object_Hierarchy . Morgaine. On Tue, Feb 24, 2009 at 6:40 AM, Gareth Nelson wrote: > Essentially, you'd need to look at each sub-component and then > evaluate what the restrictions are, applying the restrictions on > sub-components to the collected whole (since they're part of the > whole). > > i've actually withdrawn my proposal. > > On Mon, Feb 23, 2009 at 8:25 PM, William George > wrote: > > Nice first step, but it's not clear how this would handle composite > objects: > > objects that have two different creators and/or permissions settings. The > SL > > convention of using the root prim's permission for the entire object > leads > > to restrictions concerning the reuse of "no mod" sub assemblies in a > larger > > assemblies. > > > > > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --0016368e29ebdd87c40463b90a4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Gareth, although you've withdrawn your proposal, it addresses interesti= ng issues so I'd like to make a brief comment on your last point:
On Tue, Feb 24, 2009 at 6:40 AM, Gareth Nelson <gareth@litesim.com> wrote:<= br>
Essentially, you&= #39;d need to look at each sub-component and then
evaluate what the restrictions are, applying the restrictions on
sub-components to the collected whole (since they're part of the
whole).


While such examination is just about feasible a= t interop time in SL's non-hierarchical scheme for objects, it is total= ly impractical for the hierarchical objects that would be the norm in a wor= ld without those highly SL-dependent restrictions on object composition.
An object will in general be composed of an arbitrary number of other o= bjects arranged in an arbitrary tree, just like objects are composed of sma= ller components in the real world.=A0 This is the basis of engineering and = the key to riding on the shoulders of giants.=A0 "Arbitrary number&quo= t; could be hundreds for virtual objects with current-day levels of complex= ity, or thousands or more as our means of object production improve.

Consequently, such piecemeal examination of permissions cannot be done = realistically at interop time, but must be done at object construction time= instead, propagating permissions up the composition tree as required.=A0 A= ll we then need to do at interop time is to look at the root of the object = tree and no deeper.

Hierarchical objects are rather central to the success of the virtual o= bject concept in VWs, and they are a linch-pin for the expansion of virtual= economies with more complex technology too, so they're coming.=A0 More= on this from the SL perspective is available here:=A0 https://wiki.secondlife.= com/wiki/Prim_and_Object_Hierarchy .

Morgaine.







On = Tue, Feb 24, 2009 at 6:40 AM, Gareth Nelson <gareth@litesim.com> wrote:
=
Essentially, you'd need to look at each sub-component and then
evaluate what the restrictions are, applying the restrictions on
sub-components to the collected whole (since they're part of the
whole).

i've actually withdrawn my proposal.
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
>
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--0016368e29ebdd87c40463b90a4d-- From echeslack@gmail.com Tue Feb 24 23:26:53 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB6A528C14F for ; Tue, 24 Feb 2009 23:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJFa8XO3BlPg for ; Tue, 24 Feb 2009 23:26:52 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id AAB003A686C for ; Tue, 24 Feb 2009 23:26:51 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so1951742qwe.31 for ; Tue, 24 Feb 2009 23:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=uU81x1sbpM4huExe/9gbkFFk0ERYo3hMZztRvaU+hwg=; b=kd+7BR+A2pA9ZKY6xhdAVfm6lxVTibWxXjIegNk0b2YxE+cCrXRPE6CFlyvqzx4nAQ 4eFS7e9y+S+qaUr6qctsxvzsKqglVnGPQuRufCAD3L4q/2dfoS9px4FL/0QkYYJFGTg7 4OiLgfQgRi2YiTpyTUFduectWcMaaA8fRsXWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=jkGdfYxHSqJLoZKj6KD/fk0TkCnPtY07Oe7Ro9Srm18LWDooxn1uwzcelaOe1RVLdm BLwNCffr6Z5C3aniq2MszBMCTvAZbRxt0JLS6xxlENcVdRtIzZnPCBT1sQz60EVj9FDw LOocX0m6T6FhA2KDq9Y+Ujl9CbsJ1b3tXRYO0= MIME-Version: 1.0 Sender: echeslack@gmail.com Received: by 10.224.11.137 with SMTP id t9mr57294qat.135.1235546830907; Tue, 24 Feb 2009 23:27:10 -0800 (PST) In-Reply-To: <497C7FD9-BF36-458F-98C0-BEECAE611E1A@lindenlab.com> References: <49A4A8FA.607@gmail.com> <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> <497C7FD9-BF36-458F-98C0-BEECAE611E1A@lindenlab.com> Date: Tue, 24 Feb 2009 23:27:10 -0800 X-Google-Sender-Auth: 37ffb56b3fe6ffb4 Message-ID: From: Ewen Cheslack-Postava To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] The Structure and Interpretation of LLSD Messages [Was: Re: unefficient binary serialization ?] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 07:26:53 -0000 Maybe I'm just overlooking something, but how is this a problem? It looks like you added an enum and an optional field using that enum type to the PhoneNumber message type. Why would the serialization engine would fail? It ignores key value pairs it doesn't understand. The encoding provides sufficient type/size information to skip the field without understanding its contents. In fact, it will even collect those fields up and deliver them to you so you can try to use them. Protocol Buffers was designed (or probably more accurately, evolved) to support backwards and forwards compatibility. This is especially critical for google because they do slow rollouts of updated services, so they, at a minimum, have to be compatible between consecutive versions of their protocols. That being said, you certainly do have to be careful about compatibility when updating a message type or creating a new message that might be upgraded in the future. For instance, there are quite a few people who use optional by default so that its possible to remove fields if they are no longer necessary. But this is true for all serializations, so I wouldn't count that as a negative mark against protocol buffers. In fact, I'd say its an argument for it that it can handle it (as can LLSD, Thrift, XML, etc). -Ewen On Tue, Feb 24, 2009 at 11:06 PM, Meadhbh Hamrick (Infinity) wrote: > imagine you have a .proto file like: > > message Person { > required string name =3D 1; > required int32 id =3D 2; > optional string email =3D 3; > > enum PhoneType { > MOBILE =3D 0; > HOME =3D 1; > WORK =3D 2; > } > > message PhoneNumber { > required string number =3D 1; > optional PhoneType type =3D 2 [default =3D HOME]; > } > > repeated PhoneNumber phone =3D 4; > } > > and the next rev of the protocol is: > > message Person { > required string name =3D 1; > required int32 id =3D 2; > optional string email =3D 3; > > enum PhoneType { > MOBILE =3D 0; > HOME =3D 1; > WORK =3D 2; > } > > enum PhoneUsage { > > VOICE =3D 0; > > FAX =3D 1; > > MODEM =3D 2; > > } > message PhoneNumber { > required string number =3D 1; > optional PhoneType type =3D 2 [default =3D HOME]; > > optional PhoneUsage type =3D 3 [default =3D VOICE]; > } > > repeated PhoneNumber phone =3D 4; > } > > the problem is that if a endpoint expecting the former consumes the latte= r, > the serialization engine barfs. and you (in the application layer) don't > receive the message in order to try to pick it apart manually (which kind= of > defeats the purpose of the serialization.) > however, it _is_ an open source project, so we could probably create a > version of the library that adds a "fail silently" mode. > there are also semantics for extending messages, so maybe.. i'd have to l= ook > at it a little more before passing judgement. > > On Feb 24, 2009, at 10:45 PM, Morgaine wrote: > > Excellent background on LLSD, Infinity!=A0 It raises a question: > > On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) > wrote: > > while we have a metric tonne of code that uses the existing LLSD DTD, > ultimately, any additional serialization format that preserves these > processing expectations could be wedged into the system. serialization > formats that did not support these processing expectations would cause > considerable heart burn. > > > One serialization format that many have mentioned here is Google's Protoc= ol > Buffers.=A0 While I have barely started to examine PB myself, it is very = clear > that this serialization is extraordinarily efficient on-the-wire and also= at > both ends of the wire, as well as catering for the continual change that = is > inherent in large, evolving systems.=A0 A interest in extending the 3-way > serialization of XXSD to Protocol Buffers follows naturally. > > The question that is raised by the quoted paragraph is whether Protocol > Buffers "preserves these processing expectations".=A0 If it does then > extending the set of serializations to PB is work that could be done by > those interested in it, as an open project, and picked up by other users = of > XXSD if they wish.=A0 Potentially, the acceleration could be quite > significant, and hence the benefit to Limited Capability Clients very > important. > > On the other hand, if it does not "preserve these processing expectations= " > then there could be a problem. > > Do Lindens (or anyone else here) have any insight on this? > > Morgaine. > > > > > > > > On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) > wrote: > but here's one reason we like LLSD... > > imagine you have two systems that are interoperating... one is owned my m= e, > the other is owned by catherine. > > cathy's customers are all banks and insurance companies and are very > conservative, so cathy want's to err on the side of caution in terms of w= hen > she deploys new features. > > i on the other hand throw caution to the wind because my customers are al= l > first person shooter fanatics between the ages of 13 and 21 who demand th= e > latest features as soon as possible (otherwise they use david's server) > > it's not hard to see we're eventually going to introduce version slew whi= ch > will make it difficult for cathy and i to participate in the unregulated > business of marketing virtual life insurance policies to my customers. in > this example, i'm trying to point out that the both the option to retain > version parity with cathy and the option to upgrade to the latest version > are not without drawbacks. > > now.. imagine we have a PDU with three members while the second version a= dds > a member. for simplicity's sake, let's say they're all integers. > > if used the DTD to define the validation for the message, the first versi= on > of the message might look like: > > > 1.0//EN" "http://example.com/pdu/1.0/pdutastic.dtd"> > > =A013 > =A042 > =A093 > > > while the new version would look like this: > > > 1.1//EN" "http://example.com/pdu/1.1/pdutastic.dtd"> > > =A013 > =A042 > =A093 > =A0161 > > > so when i (expecting the new version) consume the old version, i do not s= ee > qux. but my parser doesn't complain because instead of the DTD of the new > PDU, i see a reference to the old PDU and say to myself... "it's okay... > it's just an older version," and i do whatever i have to do to continue > processing in the absence of the qux member i was expecting. even if i'm > doing validation, it's okay, i'm pulling the DTD from the old definition,= so > we're cool. > > now... when cathy consumes the new PDU, something similar happens. she se= e's > a DTD she's not familiar with, but it's all good.. she grabs teh DTD from > URL specified in teh DOCTYPE and moves on with her life, hoping that new > version PDU didn't change the semantics of the three values (foo, bar and > baz) she's familiar with. > > and then one day she receives this from david: > > > 1.2//EN" "http://example.com/pdu/1.2/pdutastic.dtd"> > > =A013 > =A02008-12-15T13:17:23.235Z > =A093 > =A0161 > > > aha! david, trying to steal my core demographic away from me has upgraded= to > the most recent beta version of the software (now with 13% more explosion= s) > > but this is now a serious problem for cathy. the "shape" of the structure= d > data now does not match. what does she do? how does she convert that date > into an integer? > > and this is the question we keep running into as we deploy "loosely coupl= ed" > systems. how do we fail gracefully and ensure robustness in the presence = of > PDU schema mismatches? > > the way linden answered this question was to develop LLSD, an abstract ty= pe > system with conversions and defaults. > > the way we would probably have defined the message above would have been > something like: > > > > =A0 > =A0 =A0foo > =A0 =A013 > =A0 =A0bar > =A0 =A02008-12-15T13:17:23.235Z > =A0 =A0baz > =A0 =A093 > =A0 =A0qux > =A0 =A0161 > =A0 > > > we don't include the doctype id 'cause our DTD never changes. in this > example the LLSD message is shorter 'cause we don't include the DOCTYPE i= d, > but even after removing the DOCTYPE id and changing the outer element to > llsd, the compressed version of the LLSD message is only seven bytes larg= er. > (an increase from 154 bytes to 161 bytes, an efficiency loss of 4.5%) > however, i can guarantee you that it took a lot less time to code the par= ser > because.. well.. we already had =A0a parser that knew how to unwrap LLSD > messages. > > but we haven't got to the interesting part yet. > > there is a processing expectation with LLSD. we assume we're de-serializi= ng > a message into a dynamic language like ECMAScript or Python. For language= s > like C++ and Java we create a class that emulates this feature. so.. all > LLSD PDUs are de-serialized into these LLSD objects, and inside our > application(s), it's these objects that get passed around. so we might ha= ve > code that looks like: > > public foo ( string message ) { > =A0 =A0 =A0 =A0LLSD llsd; > > =A0 =A0 =A0 =A0llsd =3D LLSD.From( message, LLSD.XML_SERIALIZATION ); > > =A0 =A0 =A0 =A0System.err.println( "hey! foo was %d.\n", (int) llsd.at( "= foo" > ).asInteger() ); > > =A0 =A0 =A0 =A0if( ( (int) llsd.at("bar").asInteger() > 100 ) || ( (int) > llsd.at("bar").asInteger() < 0 ) ) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0System.err.println( "bar is not a percenta= ge\n" ); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0System.haltAndCatchFire(); > =A0 =A0 =A0 =A0} > > > =A0 =A0 =A0 =A0if( (int) llsd.at("bar").asInteger() < 40 ) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0System.err.println( "sorry, this percent m= argin is way too > small for me to be interested.\n" ); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0System.haltAndCatchFire(); > =A0 =A0 =A0 =A0} > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0. > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0. > } > > forgive the javaisms, the alternative was smalltalk and well... let's not= go > there. > > for the sake of argument let's say we had already determined it was in XM= L > format by looking at the Content-Type: header from the request. > > so what we're doing here is not out of the ordinary... we create an insta= nce > of the LLSD class from the serialization. > > and we print some logging messages. > > and we then try to see if bar is between 0 an 100. > > but the object representing "foo" is a date, not an integer. what happens= ? > > in our current implementation of LLSD, we attempt to convert, but notice > that the conversion from date to integer has no semantic meaning. =A0beca= use > the conversion is "illegal," the default value is returned. > > the result of running this fragment would be something like > > =A0 =A0 =A0 =A0hey! foo was 0. > =A0 =A0 =A0 =A0sorry, this percent margin is way too small for me to be i= nterested. > > the important feature here is that we did not allow the "presentation lay= er" > to create an error. we did the best we could to interpret the sense of th= e > message, even to the point of making a nonsensical conversion. we allow t= his > to happen because we assume that at the application layer, we're going to= do > parameter checking. so the reasoning was... if we're going to be doing > parameter checking anyway, why would we want to allow the presentation la= yer > to fail a message that would have generated a result that could be checke= d > at the application layer? > > i hope you've enjoyed this installment of "the structure and interpretati= on > of LLSD messages." and i hope it helps explain our motivations for design= ing > LLSD and it's serializations the way we did... and while we have a metric > tonne of code that uses the existing LLSD DTD, ultimately, any additional > serialization format that preserves these processing expectations could b= e > wedged into the system. serialization formats that did not support these > processing expectations would cause considerable heart burn. > > -cheers > -meadhbh > > On Feb 24, 2009, at 6:12 PM, Jon Watte wrote: > > Catherine Pfeffer wrote: > That's precisely all the HUGE strength of LLSD. Having information about > what the data is intermingled with the data itself makes it very flexible > and future-proof. > But that is simply not necessary. If you transmit a reference to the sche= ma > you use when you initiate connection, then all future transmissions durin= g > that connection session can use the knowledge of that schema to highly > optimize traffic. Network traffic is actually one of the scarce resources > when you start scaling up really large virtual worlds. There are cases wh= ere > an entire office (20 people or more) share a single T1 connection to the > Internet, and expect to have a good virtual world experience for multiple > users at the same time. > > > Honestly, here, the bandwidth is not lost, compared to the advantages. > > > I think it is, because the size difference is quite significant. > > In summary, their binary serialization is as flexible as XML data. Perhap= s > I'm wrong, but to me it's an unique case in all computer science of a bin= ary > format that would be so flexible. > > Don't overextend yourself :-) AIFF/RIFF has pretty much the same > flexibility, as does TLV (also used in OSCAR), a number of "binary XML" > proposals, and a number of protocols that have all done more or less the > same thing ever since computers were interconnected on a larger scale in = the > '80s. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From cathypfeffer@gmail.com Wed Feb 25 04:48:00 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7212328C14B for ; Wed, 25 Feb 2009 04:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.322 X-Spam-Level: X-Spam-Status: No, score=-1.322 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJtOyZ8sgd+v for ; Wed, 25 Feb 2009 04:47:59 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id 8B61F3A6900 for ; Wed, 25 Feb 2009 04:47:55 -0800 (PST) Received: by ewy8 with SMTP id 8so3580ewy.13 for ; Wed, 25 Feb 2009 04:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=WoIodKdrZ8nvll7iZkLPNdrdrHbYXPPXbNxaatOnePE=; b=QeF2Tl9JNL1FChlJS4WoUTCU343/dq/LrBJ4RDxdUH68IU6U+bGrdNJ4YjrC7lmiL5 YaE1JDusbTus2Oh6+/qcP1c83hKM/UWPYXvPotVVwQXPPonCFjvyCCfhTqSuQdaQyL3G Z3bBr1uUIQiqLLKXErk3MHYb0plqzXqJkZ514= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=xxkfjExZYw1sjmExCZvuDCQVbMnDKhT/+dnG02QLl7y82sQ6AYHZxPNDY0JhuL6Ufn hPE0MMlecPU6EAzpHAMzHFb2gBtE8hHi2aB99TDJf2S+FqTc6PPi0/EmbFP1k7iY+PLS OYTAZ/Ou3edA+QtG/L1MPYy0vlf1ik8Mq7sY0= MIME-Version: 1.0 Received: by 10.210.133.19 with SMTP id g19mr56853ebd.125.1235566094833; Wed, 25 Feb 2009 04:48:14 -0800 (PST) Date: Wed, 25 Feb 2009 13:48:14 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c3b6a2dda7b0463bda601 Subject: [mmox] tags X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:48:00 -0000 --0015174c3b6a2dda7b0463bda601 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Infinity said: > about sizes of ints as attributes. > > let me pose the question... what is the difference in terms of > processing expectations if one sends > > '12' > > vs. sending > > '12' ? Honestly, having a tag is so ... unusual in the XML world, that I won't even attempt to answer this detail question and the next ones. We should simply abandon the idea of having , , and so on in the data flow. In a binary serialization, you need to say : the next four bytes will be an integer. Or the next 25 bytes will be a 25-bytes long string. Fine. But there is *no* reason to do the same in an XML file. The angle brackets < > or the quotes " " are delimiters. They tell you where the data starts and where it ends, so there is no need to say it an integer or whatever else. When you want to pass a key-value pair like Taper_X = 0.5 then if we want to stick to XML paradigm, it should be a ... Taper_X="0.5" ... attribute of some prim-related tag (14 bytes), and not ... Taper_X 0.5 ... in some (36 bytes plus the whitespace). The quotes " " tell where "0.5" starts and where it ends. The information "Taper_X is a float" belongs to the XML schema or DTD, not to the data sent over the wire. What I am trying to say is that the current xxSD XML serialization might look like XML, but it definitely belongs to another world from a conceptual point of view. It's like Canada Dry, it looks like beer, but it's no beer. What you have come up with is just a rewriting of the binary serialization that is well-formed XML. That does not make it something that fits naturally into XML: - LLIDL plays the same role as XML schemas or DTDs and could simply be dropped. - currently, accessing the value of Taper_X from XPath is convoluted and probably slow, compare: map/key[. = 'Taper_X']/following-sibling::float[position() = 1] with: @Taper_X - I also already mentioned the higher (250%) bandwidth footprint - etc What is the point of having a XML serialization just to have it "look like" some XML, while it's not really XML? OK, let's try to be positive (for once ;-) ): I am currently wondering if there is not an automated way to map the LLSD abstract view into a real XML-ish serialization. Perhaps that would make everyone happy. That would keep the very high flexibility of LLSD, have a lower angle bracket tax, and allow "natural" use of all XML tools. That would keep the possibility of having three different serializations, even though I still think that it's a false good idea. The technical problem I see with this approach is that the current LLSD draft does not recognize the special role played by the maps in storing name-value pairs used by the upper layers. It does not either say that arrays are made for vectors and quaternions, and so on. There is a lot of semantics that are evacuated from this draft and that I only know for having worked with SL client source code as an Open Source contributor. And I don't see how I could specify such an "intelligent" XML serialization if such context information is missing. (I apologize in advance if this context information is in the LLSD draft and I did not see it.) -- Cathy --0015174c3b6a2dda7b0463bda601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Infinity said:
> about sizes of ints as attributes.
>
> l= et me pose the question... what is the difference in terms of =C2=A0
>= ; processing expectations if one sends
>
>=C2=A0 '<integ= er size=3D"8">12</integer>'
>
> vs. sending
>
> '<integer size=3D"32&q= uot;>12</integer>' ?

Honestly, having a &= lt;integer> tag is so ... unusual in the XML world, that I won't eve= n attempt to answer this detail question and the next ones. We should simpl= y abandon the idea of having <integer>, <float>, <string>= and so on in the data flow.

In a binary serialization, you need to say :=C2=A0 the next four bytes = will be an integer. Or the next 25 bytes will be a 25-bytes long string. Fi= ne. But there is *no* reason to do the same in an XML file. The angle brack= ets < > or the quotes " " are delimiters. They tell you whe= re the data starts and where it ends, so there is no need to say it an inte= ger or whatever else.

When you want to pass a key-value pair like
=C2=A0=C2=A0=C2=A0 Taper= _X =3D 0.5
then if we want to stick to XML paradigm, it should be a
= =C2=A0=C2=A0=C2=A0 ... Taper_X=3D"0.5" ...
attribute of some p= rim-related tag (14 bytes), and not
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ...
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <key>Taper_X</key= >
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <float>= ;0.5</float>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ...
in some <map> (36 bytes plus the whitespace).

The q= uotes " " tell where "0.5" starts and where it ends. Th= e information "Taper_X is a float" belongs to the XML schema or D= TD, not to the data sent over the wire.

What I am trying to say is that the current xxSD XML serialization migh= t look like XML, but it definitely belongs to another world from a conceptu= al point of view. It's like Canada Dry, it looks like beer, but it'= s no beer.

What you have come up with is just a rewriting of the binary serialization = that is well-formed XML. That does not make it something that fits naturall= y into XML:
=C2=A0- LLIDL plays the same role as XML schemas or DTDs and= could simply be dropped.
=C2=A0- currently, accessing the value of Taper_X from XPath is convoluted = and probably slow, compare:
=C2=A0=C2=A0 map/key[. =3D 'Taper_X'= ]/following-sibling::float[position() =3D 1]=C2=A0 with:
=C2=A0=C2=A0 @T= aper_X
=C2=A0- I also already mentioned the higher (250%) bandwidth foot= print
=C2=A0- etc

What is the point of having a XML serialization just to = have it "look like" some XML, while it's not really XML?
<= br>
OK, let's try to be positive (for once ;-) ):

I am curren= tly wondering if there is not an automated way to map the LLSD abstract vie= w into a real XML-ish serialization. Perhaps that would make everyone happy= . That would keep the very high flexibility of LLSD, have a lower angle bra= cket tax, and allow "natural" use of all XML tools. That would ke= ep the possibility of having three different serializations, even though I = still think that it's a false good idea.

The technical problem I see with this approach is that the current LLSD= draft does not recognize the special role played by the maps in storing na= me-value pairs used by the upper layers. It does not either say that arrays= are made for vectors and quaternions, and so on. There is a lot of semanti= cs that are evacuated from this draft and that I only know for having worke= d with SL client source code as an Open Source contributor. And I don't= see how I could specify such an "intelligent" XML serialization = if such context information is missing.

(I apologize in advance if this context information is in the LLSD draf= t and I did not see it.)

--
Cathy
--0015174c3b6a2dda7b0463bda601-- From cathypfeffer@gmail.com Wed Feb 25 04:51:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D6E3A6900 for ; Wed, 25 Feb 2009 04:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcHMWwF1zdXq for ; Wed, 25 Feb 2009 04:51:35 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by core3.amsl.com (Postfix) with ESMTP id C93F23A688A for ; Wed, 25 Feb 2009 04:51:34 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d3so919nfc.39 for ; Wed, 25 Feb 2009 04:51:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=hJ+y9HuA8VxTxnS2UeHIg4RSKg3Go0kTHRMZ+dZlmfA=; b=YbsGIYmLTn2LX3VUh1N8yCeJ4T0d8ST9dJeigCUd5pnrr5S/24xy2WDtaDescb0WTv rRmgL0OgLclw3MYkCoaEAcHSuoLDAI9u/kO9XWCP8m8gDGTb9jn1xLeznuvykp9rD/jO PiT65I33wNsZIl3Ws39HWonrTSB9IxNeH+C9c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=t6Ad2pCLkqs4hmg9fW+YEPya/zCyMDosOYvx2WBHmADQfmP0rDYF5bec5ySZCcOL7Q Fr6nvYfpabFFILBZDWZUx3SN9Brf4L7uBC0H3ABPn4vaXM44c0JdnV2iwN4WB1jXY7rd wdW/clxf5ZvvQm5kAhRsgnhivJDGsAP1Bw0sc= MIME-Version: 1.0 Received: by 10.210.82.2 with SMTP id f2mr47528ebb.178.1235566313531; Wed, 25 Feb 2009 04:51:53 -0800 (PST) Date: Wed, 25 Feb 2009 13:51:53 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c40b036ea470463bdb3b9 Subject: [mmox] XML way loosely typed? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:51:35 -0000 --0015174c40b036ea470463bdb3b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Tom wrote: > Apologies if I missed the answer if it was in an earlier message... > > The "XML way" message appears to be loosly typed. How could a parser create an object from that > XML data and know the difference between an integer and a float, or a UUID and a string? >From the associated schema. The schema is the place where you usually declare the data types in the XML world. -- Cathy --0015174c40b036ea470463bdb3b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Tom wrote:
> Apologies if I missed the answer if it was in an earlier= message...
>
> The "XML way" message appears to be l= oosly typed. How could a parser create an object from that
> XML data= and know the difference between an integer and a float, or a UUID and a st= ring?

From the associated schema.

The schema is the place where you us= ually declare the data types in the XML world.

--
= Cathy
--0015174c40b036ea470463bdb3b9-- From belxjander@gmail.com Wed Feb 25 04:58:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179193A688A for ; Wed, 25 Feb 2009 04:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q36BN-EWyIms for ; Wed, 25 Feb 2009 04:58:48 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id E84263A67D6 for ; Wed, 25 Feb 2009 04:58:47 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so5487rvb.49 for ; Wed, 25 Feb 2009 04:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=HjfjPh01+XwtBw1snKgh5i7j15AnHLYq667gR3VcWwo=; b=ocBu01Zq8a7UmuXOWuGLhtHckLxdOtYHj4pyKxck43ZxO8mSi3V7HDXgs6XuJ5MuNC LuK7NUQlmgg6s7F46tFdqtpFdo+sQG+lOYV3GSXKvyBnREcmF824JayD/jR2IOuJSnbU CHgPHINgsLCWDFTaWjXqd919qwObmrhg7Q2hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=UHhgrmtCJgp4Pz+Yr+9mRzMk5iq4/eJfGb+ZE2VEQc+KdzmM/PtZh+bPYuzvM9x0TA Ven4rc4akMachiapTHSnwGqRxzdnNj258AiD4IGy5oPnlqm9Xv7lNMkEhbAbdHeyxUs1 AuYnEINUH70ZwZC/aIRjoq+q6J0lUfFh+DySY= Received: by 10.141.100.15 with SMTP id c15mr52716rvm.52.1235566747075; Wed, 25 Feb 2009 04:59:07 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id k2sm1573743rvb.4.2009.02.25.04.59.04 (version=SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 04:59:06 -0800 (PST) From: Kajikawa Jeremy To: Meadhbh Hamrick In-Reply-To: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VRPFLtpKOquuscWbrz97" Date: Wed, 25 Feb 2009 21:53:36 +0900 Message-Id: <1235566416.4026.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: "mmox@ietf.org" Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 12:58:49 -0000 --=-VRPFLtpKOquuscWbrz97 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2009-02-24 at 08:08 -0800, Meadhbh Hamrick wrote: > so... what started as a pleasant little proposal to take our (the =20 > awg's) pleasant little protocol (ogp) kick it around in public (the =20 > mmox mailing list) and potentially generate some RFCs from it seems to =20 > have spawned a number of discussions. _all_ of the discussions are =20 > interesting, but perhaps not all of them are germane to the proposed =20 > task. > so i ask.. is it appropriate to limit the discussion here to the MMOX =20 > Charter, LLSD, OGP and HyperGrid with occasional reference to the IETF =20 > IPR Disclosure Policy? > to be sure... we _are_ in the stage where the charter is important to =20 > discuss... but i'm just wondering... and these questions are here to =20 > spark _conversation_, not radical debate. there are rational answers, =20 > pro and con, to each of these questions and teasing them out is =20 > important... > * why would we care about HLA, DIS or IEEE-1278? they're already =20 > standardized. (though understanding that the structure of something =20 > like OGP differs from the structure of these protocols _is_ important.) > * why do we care about OLIVE, which is a proprietary protocol with a =20 > single implementation? > * why do we care about MXP whose apparent dependence on another =20 > protocol with unclear IPR encumbrance gives some people on this list =20 > the willies. >=20 > so the questions i pose are... > * pursuit of which of these topics brings us to our goal of an =20 > interoperable virtual worlds? > * what does it mean to be interoperable? > * must we have early agreement on all topics before we move forward =20 > with any component? > * OGP (Open Grid Protocol) > * should OGP be named something else? > * how do we do the event queue? (COMET? Bayeux? RHTTP? Long Poll?) > * where do we stuff permissions in this model? > * OGP/Teleport is not HyperGrid Open Grid Protocol currently limits itself by recognising SecondLife specifics before usability across to non-SecondLife services. an *interoperability* protocol needs to be based on a common formatting with layer approach similar to how the logical and physical layers of ethernet are seperated. Recognition of Identity - One User - Many VWs with Seperate or same login to all? Recognition of location - Where is the representation of the User? a single VW or multiple VWs sharing a common "location area" ? > * LLSD > * why is LLSD different from XDR? ASN.1? Google ProtocolBuffers? > * 128 bit integers? good enough? > * should LLSD be named something else? > * XML serialization > * maps are too much like apple plists in the XML serialization. LLSD or any other "format"/"protocol" and similar is binding nomenclature of an existing "name" and pushing recognition, the OpenGridProtocol would need to allow the serialization to be modularized and an option to replace it when newer specification versions need such a major change. > * MMOX Charter > * we should rename everything > * we should abandon interoperability in favor of general agreement of =20 > model is MMOX a branching of Linden Labs specifically or is this an *open* standard? Does linden lab want a delayed backlash from technical users akin to the backlash from Microsofts efforts with the MSOOXML and its having country votes *against* becoming a ratified standard? I propose a more fine-grained modular approach in the design of included material, OGP as it is may need to be changed from having LLSD serialization.=20 > * IETF > * Virtual Worlds in General > * Previously Established Protocols > * HLA, DIS, IEEE-1278 and related protocols > * OLIVE > * MXP? > * VRML Definitely be aware of these and how are they different?=20 > * Representation of virtual objects > * meshes vs. prims > * interaction models for virtual objects What is common and what is uncommon already? ... do we re-use an open format for serialization of OGP? > * Intellectual Property Regimes for Virtual Worlds > * Creative Commons (awesome gateway to free culture or the ultimate =20 > embodiment of evil in the noosphere?) > * DRM (the only way i'll trust you with my content or the ultimate =20 > embodiment of evil in the noosphere?) > * permissions regime > * MPEG-21? > * must we mandate the SL-style c/m/t permission? Mandating C/M/T from SecondLife or *any* kind of permissions into the serialization is in my own opinion a mistake and will lock the protocol to needing that section changed at cost in the future... =20 Defining a block extensible now will save effort > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-VRPFLtpKOquuscWbrz97 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJpT9QAAoJECHrKutFYVwTCHAQALxcUZu321pu2IAL4b1xT2pK ++fZ2KYy8uminrxeX90ROuC6rgkVxs/o46c11RaQBKgCsX53jFmWTmyisMkIbKta 5cVQvTRAmDAnZ9OFOy4gBf9c7FT2iaXqH/WIc5xVtDoD6/nzJ2Q3RYZeGfWTdHvi +LYWV/EGDJ9UsAbOyPFuslz/VBvqeETtcajaBtEG/yP+R4NpbwaRpgtadRl+yR3K 9pctsSFrUc2MdsQrtRXGEa1fdjTUBfeSJyBSK3tFAnQwsBwQ6GbHefMJ/05BDD2x Z40143qrIFAqipW5rt9zDO5sjpI6NjALUX9grZMQzSAy0ERsLft1M0ohCiNg86S9 bHZJwIkmVUQ0cVtM6ExeFuKzfC11Wti8nkqZwNAnlqOUJQg455xwTql6yIP1ezRi 4IE8Wj0e/xOSbVP7a0bpP7YCDPDuQKF4JzrUeOQgvQbME08GEPXzALnPsRSW8Pyr dVIOpHotONXJ1x8zW8Wp0fxiJodfM26d9VSUQMeI8gJ2ZiOcuHzsG+LbOtb6d8Ul VvJyXYaBPX/RihcxqaLu1yB8um6M+3savGYsTHK2YMX602eFDDTWACqe1Dc3PiTD el75qsk8ACiolNQ1o0/EHT15MY0yiD5fT3OewPHdM6LMDcOBuarb2tp6sO0dIUtk xn/LA8dqR5iZlEU/KHys =2dya -----END PGP SIGNATURE----- --=-VRPFLtpKOquuscWbrz97-- From cathypfeffer@gmail.com Wed Feb 25 05:13:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E17A28C169 for ; Wed, 25 Feb 2009 05:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-hHAIuSofd6 for ; Wed, 25 Feb 2009 05:13:19 -0800 (PST) Received: from mail-ew0-f164.google.com (mail-ew0-f164.google.com [209.85.219.164]) by core3.amsl.com (Postfix) with ESMTP id 740113A680B for ; Wed, 25 Feb 2009 05:13:19 -0800 (PST) Received: by ewy8 with SMTP id 8so10614ewy.13 for ; Wed, 25 Feb 2009 05:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=B5R8j+eYF/xGZ7ZcmEZoXChAMC9SQEq76TwYvIk2wIU=; b=fimHO72PfERG4AA/DR84+ELZJIOkxvrfv3gMlfb7vgxUyy+s3+4SXSiELQ1sBIcfw+ ny6QPVhatoldNP6BxWpjtZYaZxUaY1UKT4PqzDW07Ow3EzBRJlHxti/o4wcO/4FZape0 AgM4rXnQog/wflu6xQbM9q3WDgZriSZxURQSw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NFWZAa95nOfwdFgJnKwLB+gwlg/YJv9CatWQLhFI6rNKckSoZIRTySvIWNrRY46bW0 nmdNpV/418cuujQuw679TE/SpM1GbXxBMGFI7e0Pia4Y0l7J9cpB4o8Bu9VCwOWnOIeB 0ezWt784SsPjNwsr7P3hNlQpYjofGrraFvZW8= MIME-Version: 1.0 Received: by 10.210.11.17 with SMTP id 17mr91311ebk.32.1235567618439; Wed, 25 Feb 2009 05:13:38 -0800 (PST) Date: Wed, 25 Feb 2009 14:13:38 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174be630fe3afd0463be0050 Subject: [mmox] Conversions in an heterogeneous grid X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 13:13:20 -0000 --0015174be630fe3afd0463be0050 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Infinity wrote: > > 13 > 2008-12-15T13:17:23.235Z > 93 > 161 > Now consider : Nothing prevents you here from converting 2008-12-15T13:17:23.235Z into an integer percentage (zero) using the same conversion rules that are currently in the LLSD specification (you get expected and sent types from the schemas), or even, which is simpler, by using a "any-string to integer" conversion. -- Cathy --0015174be630fe3afd0463be0050 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Infinity wrote:
> <pdutastic>
>=C2=A0=C2=A0 <foo type= =3D"integer">13</foo>
>=C2=A0=C2=A0 <bar type= =3D"date">2008-12-15T13:17:23.235Z</bar>
>=C2=A0= =C2=A0 <baz type=3D"integer">93</baz>
>=C2=A0=C2=A0 <qux type=3D"integer">161</qux>
&= gt; </pdutastic>

Now consider :
<pdutastic=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 foo=3D"13"
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 bar=3D"2008-12-15T13:17:23.235Z"
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 baz=3D"93"
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 qux=3D"161" />

Nothing p= revents you here from converting 2008-12-15T13:17:23.235Z into an integer p= ercentage (zero) using the same conversion rules that are currently in the = LLSD specification (you get expected and sent types from the schemas), or e= ven, which is simpler, by using a "any-string to integer" convers= ion.

--
Cathy
--0015174be630fe3afd0463be0050-- From cathypfeffer@gmail.com Wed Feb 25 05:18:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F66B3A696E for ; Wed, 25 Feb 2009 05:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlEUHsEcHL1x for ; Wed, 25 Feb 2009 05:18:13 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by core3.amsl.com (Postfix) with ESMTP id 475083A67ED for ; Wed, 25 Feb 2009 05:18:11 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d3so2837nfc.39 for ; Wed, 25 Feb 2009 05:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Awem6qoUNE5dx3whaGzzWs//SQKLM9lKl953y8LS0RM=; b=Q9BgM3+2lwmpu8+ma789UPCXLgytxwzSDn56HWBNlgESHabK1O2rqg5vYw282ibelw EFLHOqbqVLVGRjveGm+tat2hDx2+t/sONyyL17njLbarzRweJg22/tfRDJzHz/bqfdrZ 64Q7hipr+wBKdaaO0qBIC/WuHcmaLiAL6LyS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Zms2I/lbV+92p0LW9l4JNbYzNNg9oWXmpNIYOG5FI/ARNk9W2dAkutAZxIHdO5wjQV Lj1Ekms/5xzsLyaiwiT9OlKXWYkpehyDbbbnJQ/sOM0d4gyTGgdAVpcmoELUkyeSOLr6 bDgpOo9mUH6h6w+dMq4SOBdr4E+m/XLRtdtZ4= MIME-Version: 1.0 Received: by 10.210.34.19 with SMTP id h19mr74618ebh.132.1235567910963; Wed, 25 Feb 2009 05:18:30 -0800 (PST) Date: Wed, 25 Feb 2009 14:18:30 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0015174c3d166dc8fb0463be124c Subject: [mmox] commas and dots X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 13:18:14 -0000 --0015174c3d166dc8fb0463be124c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > 127,255,127 > 100.0,75.3,28.6 > 0.5,-0.5,0.5,0.5 > > might seem ok, however, consider what happens when someone in a locale > with a different way of displaying the number tries to figure out what > this means? Yes, although a conventional format might be chosen. What is worse with such a syntax is that you don't take profit of XML facilities and reinvent your own syntax. Therefore is way better. -- Cathy --0015174c3d166dc8fb0463be124c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > <colour>127,255,127</colour>
> <vector>100.0,7= 5.3,28.6</vector>
> <quat>0.5,-0.5,0.5,0.5</quat>>
> might seem ok, however, consider what happens when someone i= n a locale
> with a different way of displaying the number tries to figure out what=
> this means?

Yes, although a conventional format might be ch= osen.

What is worse with such a syntax is that you don't take pr= ofit of XML facilities and reinvent your own syntax. Therefore
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <colour r=3D"127" g=3D"255= " b=3D"127" />
is way better.

-- =
Cathy
--0015174c3d166dc8fb0463be124c-- From cs@comlounge.net Wed Feb 25 07:34:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680CE3A68E4 for ; Wed, 25 Feb 2009 07:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[AWL=-5.000, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, URIBL_WS_SURBL=10] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBbEJ28vi5U9 for ; Wed, 25 Feb 2009 07:34:23 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 4CFA23A67D6 for ; Wed, 25 Feb 2009 07:34:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 5D1EA6F4023; Wed, 25 Feb 2009 16:34:41 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+G+QJuDMzyd; Wed, 25 Feb 2009 16:34:37 +0100 (CET) Received: from [192.168.1.20] (p5B39549B.dip.t-dialin.net [91.57.84.155]) by post.comlounge.net (Postfix) with ESMTP id 6BCBC1CE0235; Wed, 25 Feb 2009 16:34:36 +0100 (CET) Message-ID: <49A56509.30900@comlounge.net> Date: Wed, 25 Feb 2009 16:34:33 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <6B85E8A2-831E-43B1-B0AC-C504AB596B26@duke.edu> <49A48342.4020707@comlounge.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 15:34:25 -0000 Meadhbh Hamrick (Infinity) wrote: > cool. lemme put on my linden hat and throw out my US$0.02... > > in terms of identity, we have a strong preference for authenticating > application to application. part of the reason we like this is we have a > requirement that our HTTP traffic be able to flow over proxies (of both > the SOCKSish variety and the squidish caching variety.) we are therefore > paranoid that somewhere, somehow, transport layer authentication > information would be "eaten" by a misconfigured or miscoded piece of > required infrastructure. we understand that many people deploying VW > applications may not have this requirement, but we kindly ask people to > respect our requirements. but... just because we have defined an > application-layer-endpoint to application-layer-endpoint authentication > protocol does not mean we're going to try to ram it down everyone else's > collective throats. OpenID, OAuth, PKIX client certs and even *shudder* > gss-api all have a place in the world, and that place may include > authenticating endpoints in virtual world interactions. What do you mean by eaten? Are there proxies eating e.g. cookies or GET parameters? E.g. OAuth after all is just some GET parameters or a header field but you can choose. I understand that you have lots of infrastructure in place which might not be that easily compatible with it though. But this will be the case for everybody for most protocols we develop. But as said earlier, I would like to see the use cases being written down first with the requirements if *all* participant and then we can think about what the best solution might be (and we apparently need criteria for that where one might be the change costs for vendors, another interoperability outside the VW space). > in terms of non-second-life-like systems... yes... some people may > remember that Zero and I are both "smalltalk people" and have been > working with squeak from the early days. i mention it only to > contextualize the discussion with respect to croquet and some the > related commercial ventures (like qwaq.) personally, i like croquet and > have for a while. like any system it has it's benefits and its > drawbacks, but more germane to this discussion, uses an interaction > model that is slightly different than the one second life uses. > however... there's a statement in the draft charter identifying the > focus of this group as being "application layer wire protocols," and to > the degree that this statement survives the WG formation process... i > would hope we could define wire protocols that were independent enough > of the interaction model to at least allow some reuse of the PDUs. if > there was a way to make TObjects look like REST-like resources we might > be able to go further and reuse some of the interaction model. (but i'm > just offering it as a suggestion! i'm not saying croquet has to change > to be more SL like before we'll play nice with you!) and who knows... > maybe after detailed investigation of both system's interaction models, > we could find a way to denote them both with the same representational > system. I think we all need more understanding of how the other systems work. I know roughly how it's in SL but have no idea about Croquet or OLIVE or ... > with respect to service discovery... the "SL mode" right now is to > assume a list of services. ultimately this has got to change, and we > know that. that was part of the motivation for the design behind > OGP/Auth. At the end of authentication, the client is in possession of a > capability (protocol endpoint) from which it may request other > capabilities (protocol endpoints) that address resources which may be > accessed to request various services. all of the services CS mentions > below could easily be implementable with this technique. i've heard from > some quarters that capabilities give some people the willies and > honestly... they gave me the willies too until i drank the kool-aide and > started using BREW a couple years back. i would point out, however, that > they've been in constant use with SL for over 5 years now and they tend > to work quite well for us. ultimately, however, there are likely going > to be some people who won't want to use them and sure... that's fine... > what this means to me vis a vis protocol definition is we should > separate the acquisition of a service endpoint from the service it > enables. and this might be was CS was talking about below. As you know I don't really like caps ;-) I mostly do not like them because they are very different from what you do on the web and they are in fact somewhat more difficult to implement with a web framework (at least if we assume how the SL infrastructure is, OpenSim does it a bit differently). But that's probably detail and maybe there is even a way to keep caps for you and maybe add some header field for more web affine people. And I think if we still want to support the use case in which e.g. some social network can act as an Agent Domain (or the equivalent in some future MMOX protocol) then it's not very likely to assume that they implement caps. They more likely have OAuth and XRD-based service discovery in place. But you are right: We should definitely separate the discovery of these service endpoints from the services themselves and we shouldn't assume any service (or specific version of it) to be there. This gives us more flexibility and shouldn't be too hard to implement. > or it might have been about service versioning that came up from time to > time in the PyOGP list. fwiw... we tend to be "chunky" in our service > deployment, meaning we prefer to not operate several versions of related > services simultaneously, but i'm sure we can come up with a way to > create a versioning system in MMOX, and i warn people up front that > enabling such functionality would likely be a tough sell at linden, but > we wouldn't stand in the way of other virtual worlds operators / client > developers wanted to add it to a spec we claim we want to adhere to. but > just keep in mind we're likely to either strongly request the feature > was optional or use it in such a way that our grid always looks like it > only has a single version of each service. It also depends on how granular a service is. If they are relatively small then it's easier to exchange them, if they are a huge thing which do everything (like an AgentDomain in OGP) then it's hard. > merging social networking sites and virtual worlds sounds like a win, > but i wonder if it's not a better idea for the two to develop separately > and allow protocols in each area to reference each other. for example, > OpenSocial is, as i understand it, currently implemented as a set of > web-apis. i really like the idea of an opensocial app being able to > "reach into the virtual world" and i like the idea of our virtual world > supporting things like existing OpenSocial apps... let's just not make > it a REQUIRED part of the protocol anytime soon. Well, you say that it's hard to get changes into your codebase. Would this be any different if you really want to meet with the web at some point? I would do it now because I don't really see a win in making our own thing here. Web protocols might have problems and flaws in our scope here but those communities are open for discussion and of course cannot guess all possible use cases. e.g. the multi-service-authorization use case for OAuth is such a case where right now it's not really well working. I still think though that it can be made working by talking to the OAuth folks and proposing some extension. As for OpenSocial I don't speak about apps. All I am talking about is the OpenSocial REST API where you can do a simple GET (guarded by OAuth) to retrieve some persons profile. The OpenSocial Person schema might not fit our needs but we can again do it as extension and/or start a discussion on the OpenSocial list to make schemas more extensible themselves. We need to transfer profiles anyway and OpenSocial gives us REST and it gives us some basic schema to build upon. It also enables the possibility to e.g. import MySpace profiles today already. But what is required or not is again not a discussion for now but for sometime after use case definition and requirements capturing. Then we can really say if it fits or not. as a sidenote: I wrote down a workflow of an experiment I was coding 2 evenings ago which uses OpenID, OAuth and OpenSocial to import a profile. You can find it here: http://socialconnect.info/trac/wiki/WorkflowNumberOne Code is following soon. > so... to paraphrase... to the degree that linden can be the 800 lb. > gorilla in a room where virtual worlds are being discussed and blizzard > hasn't shown up... i promise to use my secret powers for good. the lab > has no interest in scuttling anyone else's product roadmap but we ask > that the more agile participants in this group give us a little slack > with what we're able to implement and how fast. compared to the open sim > peeps, we must seem like dinosaurs, and compared to tao, we're probably > stromatolites. i just ask that peeps here please keep in mind we have an > onerous repository of legacy code and a large installed base we can't > abandon, so there's a reason we're moving slower than people might like. I think protocol definition and implementation are two different things. Defining a protocol for VW interoperability is IMHO a very huge undertaking because the problem domain is so huge and every participant has their own flavour of what they want, need and can do in a reasonable time for a reasonable budget. So everybody needs time to implement changes and they might not be small. And because of that I hope not that it means just because SL might be slower in adapting we use more SL related technology just because it makes it easier for LL. I am not against using that technology if it makes sense but before that I really want to know what the other vendors do, why they do it and what's important to them. That it already works well can probable be said about the technology of every vendor participating. My last point is about the huge problem space. Maybe it really makes sense to first cut that into pieces. My pet peeve apparently is a portable identity or in more general maybe data portability and I would already be happy if I can login with my SL account in There, Kaneva and so on without creating a new one. Also having my friends from elsewhere being on my friendlist there automatically would be great. All this of course under the premise that I can control who can see what data. Other things like object transfer and making 3D representations compatible might then come afterwards. -- Christian PS: I don't think you are stromatolites ;-) SL came a big way and helped to make VWs popular. And what now is live deployed is probably all very much grown and also based in a time where nobody talked about OAuth or OpenSocial. And I know that changing such a system and keep it running is a huge task in itself and also risky. So I understand your problems and I also understand why it's easier for LL to just standardize OGP. > > -cheers > -meadhbh > > On Feb 24, 2009, at 3:31 PM, Christian Scholz wrote: > >> Mark P. McCahill schrieb: >>> +1 >>> I really like the approach David is taking here. The first two items: >>> * managing identity >>> * naming and authenticating services in MMOX worlds >>> are prerequisites for getting anywhere with cross-system >>> interoperability, >>> would benefit users of existing systems, and should be achievable in the >>> fairly near term. Understanding how to negotiate these services is the >>> place to start, rather than defining an abstract wire-level protocol, if >>> the intent is to bring something other than Second Life-like worlds into >>> the fold. >> >> +1 and I would actually list: >> >> - defining an identity endpoint >> - service discovery to find services for this identity such as profile >> definition, friends list, inventory server, ... >> - distributed authorization >> >> Then having a way defined for services to be found and authorized one >> could define the specifics of these services. >> >> I would extend this beyond MMOX worlds though because there is huge >> interest in the web and social networking players as well. >> >> So maybe a seperate working group which has not the focus so much just >> on virtual worlds for this part might make sense. But I have no idea >> about the IETF process anyway at this time and if and how this would >> be possible or wanted. >> >> -- Christian >> >> >>> Mark McCahill >>> On Feb 24, 2009, at 11:04 AM, David W Levine wrote: >>>> >>>> 1. The ability to manage one's identity when interacting in >>>> multiple MMOX spaces. >>>> a. Allowing presence information to be shared and >>>> coordinated across >>>> MMOX spaces >>>> b. Permitting friends lists, and IMs to be shared >>>> across spaces >>>> c. Permitting MMOX spaces to share naming >>>> d. Simple ways of allowing a consistent name, managed >>>> by the user, and >>>> verifiable by other users >>>> e. Single sign on, mediated by multiple spaces, within >>>> the policy constraints >>>> of the spaces >>>> f. A consistent appearance, within the constraints of >>>> the various systems >>>> g. The ability to manage the degree of visibility / >>>> coupling between identities >>>> in MMOX spaces >>>> >>>> Note that for all of these, there is no requirement to couple the >>>> systems together >>>> beyond managing identity, and share presence and IM information. >>>> These use >>>> cases don't speak to how you move between spaces. You may have to >>>> shutdown >>>> your client on one system and start another. This also is not a "You >>>> must enable >>>> this" this is very much a "Make it easy for spaces which want to >>>> enable this to do >>>> it." Also, note that "presence and messaging" speak to user needs, >>>> and consitent >>>> appearance and name (when desired by users) again speeks to meeting >>>> user's >>>> desires. >>>> >>>> 2. The ability for the services in an MMOX world to be named, >>>> and authenticated >>>> a. Services to associate virtual places and the >>>> services which support them >>>> with authentication and administrative domains >>>> b. Services to permit a service to validate the >>>> membership of a remote >>>> service in one or more authentication and administrative domains >>>> >>>> This is needed so that we can do essentially any of the >>>> interoperability work. >>>> Without some framework which lets us know who we are talking to, it is >>>> impossible to trust the behavior of distributed systems. >>>> >>>> 3. The ability to share content between MMOX spaces >>>> a. Import and Export of content and models (This may >>>> well leverage off of >>>> existing work such as Collada) Static, import/export of >>>> content while not >>>> terribly dramatic is an important part of the value chain of >>>> interoperability >>>> b. Mark up schemes which recognize the existence of >>>> multiple presentation >>>> environments, but permit the sharing of content >>>> i. Shared "type" information for the various >>>> types of graphical >>>> content which MMOX spaces contain >>>> ii. Extensible, with a common registry, so that >>>> we can understand the >>>> types of contents a client can accept, and a >>>> virtual space, or virtual >>>> asset store can be asked to provide >>>> c. A MMOX based, system independent asset addressing >>>> scheme which includes >>>> i. Content negotiation based on 2b >>>> ii. Access Management based on (1) and (2) >>>> >>>> This is, to my mind, the key mid term deliverable >>>> >>>> 4. The affordances in MMOX to permit the creation of >>>> micro-payment economies >>>> a. Appropriate spots defined in MMOX protocols for cost >>>> information >>>> b. Appropriate spots defined in MMOX protocols for >>>> reference to >>>> micropayment systems >>>> >>>> 5. The ability to share "non immersive streams" between spaces >>>> a. Markup to permit the consistent sharing of stream >>>> media such as voice, >>>> and video, with shared start and synchronization >>>> information to permit >>>> "parallel" events between MMOX space >>>> >>>> 6. The ability to express Policy intent between MMOX services >>>> and virtual spaces >>>> a. Places in reserved in the MOX protocols for >>>> expressing policy intent >>>> b. One or more policy languages for expressing policy >>>> >>>> >>>> The solution space: >>>> >>>> Most of the deployed solutions partition the software problem into >>>> the following chunks. >>>> >>>> 1. Some form of a client which permits a user to interact >>>> with the shared experience >>>> 2. Virtual space servers which manage the state of a portion >>>> of virtual space >>>> 3. A set of supporting services used by the virtual space >>>> servers >>>> >>>> Note that exactly how these three large chunks are assembled and the >>>> granular nature of >>>> the services can vary radically, even when serving very similar >>>> environments. Some >>>> environments push a large amount of rendering and management onto >>>> complex clients, >>>> others perform the bulk of rendering in the server portion of the >>>> deployment. Some >>>> implementations combine client and simulation into a single entity >>>> which does some >>>> simulation and some user presentation. Some distribute the >>>> simulation, some centralize it. >>>> >>>> The heart of most of the solutions is managing to accept and merge a >>>> stream of updates, >>>> and then distribute the merged updates back to users. This can >>>> happen at a range of >>>> granularities. The two ends of the spectrum, are, roughly, sending >>>> updates as a fully >>>> merged audio visual stream, which the client merely displays, and >>>> sending low level >>>> changes to a underlying mode, which the client uses to assemble a >>>> complete visual >>>> representation of the scene. Variations include croquet and qwaq >>>> which use an >>>> underlying distributed object model to pass large amounts of >>>> updates, and approaches >>>> such as used by SecondLife and Protonsphere, where voice is managed >>>> in a separate >>>> service, with the merged state service merely letting the voice >>>> service know where the >>>> users are located. >>>> >>>> Closely related, are issues of representation and format of content. >>>> This takes several, >>>> separable forms. Import and Export of material to the core >>>> environment, and, more >>>> problematically, run time representations >>>> >>>> Approach >>>> Our overall approach should be web centric, and web services >>>> oriented. We can, and >>>> should think of sets of related services which can be composed as >>>> part of different >>>> solutions which will enable varying degrees of interoperability. We >>>> can, and should >>>> attempt to provide as web like an approach to function as possible. >>>> Content negotiation, >>>> separation of protocol from security, separation of interface from >>>> implementation and >>>> other techniques. >>>> >>>> Our goal is not to enshrine any single virtual world as the standard >>>> for all MMOX spaces, >>>> but rather create a flexible, extensible set of services which will >>>> allow us to grow larger >>>> and large overlapping sets of capabilities. My expectation is that >>>> we will see a lot of low >>>> hanging fruit in the area of identity, authentication, authorization >>>> and presence >>>> management (Where a user is, and allowing messaging to them across >>>> MMOX spaeces) >>>> and initially, we will find a lot of format and content area >>>> addressed by gateways, >>>> markup, and content negotiation. I see nothing wrong with having a >>>> URI which refers to >>>> "A pretty maple tree with fall colors" which provides a way to fetch >>>> the "Collada Style >>>> version" the "3dMax Mesh version" the "Linden Lab 1.2 sculpty spec >>>> version" such that >>>> a virtual space can select, through content negotiation the one most >>>> useful to it. >>>> >>>> We get value, when we have consistent ways of referring to all the >>>> various forms of >>>> content, and we get more value when we have ways of using existing >>>> content negotiation >>>> to allow a web light selection of an appropriate form. It is equally >>>> possible to imagine >>>> negotiating between a client and a virtual space, the desired form >>>> of objects. There are >>>> some deep challenges lurking, such as when two different approaches >>>> have radically >>>> different >>>> >>>> What I would encourage us, as a mailing list to do, is look through >>>> the problem >>>> statement, and interoperability goals I've put together here. They >>>> are an attempt to >>>> capture the various sentiments in the ongoing discussion. I am sure >>>> I have missed points, >>>> and I am sure some people will disagree with some of the points I >>>> have made. >>>> >>>> I would ask people to look for "No, you missed X" and "Hey, I don't >>>> think Y" is true. I >>>> will attempt to capture all of those, and revise the document, until >>>> we think it represents >>>> something close to the general group consensus. (I am not looking >>>> for 100% consensus, >>>> but a "Yeah, this captures most of what we're trying to do." With >>>> that in hand, I would >>>> suggest we could then begin to enumerate the specific services and >>>> markups we need to >>>> support our goals, and begin to flesh out use cases to help us >>>> understand the goals and >>>> services. >>>> >>>> I do not expect this to yield a set of specs which Linden Lab, or >>>> OpenSim, Or any one >>>> virtual world vendor or project would implement whole. What I expect >>>> it to yield is a set >>>> of specs, which can be combined with existing projects and code >>>> bases to drive us >>>> towards a more interoperable future. >>>> >>>> Out of scope >>>> >>>> I also want to begin to accumulate a short list of "No, this is out >>>> of scope" assertions >>>> >>>> 1. We will provide all the affordances necessary to permit a >>>> broad range of >>>> interaction policies. Appropriate policies for various deployed >>>> solutions and >>>> future deployed solutions is out of scope, beyond providing us use >>>> cases which >>>> highlight specific affordances we may wish to consider >>>> 2. Whether or not immersive multi-party spaces are useful and >>>> which specific >>>> capabilities are required is out of scope. We aspire to support a >>>> broad range of >>>> possible capabilities, and we respect that different organizations >>>> will have >>>> different perspectives on what is required. Our goal is to define >>>> broad, >>>> interoperable frameworks which will enable a range of deployments, >>>> not to define >>>> the one true model for this space >>>> 3. Propose additional statements here >>>> >>>> Closing comments >>>> >>>> I don't think our collective goal can be to take any one existing >>>> spec or solution and >>>> simply declare it the basis for our work going forward. At the same >>>> time, we must base >>>> our work in actually running code, showing real interoperability. >>>> Our goal must be to >>>> build supersets of function, based on existing products and >>>> solutions which demonstrate >>>> real interoperability. >>>> >>>> The IETF favors working code and growing consensus over blank paper >>>> and blue sky >>>> efforts. This is based in a history of success and failure in the >>>> industry when it comes to >>>> building, promoting and succeeding at standards work. Work at the >>>> IETF is grounded in >>>> working code. >>>> >>>> One way forward is to focus on several clusters of work. One: a >>>> clear, broad framework, >>>> which forms the basis for long term broad interoperation. Two: >>>> Capturing the current set >>>> of incompatible and overlapping formats and protocols in use, so >>>> that we can create a >>>> extensible and shared catalog of artifacts for sharing. (eg. "Here >>>> is the canonical, >>>> extensible list of graphic content types you might want to move on >>>> a MMOX transport" >>>> Three grow out proposed solutions such as LLSD, OGP, and others, as >>>> they are >>>> contributed towards a common superset which can be used to as the >>>> basis for >>>> demonstrating concrete progress towards interop goals. Four, >>>> Identify places where we >>>> simply want to use existing work, such as OpenID, OAuth, X.509 and >>>> create a shared >>>> profile for how we can use these protocols to further interoperability. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> mmox mailing list >>>> mmox@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmox >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> >> >> -- >> Christian Scholz >> Blog: http://mrtopf.de/blog >> Company: http://comlounge.net >> Podcasts: http://datawithoutborders.net, http://openweb-podcast.de >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > -- 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 cs@comlounge.net 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 infinity@lindenlab.com Wed Feb 25 09:09:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54D6C28C1D3 for ; Wed, 25 Feb 2009 09:09:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkKOYwhNxiH3 for ; Wed, 25 Feb 2009 09:09:52 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id A578E28C1CB for ; Wed, 25 Feb 2009 09:09:52 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 5CC6F3DBC063; Wed, 25 Feb 2009 09:10:12 -0800 (PST) Message-Id: <06CF9E4E-6C20-46CB-B092-68F702C2E185@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Ewen Cheslack-Postava In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 09:10:12 -0800 References: <49A4A8FA.607@gmail.com> <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> <497C7FD9-BF36-458F-98C0-BEECAE611E1A@lindenlab.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] The Structure and Interpretation of LLSD Messages [Was: Re: unefficient binary serialization ?] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:09:54 -0000 i'm relying on rusty neurons to make this assertion, but i think protocol buffers will fail if you parse a message with an additional required member. but this isn't that big of a deal since we like optional members in LLSD. but i'm also at a bit of a loss for figuring out how to represent variant records with GPB. which is to say, i'm sure it can be done and i'm pretty sure it "won't be pretty" in the sense that to support variants, you may have to do things that avoid using the innate structure representation of GPB. and at that point, unless google (or someone else) is opening up an LLSD service, maybe the thing to do would be to have a protocol gateway that takes LLSD style PDUs in one side and emits GPB messages out the other. On Feb 24, 2009, at 11:27 PM, Ewen Cheslack-Postava wrote: > Maybe I'm just overlooking something, but how is this a problem? It > looks like you added an enum and an optional field using that enum > type to the PhoneNumber message type. Why would the serialization > engine would fail? It ignores key value pairs it doesn't understand. > The encoding provides sufficient type/size information to skip the > field without understanding its contents. In fact, it will even > collect those fields up and deliver them to you so you can try to use > them. Protocol Buffers was designed (or probably more accurately, > evolved) to support backwards and forwards compatibility. This is > especially critical for google because they do slow rollouts of > updated services, so they, at a minimum, have to be compatible between > consecutive versions of their protocols. > > That being said, you certainly do have to be careful about > compatibility when updating a message type or creating a new message > that might be upgraded in the future. For instance, there are quite a > few people who use optional by default so that its possible to remove > fields if they are no longer necessary. But this is true for all > serializations, so I wouldn't count that as a negative mark against > protocol buffers. In fact, I'd say its an argument for it that it can > handle it (as can LLSD, Thrift, XML, etc). > > -Ewen > > On Tue, Feb 24, 2009 at 11:06 PM, Meadhbh Hamrick (Infinity) > wrote: >> imagine you have a .proto file like: >> >> message Person { >> required string name = 1; >> required int32 id = 2; >> optional string email = 3; >> >> enum PhoneType { >> MOBILE = 0; >> HOME = 1; >> WORK = 2; >> } >> >> message PhoneNumber { >> required string number = 1; >> optional PhoneType type = 2 [default = HOME]; >> } >> >> repeated PhoneNumber phone = 4; >> } >> >> and the next rev of the protocol is: >> >> message Person { >> required string name = 1; >> required int32 id = 2; >> optional string email = 3; >> >> enum PhoneType { >> MOBILE = 0; >> HOME = 1; >> WORK = 2; >> } >> >> enum PhoneUsage { >> >> VOICE = 0; >> >> FAX = 1; >> >> MODEM = 2; >> >> } >> message PhoneNumber { >> required string number = 1; >> optional PhoneType type = 2 [default = HOME]; >> >> optional PhoneUsage type = 3 [default = VOICE]; >> } >> >> repeated PhoneNumber phone = 4; >> } >> >> the problem is that if a endpoint expecting the former consumes the >> latter, >> the serialization engine barfs. and you (in the application layer) >> don't >> receive the message in order to try to pick it apart manually >> (which kind of >> defeats the purpose of the serialization.) >> however, it _is_ an open source project, so we could probably >> create a >> version of the library that adds a "fail silently" mode. >> there are also semantics for extending messages, so maybe.. i'd >> have to look >> at it a little more before passing judgement. >> >> On Feb 24, 2009, at 10:45 PM, Morgaine wrote: >> >> Excellent background on LLSD, Infinity! It raises a question: >> >> On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) >> wrote: >> >> while we have a metric tonne of code that uses the existing LLSD DTD, >> ultimately, any additional serialization format that preserves these >> processing expectations could be wedged into the system. >> serialization >> formats that did not support these processing expectations would >> cause >> considerable heart burn. >> >> >> One serialization format that many have mentioned here is Google's >> Protocol >> Buffers. While I have barely started to examine PB myself, it is >> very clear >> that this serialization is extraordinarily efficient on-the-wire >> and also at >> both ends of the wire, as well as catering for the continual change >> that is >> inherent in large, evolving systems. A interest in extending the 3- >> way >> serialization of XXSD to Protocol Buffers follows naturally. >> >> The question that is raised by the quoted paragraph is whether >> Protocol >> Buffers "preserves these processing expectations". If it does then >> extending the set of serializations to PB is work that could be >> done by >> those interested in it, as an open project, and picked up by other >> users of >> XXSD if they wish. Potentially, the acceleration could be quite >> significant, and hence the benefit to Limited Capability Clients very >> important. >> >> On the other hand, if it does not "preserve these processing >> expectations" >> then there could be a problem. >> >> Do Lindens (or anyone else here) have any insight on this? >> >> Morgaine. >> >> >> >> >> >> >> >> On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) >> wrote: >> but here's one reason we like LLSD... >> >> imagine you have two systems that are interoperating... one is >> owned my me, >> the other is owned by catherine. >> >> cathy's customers are all banks and insurance companies and are very >> conservative, so cathy want's to err on the side of caution in >> terms of when >> she deploys new features. >> >> i on the other hand throw caution to the wind because my customers >> are all >> first person shooter fanatics between the ages of 13 and 21 who >> demand the >> latest features as soon as possible (otherwise they use david's >> server) >> >> it's not hard to see we're eventually going to introduce version >> slew which >> will make it difficult for cathy and i to participate in the >> unregulated >> business of marketing virtual life insurance policies to my >> customers. in >> this example, i'm trying to point out that the both the option to >> retain >> version parity with cathy and the option to upgrade to the latest >> version >> are not without drawbacks. >> >> now.. imagine we have a PDU with three members while the second >> version adds >> a member. for simplicity's sake, let's say they're all integers. >> >> if used the DTD to define the validation for the message, the first >> version >> of the message might look like: >> >> >> > PDU >> 1.0//EN" "http://example.com/pdu/1.0/pdutastic.dtd"> >> >> 13 >> 42 >> 93 >> >> >> while the new version would look like this: >> >> >> > PDU >> 1.1//EN" "http://example.com/pdu/1.1/pdutastic.dtd"> >> >> 13 >> 42 >> 93 >> 161 >> >> >> so when i (expecting the new version) consume the old version, i do >> not see >> qux. but my parser doesn't complain because instead of the DTD of >> the new >> PDU, i see a reference to the old PDU and say to myself... "it's >> okay... >> it's just an older version," and i do whatever i have to do to >> continue >> processing in the absence of the qux member i was expecting. even >> if i'm >> doing validation, it's okay, i'm pulling the DTD from the old >> definition, so >> we're cool. >> >> now... when cathy consumes the new PDU, something similar happens. >> she see's >> a DTD she's not familiar with, but it's all good.. she grabs teh >> DTD from >> URL specified in teh DOCTYPE and moves on with her life, hoping >> that new >> version PDU didn't change the semantics of the three values (foo, >> bar and >> baz) she's familiar with. >> >> and then one day she receives this from david: >> >> >> > PDU >> 1.2//EN" "http://example.com/pdu/1.2/pdutastic.dtd"> >> >> 13 >> 2008-12-15T13:17:23.235Z >> 93 >> 161 >> >> >> aha! david, trying to steal my core demographic away from me has >> upgraded to >> the most recent beta version of the software (now with 13% more >> explosions) >> >> but this is now a serious problem for cathy. the "shape" of the >> structured >> data now does not match. what does she do? how does she convert >> that date >> into an integer? >> >> and this is the question we keep running into as we deploy "loosely >> coupled" >> systems. how do we fail gracefully and ensure robustness in the >> presence of >> PDU schema mismatches? >> >> the way linden answered this question was to develop LLSD, an >> abstract type >> system with conversions and defaults. >> >> the way we would probably have defined the message above would have >> been >> something like: >> >> >> >> >> foo >> 13 >> bar >> 2008-12-15T13:17:23.235Z >> baz >> 93 >> qux >> 161 >> >> >> >> we don't include the doctype id 'cause our DTD never changes. in this >> example the LLSD message is shorter 'cause we don't include the >> DOCTYPE id, >> but even after removing the DOCTYPE id and changing the outer >> element to >> llsd, the compressed version of the LLSD message is only seven >> bytes larger. >> (an increase from 154 bytes to 161 bytes, an efficiency loss of 4.5%) >> however, i can guarantee you that it took a lot less time to code >> the parser >> because.. well.. we already had a parser that knew how to unwrap >> LLSD >> messages. >> >> but we haven't got to the interesting part yet. >> >> there is a processing expectation with LLSD. we assume we're de- >> serializing >> a message into a dynamic language like ECMAScript or Python. For >> languages >> like C++ and Java we create a class that emulates this feature. >> so.. all >> LLSD PDUs are de-serialized into these LLSD objects, and inside our >> application(s), it's these objects that get passed around. so we >> might have >> code that looks like: >> >> public foo ( string message ) { >> LLSD llsd; >> >> llsd = LLSD.From( message, LLSD.XML_SERIALIZATION ); >> >> System.err.println( "hey! foo was %d.\n", (int) llsd.at( "foo" >> ).asInteger() ); >> >> if( ( (int) llsd.at("bar").asInteger() > 100 ) || ( (int) >> llsd.at("bar").asInteger() < 0 ) ) { >> System.err.println( "bar is not a percentage\n" ); >> System.haltAndCatchFire(); >> } >> >> >> if( (int) llsd.at("bar").asInteger() < 40 ) { >> System.err.println( "sorry, this percent margin is >> way too >> small for me to be interested.\n" ); >> System.haltAndCatchFire(); >> } >> . >> . >> . >> } >> >> forgive the javaisms, the alternative was smalltalk and well... >> let's not go >> there. >> >> for the sake of argument let's say we had already determined it was >> in XML >> format by looking at the Content-Type: header from the request. >> >> so what we're doing here is not out of the ordinary... we create an >> instance >> of the LLSD class from the serialization. >> >> and we print some logging messages. >> >> and we then try to see if bar is between 0 an 100. >> >> but the object representing "foo" is a date, not an integer. what >> happens? >> >> in our current implementation of LLSD, we attempt to convert, but >> notice >> that the conversion from date to integer has no semantic meaning. >> because >> the conversion is "illegal," the default value is returned. >> >> the result of running this fragment would be something like >> >> hey! foo was 0. >> sorry, this percent margin is way too small for me to be >> interested. >> >> the important feature here is that we did not allow the >> "presentation layer" >> to create an error. we did the best we could to interpret the sense >> of the >> message, even to the point of making a nonsensical conversion. we >> allow this >> to happen because we assume that at the application layer, we're >> going to do >> parameter checking. so the reasoning was... if we're going to be >> doing >> parameter checking anyway, why would we want to allow the >> presentation layer >> to fail a message that would have generated a result that could be >> checked >> at the application layer? >> >> i hope you've enjoyed this installment of "the structure and >> interpretation >> of LLSD messages." and i hope it helps explain our motivations for >> designing >> LLSD and it's serializations the way we did... and while we have a >> metric >> tonne of code that uses the existing LLSD DTD, ultimately, any >> additional >> serialization format that preserves these processing expectations >> could be >> wedged into the system. serialization formats that did not support >> these >> processing expectations would cause considerable heart burn. >> >> -cheers >> -meadhbh >> >> On Feb 24, 2009, at 6:12 PM, Jon Watte wrote: >> >> Catherine Pfeffer wrote: >> That's precisely all the HUGE strength of LLSD. Having information >> about >> what the data is intermingled with the data itself makes it very >> flexible >> and future-proof. >> But that is simply not necessary. If you transmit a reference to >> the schema >> you use when you initiate connection, then all future transmissions >> during >> that connection session can use the knowledge of that schema to >> highly >> optimize traffic. Network traffic is actually one of the scarce >> resources >> when you start scaling up really large virtual worlds. There are >> cases where >> an entire office (20 people or more) share a single T1 connection >> to the >> Internet, and expect to have a good virtual world experience for >> multiple >> users at the same time. >> >> >> Honestly, here, the bandwidth is not lost, compared to the >> advantages. >> >> >> I think it is, because the size difference is quite significant. >> >> In summary, their binary serialization is as flexible as XML data. >> Perhaps >> I'm wrong, but to me it's an unique case in all computer science of >> a binary >> format that would be so flexible. >> >> Don't overextend yourself :-) AIFF/RIFF has pretty much the same >> flexibility, as does TLV (also used in OSCAR), a number of "binary >> XML" >> proposals, and a number of protocols that have all done more or >> less the >> same thing ever since computers were interconnected on a larger >> scale in the >> '80s. >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> From lenglish5@cox.net Wed Feb 25 09:11:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB6A128C258 for ; Wed, 25 Feb 2009 09:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.88 X-Spam-Level: X-Spam-Status: No, score=0.88 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K586Kfk7pcEa for ; Wed, 25 Feb 2009 09:11:54 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 1B2ED28C254 for ; Wed, 25 Feb 2009 09:11:54 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090225171214.DXMR10385.fed1rmmtao107.cox.net@fed1rmimpo03.cox.net>; Wed, 25 Feb 2009 12:12:14 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id LHCE1b0094N6T0Q04HCEgt; Wed, 25 Feb 2009 12:12:14 -0500 X-Authority-Analysis: v=1.0 c=1 a=p0nbaXBoQyQA:10 a=7xlGZuZgQMUA:10 a=Wajolswj7cQA:10 a=F_HBYQjVbwErF811u8UA:9 a=f15S93ZXEYV6TQNUP_kA:7 a=4yUPCWxB32lAQ6gdn_hFK_uW20oA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <49A57BEE.5000803@cox.net> Date: Wed, 25 Feb 2009 10:12:14 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <20090223.204109.9421.3@webmail20.vgs.untd.com> <49A352FD.20908@gmail.com> <586791.64322.qm@web59104.mail.re1.yahoo.com> <49A36CA1.70607@gmail.com> In-Reply-To: <49A36CA1.70607@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: [mmox] What's in a name? Was: Re: mmox Digest, Vol 1, Issue 113 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:11:54 -0000 Jon Watte wrote: > Ann Otoole wrote: >> **Jon will now "rez" a prim that has a script in it and then click >> the prim to cause the script to trigger it's on_touch() event. >> Jon will now instantiate a 3D mesh, apply a texture bake, and then >> invoke it's methods to... >> >> Same thing. > > Once you know the intended meaning of the word, right. > > To quote a recent internal discussion from OLIVE world: "When the > dobrepo sobs the thob, the foreman will activate schema based on path > bindings to DPM props." > > Yes, every word there has a specific and clear meaning to those who > work with the OLIVE SDK, but I try to avoid using that kind of > language in the external world. I'm not for or against specific words, > but I am for clear and unequivocal communication, and if the target > audience is unknown, a dictionary tends to be a good starting point. > > And btw: it's not a "grid," it's a "world instance" running on a > "cluster" :-) > > Sincerely, > > jw > The AWG debated the use of grid for a while. Its obviously SL-centric since few other platforms have nice neat rectangular grids of simulators. Your terminology is better I think; although, since SL simulators can form contiguous "land masses" it's not quite accurate either. A "world graph" just doesn't have the right feel... L From infinity@lindenlab.com Wed Feb 25 09:33:09 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91F3E28C16F for ; Wed, 25 Feb 2009 09:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HoZcS6Xx8p0 for ; Wed, 25 Feb 2009 09:33:08 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 9197C28C15D for ; Wed, 25 Feb 2009 09:33:08 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 405603DBC066; Wed, 25 Feb 2009 09:33:29 -0800 (PST) Message-Id: <8F8A1224-A2E1-4A3F-AA19-80F19CCE6071@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Catherine Pfeffer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 09:33:29 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] tags X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:33:09 -0000 so. again. let me reiterate the issues we have with "the XML way." first off, XML is for us, not a first order representational system. we do this because: * we have an external requirement to expose a JSON interface and an internal requirement to export a Binary interface. * we have an internal requirement to not co-mingle application semantics and the presentation logic (this means we cannot have a system that requires us to deploy new XML to data structure parsers to our system components when new versions of PDUs are defined.) so in short, we would not deploy a protocol that mandated we abandon these requirements. that being said, i suspect at some point we will be discussing application layer objects (user, avatar, location, prim, texture, mesh, etc.) if there was an "XML way" PDU defined for each protocol interaction, i don't think we would care one whit as long as supporting it was not mandatory and application layer PDUs were defined in a way that allowed us to continue to use LLSD. to paraphrase... we think the "XML way" does not buy us anything. we respect that other people might have a different preference or set of requirements related to XML. but you have to respect that we're not going to abandon a key portion of what makes our architecture resilient in the face of version slew. so why not just agree to disagree about it, allow virtual world deployers make up their own minds about which presentation tier to adopt. i would also argue that if we could develop a mechanical scheme to convert between LLIDL and "the XML way" XML DTD, we could interoperate with such systems will less ambiguity. On Feb 25, 2009, at 4:48 AM, Catherine Pfeffer wrote: > Infinity said: > > about sizes of ints as attributes. > > > > let me pose the question... what is the difference in terms of > > processing expectations if one sends > > > > '12' > > > > vs. sending > > > > '12' ? > > Honestly, having a tag is so ... unusual in the XML world, > that I won't even attempt to answer this detail question and the > next ones. We should simply abandon the idea of having , > , and so on in the data flow. > > In a binary serialization, you need to say : the next four bytes > will be an integer. Or the next 25 bytes will be a 25-bytes long > string. Fine. But there is *no* reason to do the same in an XML > file. The angle brackets < > or the quotes " " are delimiters. They > tell you where the data starts and where it ends, so there is no > need to say it an integer or whatever else. > > When you want to pass a key-value pair like > Taper_X = 0.5 > then if we want to stick to XML paradigm, it should be a > ... Taper_X="0.5" ... > attribute of some prim-related tag (14 bytes), and not > ... > Taper_X > 0.5 > ... > in some (36 bytes plus the whitespace). > > The quotes " " tell where "0.5" starts and where it ends. The > information "Taper_X is a float" belongs to the XML schema or DTD, > not to the data sent over the wire. > > What I am trying to say is that the current xxSD XML serialization > might look like XML, but it definitely belongs to another world from > a conceptual point of view. It's like Canada Dry, it looks like > beer, but it's no beer. > > What you have come up with is just a rewriting of the binary > serialization that is well-formed XML. That does not make it > something that fits naturally into XML: > - LLIDL plays the same role as XML schemas or DTDs and could simply > be dropped. > - currently, accessing the value of Taper_X from XPath is > convoluted and probably slow, compare: > map/key[. = 'Taper_X']/following-sibling::float[position() = 1] > with: > @Taper_X > - I also already mentioned the higher (250%) bandwidth footprint > - etc > > What is the point of having a XML serialization just to have it > "look like" some XML, while it's not really XML? > > > OK, let's try to be positive (for once ;-) ): > > I am currently wondering if there is not an automated way to map the > LLSD abstract view into a real XML-ish serialization. Perhaps that > would make everyone happy. That would keep the very high flexibility > of LLSD, have a lower angle bracket tax, and allow "natural" use of > all XML tools. That would keep the possibility of having three > different serializations, even though I still think that it's a > false good idea. > > The technical problem I see with this approach is that the current > LLSD draft does not recognize the special role played by the maps in > storing name-value pairs used by the upper layers. It does not > either say that arrays are made for vectors and quaternions, and so > on. There is a lot of semantics that are evacuated from this draft > and that I only know for having worked with SL client source code as > an Open Source contributor. And I don't see how I could specify such > an "intelligent" XML serialization if such context information is > missing. > > (I apologize in advance if this context information is in the LLSD > draft and I did not see it.) > > -- > Cathy > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From wjgeorge@dceo.rutgers.edu Wed Feb 25 09:41:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 562C028C25E for ; Wed, 25 Feb 2009 09:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdU09tXrY5hV for ; Wed, 25 Feb 2009 09:41:06 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 8BBD428C1D3 for ; Wed, 25 Feb 2009 09:41:06 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so152762ywh.49 for ; Wed, 25 Feb 2009 09:41:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.173.18 with SMTP id v18mr720101ane.20.1235583686034; Wed, 25 Feb 2009 09:41:26 -0800 (PST) In-Reply-To: References: <27a487810902231225l6698b519rdc6f1d53ba215024@mail.gmail.com> <61dbdd7d0902232240v7be93f0dpd6310ecd7db0902a@mail.gmail.com> Date: Wed, 25 Feb 2009 12:41:25 -0500 Message-ID: <27a487810902250941j53b20ec1h2d4edf30cef22a2d@mail.gmail.com> From: William George To: Morgaine Content-Type: multipart/alternative; boundary=0016e644cc2ab247740463c1be82 Cc: mmox@ietf.org Subject: Re: [mmox] Permissions (Gareth Nelson) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:41:07 -0000 --0016e644cc2ab247740463c1be82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Morgaine, Yes..but..my comment was in reference to the idea of permissions, mainly so I could buy a "no-mod" object, tack my mods on it, make it modifiable, but still protect the sub-assemblies' object creators intentions. SL has effectively disabled this aspect of the time honored yankee tradition of re-tasking objects for things they weren't orginally intended to do. My better mousetrap shouldn't need to be constructed from scratch. I'm guessing the the object hierachy as described will work well for the permission attributes of sub-assemblies. Waka --0016e644cc2ab247740463c1be82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Morgaine,

=A0 Yes..but..my comment was in reference to the idea of p= ermissions, mainly so I could buy a "no-mod" object, tack my mods= on it, make it modifiable, but still protect the sub-assemblies' objec= t creators intentions.

SL has effectively disabled this aspect of the time honored yankee trad= ition of re-tasking objects for things they weren't orginally intended = to do. My better mousetrap shouldn't need to be constructed from scratc= h.

I'm guessing the the object hierachy as described will work well fo= r the permission attributes of sub-assemblies.

Waka

=A0
--0016e644cc2ab247740463c1be82-- From infinity@lindenlab.com Wed Feb 25 09:43:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D0928C0D0 for ; Wed, 25 Feb 2009 09:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4nnH4ziP5ct for ; Wed, 25 Feb 2009 09:43:09 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 9211B3A68CB for ; Wed, 25 Feb 2009 09:43:09 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id C72343DBC063; Wed, 25 Feb 2009 09:43:29 -0800 (PST) Message-Id: <4939014F-5D7C-4728-A191-0606CC577EA2@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Catherine Pfeffer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 09:43:29 -0800 References: X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Conversions in an heterogeneous grid X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:43:10 -0000 there are no conversions between date and integer in the current draft of LLSD. On Feb 25, 2009, at 5:13 AM, Catherine Pfeffer wrote: > Infinity wrote: > > > > 13 > > 2008-12-15T13:17:23.235Z > > 93 > > 161 > > > > Now consider : > foo="13" > bar="2008-12-15T13:17:23.235Z" > baz="93" > qux="161" /> > > Nothing prevents you here from converting 2008-12-15T13:17:23.235Z > into an integer percentage (zero) using the same conversion rules > that are currently in the LLSD specification (you get expected and > sent types from the schemas), or even, which is simpler, by using a > "any-string to integer" conversion. > > -- > Cathy > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From eh2th-mmox@yahoo.com Wed Feb 25 09:52:42 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B1C3A6973 for ; Wed, 25 Feb 2009 09:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th6iGbptjQjI for ; Wed, 25 Feb 2009 09:52:42 -0800 (PST) Received: from web65704.mail.ac4.yahoo.com (web65704.mail.ac4.yahoo.com [76.13.9.96]) by core3.amsl.com (Postfix) with SMTP id D5C133A696D for ; Wed, 25 Feb 2009 09:52:41 -0800 (PST) Received: (qmail 46513 invoked by uid 60001); 25 Feb 2009 17:53:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=iG/eYyViDH6/1ALoVyjBlyjVB3TQjSYkEG83yVpZUBV5O5OGHAtVQWRtF/pPF33HZHleBXltr9SPLYHowhb2ZlrQIiZsJQIW5IwmGgd91Hmpe9LD2YI02ty8hd0umBfxnvXqeRmsRFCQ1iU6uokf17lXl0VS381b3oCs1ji9ml0=; X-YMail-OSG: WB3abj8VM1kt9lWWe9tkbeEouiuwb0LDvhoyli4Xbai0nXhirtNXPvH67XG8a.bnYcjYKJg9NxOIz5.z.IMA0i1cR.OmggVK0EF0rNeCeOajP8Xo9RGkZKjr.dlk74hC8vc0IB32ZhYrTLNu1j39LCrjPK_td2RlgWKrZtqPZZ80HXO2rBFK0f.Eud89hmiuDtU_WSUcl06WUIvD8zqeD73izQ-- Received: from [72.220.236.152] by web65704.mail.ac4.yahoo.com via HTTP; Wed, 25 Feb 2009 09:53:00 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: Date: Wed, 25 Feb 2009 09:53:00 -0800 (PST) From: eh2th-mmox@yahoo.com To: Catherine Pfeffer , mmox@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1213321900-1235584380=:46278" Message-ID: <282639.46278.qm@web65704.mail.ac4.yahoo.com> Subject: Re: [mmox] XML way loosely typed? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 17:52:42 -0000 --0-1213321900-1235584380=:46278 Content-Type: text/plain; charset=us-ascii thanks, it wasnt clear to me that this example was dependant on a schema. --Tom ________________________________ From: Catherine Pfeffer To: mmox@ietf.org Sent: Wednesday, February 25, 2009 4:51:53 AM Subject: [mmox] XML way loosely typed? Tom wrote: > Apologies if I missed the answer if it was in an earlier message... > > The "XML way" message appears to be loosly typed. How could a parser create an object from that > XML data and know the difference between an integer and a float, or a UUID and a string? >From the associated schema. The schema is the place where you usually declare the data types in the XML world. -- Cathy --0-1213321900-1235584380=:46278 Content-Type: text/html; charset=us-ascii
thanks, it wasnt clear to me that this example was dependant on a schema.

--Tom
From: Catherine Pfeffer <cathypfeffer@gmail.com>
To: mmox@ietf.org
Sent: Wednesday, February 25, 2009 4:51:53 AM
Subject: [mmox] XML way loosely typed?

Tom wrote:
> Apologies if I missed the answer if it was in an earlier message...
>
> The "XML way" message appears to be loosly typed. How could a parser create an object from that
> XML data and know the difference between an integer and a float, or a UUID and a string?

From the associated schema.

The schema is the place where you usually declare the data types in the XML world.

--
Cathy
--0-1213321900-1235584380=:46278-- From jwatte@gmail.com Wed Feb 25 11:00:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C988628C2C8 for ; Wed, 25 Feb 2009 11:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k6p4brWstbe for ; Wed, 25 Feb 2009 11:00:27 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id C4F7D28C2C5 for ; Wed, 25 Feb 2009 11:00:26 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so193032yxm.49 for ; Wed, 25 Feb 2009 11:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tMXzFs3MPVTKMJNk7OOPk01mdg3EZglWA3mkVygjrpI=; b=BsDJZshel0r1808EoriTJ3Pyyziq4Z+Z7TKFDCEmPiL1GYGyJy4ecFxlX/brrK/NY9 H6qml+h38Af8ukpUI7Xh05ICAzneGMkIsF0gFgRnNYy9vNCZWMCcXGGkKq4TNwkdIqcQ xeHHcfIRQq/A9/0FT5NFTmChGh4IgWdCW7erE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Spxxohhn9VP6F+rl8NKeXdRppYfkOeup47WZUklpz8TN4ZDO/wb7W+pUUKxc6YPxBv AhyTrSppj39bN1V3NHBXRUbh7M7RZsvAwL3qPsDyO5o/Cy2r0zGbzm6l0kSk63HsIXk+ uWj3T9M/LAGE1yX25icMVSbiq7x0DgKhlrV1g= Received: by 10.100.152.19 with SMTP id z19mr790847and.85.1235588446868; Wed, 25 Feb 2009 11:00:46 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c23sm299858ana.32.2009.02.25.11.00.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 11:00:45 -0800 (PST) Message-ID: <49A5955B.8000401@gmail.com> Date: Wed, 25 Feb 2009 11:00:43 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <1E712A17-6D23-471C-A827-CD86C1EDE59D@lindenlab.com> In-Reply-To: <1E712A17-6D23-471C-A827-CD86C1EDE59D@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Representing Number Types [Was: Re: Details proposal] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 19:00:27 -0000 Meadhbh Hamrick (Infinity) wrote: > let me pose the question... what is the difference in terms of > processing expectations if one sends > > '12' > > vs. sending > > '12' ? > If we go with a schema-based approach (where "schema" could refer to the xxSD source file, not necessarily an XSD or DTD), then you don't need to send the size for each field. Instead, the schema defines what the "internal" format is, and the size does not need to be sent. 12 > > what would happen if we just remove the bit width of number types from > the proposal all together? would that kill anyone? > I believe bit width is necessary for the schema, so that I can a priori determine whether I'm actually capable of handling the kind of data that someone might send to me. If the schema says "this is a 4096-bit int" and I don't deal with 4096-bit ints, I want to know that when establishing the connection or looking at the schema, not when I get an XML document with hundreds of digits in an "integer" value field. > assuming we can all find agreement that the machines we're using all > use 2's complement notation, the main difference between signed and > unsigned seems to be behavior when a right shift operation occurs. > There are transmission encoding problems with that, though, as you can't optimize the transmission length for small negative numbers (when sending binary). The Google protocol buffers format has that problem. The slight variation I proposed (that adds a sign bit and sends negative numbers in 1's complement) fixes that, at effectively no cost. Sincerely, jw From jwatte@gmail.com Wed Feb 25 11:03:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457DB3A6AF3 for ; Wed, 25 Feb 2009 11:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afnFS+Bily7z for ; Wed, 25 Feb 2009 11:03:39 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 62FEC3A6AC5 for ; Wed, 25 Feb 2009 11:03:39 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so194043ywh.49 for ; Wed, 25 Feb 2009 11:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=J+TNBx6Pf+6Y5D55SbFx5cqCGbHzUYS2KyBD9tDiQdI=; b=pcBjub2N1AW+6/U+vvw2LXuONkUBkM1qP1px047PcmPajap2OrOBsXl3XFVwOBcW4T oyaI5HpV+JtEAaTLDJgcihWL3LywspHiQlEqRbXaj0++E+sHNIijtMZISj1lqE/rcIQI 0W9fgVCTd9xcdg1t557EXTkkcSdGdR3TNUNuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=OLq0K7R7pnQIoFDbyjt9XN0zdeGSzs0QtgTPW4pIOcpOcMn1CVmylnRFIjeW3Qfey2 DWmIepTlP8WxTUTyaOmf6FAbH82q1vv8asGRgYha42sEmBR1/qR8d3O7leQTB+BwNheX lyoaLjUFPnO6PEL/RLoUzwAKXtdKe/glAsfLA= Received: by 10.100.190.14 with SMTP id n14mr838654anf.19.1235588638283; Wed, 25 Feb 2009 11:03:58 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b14sm8602120ana.16.2009.02.25.11.03.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 11:03:57 -0800 (PST) Message-ID: <49A5961B.3030308@gmail.com> Date: Wed, 25 Feb 2009 11:03:55 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Dan Olivares References: <49A4563A.5060008@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Compact Binary Serialization X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 19:03:40 -0000 Dan Olivares wrote: > might seem ok, however, consider what happens when someone in a locale > with a different way of displaying the number tries to figure out what > this means? > > That could be a non-problem. Define C locale, and you're done. And, btw, C locale does not use thousands grouping at all. Note that the schema is for machine data interchange (a user doesn't generally enter quats by hand :-). Sincerely, jw From infinity@lindenlab.com Wed Feb 25 11:08:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D257E3A6B04 for ; Wed, 25 Feb 2009 11:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvfRW9tUg58W for ; Wed, 25 Feb 2009 11:08:50 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 110863A6A9F for ; Wed, 25 Feb 2009 11:08:50 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id B6B203DBC063; Wed, 25 Feb 2009 11:09:10 -0800 (PST) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49A5955B.8000401@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 25 Feb 2009 11:09:10 -0800 References: <1E712A17-6D23-471C-A827-CD86C1EDE59D@lindenlab.com> <49A5955B.8000401@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Representing Number Types [Was: Re: Details proposal] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 19:08:50 -0000 yeah. i think the question i was eventually going to ask was.. a. do we need to define the size of integers in the specification? - or is it okay for me to say.. "if you connect to Second Life, i will insist that integers are 32 bits." and for OSGrid to say "if you connect to OSGrid, i will insist that integers are 64 bits." - cause for what it's worth, the JSON spec doesn't provide size limits for numbers, so we're going to be defining that "somewhere" for JSON. On Feb 25, 2009, at 11:00 AM, Jon Watte wrote: > Meadhbh Hamrick (Infinity) wrote: >> let me pose the question... what is the difference in terms of >> processing expectations if one sends >> >> '12' >> >> vs. sending >> >> '12' ? >> > > If we go with a schema-based approach (where "schema" could refer to > the xxSD source file, not necessarily an XSD or DTD), then you don't > need to send the size for each field. Instead, the schema defines > what the "internal" format is, and the size does not need to be sent. > > 12 > > >> >> what would happen if we just remove the bit width of number types >> from the proposal all together? would that kill anyone? >> > > I believe bit width is necessary for the schema, so that I can a > priori determine whether I'm actually capable of handling the kind > of data that someone might send to me. If the schema says "this is a > 4096-bit int" and I don't deal with 4096-bit ints, I want to know > that when establishing the connection or looking at the schema, not > when I get an XML document with hundreds of digits in an "integer" > value field. > > >> assuming we can all find agreement that the machines we're using >> all use 2's complement notation, the main difference between signed >> and unsigned seems to be behavior when a right shift operation >> occurs. >> > > There are transmission encoding problems with that, though, as you > can't optimize the transmission length for small negative numbers > (when sending binary). The Google protocol buffers format has that > problem. The slight variation I proposed (that adds a sign bit and > sends negative numbers in 1's complement) fixes that, at effectively > no cost. > > Sincerely, > > jw > From echeslack@gmail.com Wed Feb 25 11:19:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7DF28C28E for ; Wed, 25 Feb 2009 11:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDOZmatOh4Pu for ; Wed, 25 Feb 2009 11:19:39 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id BC5253A68EB for ; Wed, 25 Feb 2009 11:19:38 -0800 (PST) Received: by gxk22 with SMTP id 22so406586gxk.13 for ; Wed, 25 Feb 2009 11:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=3PU9zPs/EYjHsZD/Qk61ulYRSH2O16RGh25kSvq1XEU=; b=IeaAUTsRwiyX/sg02IuHWMgZhvcdtbJNsXyQeDqNzaQqR1kEuNYSp9WdeizZsH0bwX EuDFJ/oQMWhrAG6PqWzHg+fDrBQcxXZ00/iHDccyAPyBhLFU+EMTYpsoU3rj4ODpdlMF /2jsEFB5CxkT14+O05XXrIbVgTcUiNtRYKd0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mJDCGJpVhmwn7MdPqWb2QqQFQnAu0yAeIElqu1+mBTJ36XVIIPB2tOypNRfmxP291e n6V65BbAwDuYNuyftrjzfIDX4TOHikX0tKUkY7N6U5qldx3BQtKW5dKbV0zFX7Y/18PS tgqH6A84/q45VUdZZ2q7zYC+dsZPdm6709b7o= MIME-Version: 1.0 Sender: echeslack@gmail.com Received: by 10.151.112.10 with SMTP id p10mr250043ybm.191.1235589598118; Wed, 25 Feb 2009 11:19:58 -0800 (PST) In-Reply-To: <06CF9E4E-6C20-46CB-B092-68F702C2E185@lindenlab.com> References: <49A4A8FA.607@gmail.com> <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> <497C7FD9-BF36-458F-98C0-BEECAE611E1A@lindenlab.com> <06CF9E4E-6C20-46CB-B092-68F702C2E185@lindenlab.com> Date: Wed, 25 Feb 2009 11:19:58 -0800 X-Google-Sender-Auth: 6f7e87ced6ae902e Message-ID: From: Ewen Cheslack-Postava To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] The Structure and Interpretation of LLSD Messages [Was: Re: unefficient binary serialization ?] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 19:19:41 -0000 On Wed, Feb 25, 2009 at 9:10 AM, Meadhbh Hamrick (Infinity) wrote: > i'm relying on rusty neurons to make this assertion, but i think protocol > buffers will fail if you parse a message with an additional required memb= er. Required/optional is only specified in the IDL. Whether a field is required is not present in the wire protocol, so the receiving end would have no way to tell if the unknown field was required by the sending end. > > but this isn't that big of a deal since we like optional members in LLSD. > > but i'm also at a bit of a loss for figuring out how to represent variant > records with GPB. There's no general variant type, but its easy to build one for the receiving end. message Variant { } Everything included in it will simply be pushed to an UnknownFieldSet, and the complete structure will be maintained. However, variants are of debatable use at best. General variants really aren't that great because you can't rely on their content. I would think it would generally be better to actually specify the possible types of data: message Name { optional string string_name =3D 1; optional uint32 predefined_name =3D 2; } If you don't do this, you get stuck with extensibility problems. Suppose I used the Variant version and I wanted to now support specifying first and last name separately. The only information I have about the meaning of the variable is its data type, string. Now the old system gets a message with 2 strings (or 3 strings, if you also specify the whole name) in it and has no idea what to do or which to use. The best you can do is hope that the ordering is nice and take the first (or maybe the last? seeing the problem with this?). With pb you could just update it to be message Name { optional string string_name =3D 1; optional uint32 predefined_name =3D 2; optional string first_name =3D 3; optional string last_name =3D 4; } The multiple strings are not ambiguous. So long as new systems implementing this also specify the string_name parameter, then everything works fine between the two. If the updated system so desires, it could have rules to automatically generate first_name and last_name from string_name. > > which is to say, i'm sure it can be done and i'm pretty sure it "won't be > pretty" in the sense that to support variants, you may have to do things > that avoid using the innate structure representation of GPB. If you're referring to the fact that protocol buffers are strongly typed, then sure, you're avoiding the innate structure representation of protocol buffers. The point is they thought about this and provided the tools to handle this when you don't know the structure. Are you suggesting LLSD does something better in this regard? It seems to me that, by definition, you can't do anything better since you don't know the structure of the data. > > and at that point, unless google (or someone else) is opening up an LLSD > service, maybe the thing to do would be to have a protocol gateway that > takes LLSD style PDUs in one side and emits GPB messages out the other. I do appreciate the possibility of having a unified data type system with multiple serialization backends, which would allow for protocol gateways like that to be fairly trivially implemented. It would just be a decode->encode in new format. -Ewen > > On Feb 24, 2009, at 11:27 PM, Ewen Cheslack-Postava wrote: > >> Maybe I'm just overlooking something, but how is this a problem? =A0It >> looks like you added an enum and an optional field using that enum >> type to the PhoneNumber message type. =A0Why would the serialization >> engine would fail? =A0It ignores key value pairs it doesn't understand. >> The encoding provides sufficient type/size information to skip the >> field without understanding its contents. In fact, it will even >> collect those fields up and deliver them to you so you can try to use >> them. Protocol Buffers was designed (or probably more accurately, >> evolved) to support backwards and forwards compatibility. =A0This is >> especially critical for google because they do slow rollouts of >> updated services, so they, at a minimum, have to be compatible between >> consecutive versions of their protocols. >> >> That being said, you certainly do have to be careful about >> compatibility when updating a message type or creating a new message >> that might be upgraded in the future. =A0For instance, there are quite a >> few people who use optional by default so that its possible to remove >> fields if they are no longer necessary. =A0But this is true for all >> serializations, so I wouldn't count that as a negative mark against >> protocol buffers. =A0In fact, I'd say its an argument for it that it can >> handle it (as can LLSD, Thrift, XML, etc). >> >> -Ewen >> >> On Tue, Feb 24, 2009 at 11:06 PM, Meadhbh Hamrick (Infinity) >> wrote: >>> >>> imagine you have a .proto file like: >>> >>> message Person { >>> =A0required string name =3D 1; >>> =A0required int32 id =3D 2; >>> =A0optional string email =3D 3; >>> >>> =A0enum PhoneType { >>> =A0 MOBILE =3D 0; >>> =A0 HOME =3D 1; >>> =A0 WORK =3D 2; >>> =A0} >>> >>> =A0message PhoneNumber { >>> =A0 required string number =3D 1; >>> =A0 optional PhoneType type =3D 2 [default =3D HOME]; >>> =A0} >>> >>> =A0repeated PhoneNumber phone =3D 4; >>> } >>> >>> and the next rev of the protocol is: >>> >>> message Person { >>> =A0required string name =3D 1; >>> =A0required int32 id =3D 2; >>> =A0optional string email =3D 3; >>> >>> =A0enum PhoneType { >>> =A0 MOBILE =3D 0; >>> =A0 HOME =3D 1; >>> =A0 WORK =3D 2; >>> =A0} >>> >>> =A0enum PhoneUsage { >>> >>> =A0 VOICE =3D 0; >>> >>> =A0 FAX =3D 1; >>> >>> =A0 MODEM =3D 2; >>> >>> =A0} >>> =A0message PhoneNumber { >>> =A0 required string number =3D 1; >>> =A0 optional PhoneType type =3D 2 [default =3D HOME]; >>> >>> =A0 optional PhoneUsage type =3D 3 [default =3D VOICE]; >>> =A0} >>> >>> =A0repeated PhoneNumber phone =3D 4; >>> } >>> >>> the problem is that if a endpoint expecting the former consumes the >>> latter, >>> the serialization engine barfs. and you (in the application layer) don'= t >>> receive the message in order to try to pick it apart manually (which ki= nd >>> of >>> defeats the purpose of the serialization.) >>> however, it _is_ an open source project, so we could probably create a >>> version of the library that adds a "fail silently" mode. >>> there are also semantics for extending messages, so maybe.. i'd have to >>> look >>> at it a little more before passing judgement. >>> >>> On Feb 24, 2009, at 10:45 PM, Morgaine wrote: >>> >>> Excellent background on LLSD, Infinity! =A0It raises a question: >>> >>> On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) >>> wrote: >>> >>> while we have a metric tonne of code that uses the existing LLSD DTD, >>> ultimately, any additional serialization format that preserves these >>> processing expectations could be wedged into the system. serialization >>> formats that did not support these processing expectations would cause >>> considerable heart burn. >>> >>> >>> One serialization format that many have mentioned here is Google's >>> Protocol >>> Buffers. =A0While I have barely started to examine PB myself, it is ver= y >>> clear >>> that this serialization is extraordinarily efficient on-the-wire and al= so >>> at >>> both ends of the wire, as well as catering for the continual change tha= t >>> is >>> inherent in large, evolving systems. =A0A interest in extending the 3-w= ay >>> serialization of XXSD to Protocol Buffers follows naturally. >>> >>> The question that is raised by the quoted paragraph is whether Protocol >>> Buffers "preserves these processing expectations". =A0If it does then >>> extending the set of serializations to PB is work that could be done by >>> those interested in it, as an open project, and picked up by other user= s >>> of >>> XXSD if they wish. =A0Potentially, the acceleration could be quite >>> significant, and hence the benefit to Limited Capability Clients very >>> important. >>> >>> On the other hand, if it does not "preserve these processing >>> expectations" >>> then there could be a problem. >>> >>> Do Lindens (or anyone else here) have any insight on this? >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) >>> wrote: >>> but here's one reason we like LLSD... >>> >>> imagine you have two systems that are interoperating... one is owned my >>> me, >>> the other is owned by catherine. >>> >>> cathy's customers are all banks and insurance companies and are very >>> conservative, so cathy want's to err on the side of caution in terms of >>> when >>> she deploys new features. >>> >>> i on the other hand throw caution to the wind because my customers are >>> all >>> first person shooter fanatics between the ages of 13 and 21 who demand >>> the >>> latest features as soon as possible (otherwise they use david's server) >>> >>> it's not hard to see we're eventually going to introduce version slew >>> which >>> will make it difficult for cathy and i to participate in the unregulate= d >>> business of marketing virtual life insurance policies to my customers. = in >>> this example, i'm trying to point out that the both the option to retai= n >>> version parity with cathy and the option to upgrade to the latest versi= on >>> are not without drawbacks. >>> >>> now.. imagine we have a PDU with three members while the second version >>> adds >>> a member. for simplicity's sake, let's say they're all integers. >>> >>> if used the DTD to define the validation for the message, the first >>> version >>> of the message might look like: >>> >>> >>> >> 1.0//EN" "http://example.com/pdu/1.0/pdutastic.dtd"> >>> >>> =A013 >>> =A042 >>> =A093 >>> >>> >>> while the new version would look like this: >>> >>> >>> >> 1.1//EN" "http://example.com/pdu/1.1/pdutastic.dtd"> >>> >>> =A013 >>> =A042 >>> =A093 >>> =A0161 >>> >>> >>> so when i (expecting the new version) consume the old version, i do not >>> see >>> qux. but my parser doesn't complain because instead of the DTD of the n= ew >>> PDU, i see a reference to the old PDU and say to myself... "it's okay..= . >>> it's just an older version," and i do whatever i have to do to continue >>> processing in the absence of the qux member i was expecting. even if i'= m >>> doing validation, it's okay, i'm pulling the DTD from the old definitio= n, >>> so >>> we're cool. >>> >>> now... when cathy consumes the new PDU, something similar happens. she >>> see's >>> a DTD she's not familiar with, but it's all good.. she grabs teh DTD fr= om >>> URL specified in teh DOCTYPE and moves on with her life, hoping that ne= w >>> version PDU didn't change the semantics of the three values (foo, bar a= nd >>> baz) she's familiar with. >>> >>> and then one day she receives this from david: >>> >>> >>> >> 1.2//EN" "http://example.com/pdu/1.2/pdutastic.dtd"> >>> >>> =A013 >>> =A02008-12-15T13:17:23.235Z >>> =A093 >>> =A0161 >>> >>> >>> aha! david, trying to steal my core demographic away from me has upgrad= ed >>> to >>> the most recent beta version of the software (now with 13% more >>> explosions) >>> >>> but this is now a serious problem for cathy. the "shape" of the >>> structured >>> data now does not match. what does she do? how does she convert that da= te >>> into an integer? >>> >>> and this is the question we keep running into as we deploy "loosely >>> coupled" >>> systems. how do we fail gracefully and ensure robustness in the presenc= e >>> of >>> PDU schema mismatches? >>> >>> the way linden answered this question was to develop LLSD, an abstract >>> type >>> system with conversions and defaults. >>> >>> the way we would probably have defined the message above would have bee= n >>> something like: >>> >>> >>> >>> =A0 >>> =A0 foo >>> =A0 13 >>> =A0 bar >>> =A0 2008-12-15T13:17:23.235Z >>> =A0 baz >>> =A0 93 >>> =A0 qux >>> =A0 161 >>> =A0 >>> >>> >>> we don't include the doctype id 'cause our DTD never changes. in this >>> example the LLSD message is shorter 'cause we don't include the DOCTYPE >>> id, >>> but even after removing the DOCTYPE id and changing the outer element t= o >>> llsd, the compressed version of the LLSD message is only seven bytes >>> larger. >>> (an increase from 154 bytes to 161 bytes, an efficiency loss of 4.5%) >>> however, i can guarantee you that it took a lot less time to code the >>> parser >>> because.. well.. we already had =A0a parser that knew how to unwrap LLS= D >>> messages. >>> >>> but we haven't got to the interesting part yet. >>> >>> there is a processing expectation with LLSD. we assume we're >>> de-serializing >>> a message into a dynamic language like ECMAScript or Python. For >>> languages >>> like C++ and Java we create a class that emulates this feature. so.. al= l >>> LLSD PDUs are de-serialized into these LLSD objects, and inside our >>> application(s), it's these objects that get passed around. so we might >>> have >>> code that looks like: >>> >>> public foo ( string message ) { >>> =A0 =A0 =A0 LLSD llsd; >>> >>> =A0 =A0 =A0 llsd =3D LLSD.From( message, LLSD.XML_SERIALIZATION ); >>> >>> =A0 =A0 =A0 System.err.println( "hey! foo was %d.\n", (int) llsd.at( "f= oo" >>> ).asInteger() ); >>> >>> =A0 =A0 =A0 if( ( (int) llsd.at("bar").asInteger() > 100 ) || ( (int) >>> llsd.at("bar").asInteger() < 0 ) ) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 System.err.println( "bar is not a percentag= e\n" ); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 System.haltAndCatchFire(); >>> =A0 =A0 =A0 } >>> >>> >>> =A0 =A0 =A0 if( (int) llsd.at("bar").asInteger() < 40 ) { >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 System.err.println( "sorry, this percent ma= rgin is way too >>> small for me to be interested.\n" ); >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 System.haltAndCatchFire(); >>> =A0 =A0 =A0 } >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 . >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 . >>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 . >>> } >>> >>> forgive the javaisms, the alternative was smalltalk and well... let's n= ot >>> go >>> there. >>> >>> for the sake of argument let's say we had already determined it was in >>> XML >>> format by looking at the Content-Type: header from the request. >>> >>> so what we're doing here is not out of the ordinary... we create an >>> instance >>> of the LLSD class from the serialization. >>> >>> and we print some logging messages. >>> >>> and we then try to see if bar is between 0 an 100. >>> >>> but the object representing "foo" is a date, not an integer. what >>> happens? >>> >>> in our current implementation of LLSD, we attempt to convert, but notic= e >>> that the conversion from date to integer has no semantic meaning. >>> =A0because >>> the conversion is "illegal," the default value is returned. >>> >>> the result of running this fragment would be something like >>> >>> =A0 =A0 =A0 hey! foo was 0. >>> =A0 =A0 =A0 sorry, this percent margin is way too small for me to be >>> interested. >>> >>> the important feature here is that we did not allow the "presentation >>> layer" >>> to create an error. we did the best we could to interpret the sense of >>> the >>> message, even to the point of making a nonsensical conversion. we allow >>> this >>> to happen because we assume that at the application layer, we're going = to >>> do >>> parameter checking. so the reasoning was... if we're going to be doing >>> parameter checking anyway, why would we want to allow the presentation >>> layer >>> to fail a message that would have generated a result that could be >>> checked >>> at the application layer? >>> >>> i hope you've enjoyed this installment of "the structure and >>> interpretation >>> of LLSD messages." and i hope it helps explain our motivations for >>> designing >>> LLSD and it's serializations the way we did... and while we have a metr= ic >>> tonne of code that uses the existing LLSD DTD, ultimately, any addition= al >>> serialization format that preserves these processing expectations could >>> be >>> wedged into the system. serialization formats that did not support thes= e >>> processing expectations would cause considerable heart burn. >>> >>> -cheers >>> -meadhbh >>> >>> On Feb 24, 2009, at 6:12 PM, Jon Watte wrote: >>> >>> Catherine Pfeffer wrote: >>> That's precisely all the HUGE strength of LLSD. Having information abou= t >>> what the data is intermingled with the data itself makes it very flexib= le >>> and future-proof. >>> But that is simply not necessary. If you transmit a reference to the >>> schema >>> you use when you initiate connection, then all future transmissions >>> during >>> that connection session can use the knowledge of that schema to highly >>> optimize traffic. Network traffic is actually one of the scarce resourc= es >>> when you start scaling up really large virtual worlds. There are cases >>> where >>> an entire office (20 people or more) share a single T1 connection to th= e >>> Internet, and expect to have a good virtual world experience for multip= le >>> users at the same time. >>> >>> >>> Honestly, here, the bandwidth is not lost, compared to the advantages. >>> >>> >>> I think it is, because the size difference is quite significant. >>> >>> In summary, their binary serialization is as flexible as XML data. >>> Perhaps >>> I'm wrong, but to me it's an unique case in all computer science of a >>> binary >>> format that would be so flexible. >>> >>> Don't overextend yourself :-) AIFF/RIFF has pretty much the same >>> flexibility, as does TLV (also used in OSCAR), a number of "binary XML" >>> proposals, and a number of protocols that have all done more or less th= e >>> same thing ever since computers were interconnected on a larger scale i= n >>> the >>> '80s. >>> >>> Sincerely, >>> >>> jw >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >>> > > From jwatte@gmail.com Wed Feb 25 11:20:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484E428C2B0 for ; Wed, 25 Feb 2009 11:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ4tGpaUsKal for ; Wed, 25 Feb 2009 11:20:03 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 4E4CB28C2AC for ; Wed, 25 Feb 2009 11:20:03 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so202549yxm.49 for ; Wed, 25 Feb 2009 11:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2jBzpoWZz5cN0ZqQ0Kq3gcqpHRBlT/xYL9nIWKWFsf8=; b=f861yNqf0mkwGKXSx7o33UIS2REBrBcVULWJwDUSCZvVf0rtqMyk9XWiEWoHXaVBiQ mkqcegONLvNQXI1huaKg9iG3KAilz7ozGdcMMCd8CEMLfXaa+5hOOeWfhKzWmhcpaHFL vJbm6KUgnmgh66OncJlBywkLxlyMui0VDQNuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=x508VC1BpfUtHQNHsVC4yGWQ6gTEel5C5BxXb8V7G03sz65VTNAl9auHHIaf3q8F4Y pL3MjB2jbMBgVUIo5Uw8o+H5HAny69WwmGN2N1HH70NTEAQCnwLLoiyhpsl481eedEy3 zkLYxMjm+wBg2TNR+QYMn0a8LM9+F1t1X4ys4= Received: by 10.100.142.4 with SMTP id p4mr856468and.23.1235589622597; Wed, 25 Feb 2009 11:20:22 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c1sm9097321ana.0.2009.02.25.11.20.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 11:20:22 -0800 (PST) Message-ID: <49A599F4.3020908@gmail.com> Date: Wed, 25 Feb 2009 11:20:20 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <1E712A17-6D23-471C-A827-CD86C1EDE59D@lindenlab.com> <49A5955B.8000401@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Representing Number Types [Was: Re: Details proposal] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 19:20:04 -0000 Meadhbh Hamrick (Infinity) wrote: > - or is it okay for me to say.. "if you connect to Second Life, i > will insist that integers are 32 bits." and for OSGrid to say "if you > connect to OSGrid, i will insist that integers are 64 bits." I don't think that's smart, because sometimes an integer value only needs to be one byte. In OLIVE we specify integers with a bit-precision representation -- a 13-bit int is nothing special to us. Our internal IDL compiles to structures that arrange and pad integers based on declared size. We don't do integers bigger than 64 bits, though. I'm prepared to relax this to 'integers are one of the basic types' (8, 16, 32 or 64 bits, signed or unsigned) for purposes of interoperability, but I think that specifying integer ranges in the declaration of messages is necessary, or you'll have to treat every integer field as possibly being the worst case (64 bits signed). Sincerely, jw From jwatte@gmail.com Wed Feb 25 11:34:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FE03A6A3F for ; Wed, 25 Feb 2009 11:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX1XDgvLc+hq for ; Wed, 25 Feb 2009 11:34:37 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 3C0633A6923 for ; Wed, 25 Feb 2009 11:34:37 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so208778ywh.49 for ; Wed, 25 Feb 2009 11:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=mox/6aIqSoMuFnPA6fzZOJ8+6YXDaa/fTdTXkE1PzfA=; b=yFW+HijxFMp9jKs5z8wyyMf01hKC+/9zv3MleFABbZS9JHP2fn0zebt71L0cngObWc rP5GTsaYz+DYIgxbegAUpPzkHLVsF1PazyBcBHt1xjOSGLnTt4h5I1VJ0j2O/nfqQiIX mTyx0CkJS7DIlZWvfnLRYo1dWp9LS27W/7ruw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=igC9ZlTbC8tL/5RledrzL8Bq/C1XKiCKNUgIXF9eVViYK+f871m1YYsWHfSWsrRfBj vDpOi0Re22BRgd6hpUG+DWpPDGfO/826u191VNS7DuIM/YAlg4sVGSjXctVXxDsKF6WP xq5CRAGf3uccU3Bb3+gSM7ZhGaRgYOY7g0x04= Received: by 10.100.32.6 with SMTP id f6mr826254anf.90.1235590489491; Wed, 25 Feb 2009 11:34:49 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d35sm6010055and.58.2009.02.25.11.34.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 11:34:48 -0800 (PST) Message-ID: <49A59D55.8080507@gmail.com> Date: Wed, 25 Feb 2009 11:34:45 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] Use cases X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 19:34:48 -0000 Yesterday, I posted three possible use cases, but I haven't heard any responses. Perhaps it got lost on the way to the list (I don't generally get my own posts back, even though I've tried to configure that in Mailman). Today, I added another two use cases, for a total of five persuasive use cases for virtual world interoperability. You can find them at http://www.interopworld.org/mmox-use-cases, or you can just read the following: The use cases, in brief, are: 1. *Friend Invite* -- you invite me to come visit you in your virtual world, when I'm currently in another world. 2. *Collaborative Training* -- two organizations with different virtual world technologies can collaborate on a defined scenario. 3. *Scene Transfer* -- I can export content that I have rights to from one virtual world, and load as much as possible into another virtual world. 4. *Analysis* -- I can purchase or create a tool that does automatic analysis of events in a virtual world, and hook it up to any world/s I have permission to do it. 5. *Data Logger* -- I can record the events and interactions of a virtual world where I have permission to do it, and later provide that data as a playback (a la YouTube) for anyone to experience "read-only." We are doing 2..5 in OLIVE already, but obviously only within the OLIVE technology domain. A large part of my interest in this field is to be able to do 1..5 across a wide variety of worlds. *Use case "Friend Invite"* 1. User A uses virtual world system A that complies with MMOX simulation interoperability. 2. User B uses virtual world system B that complies with MMOX simulation interoperability. 3. User A wants user B to visit him/her in system/world A, and gets a suitable URL from his/her system (A), and sends this to user B using any transport (mail, IM, integrated communication, carrier pigeon, ...) 4. User B clicks/activates this link. 5. After a brief "loading" screen, user B sees user A in user A's environment, including a representative form of any simulated object in that environment. 6. User B can interact at some level with the objects from user A. 7. Objects that user B take out of inventory show up in some representative form for both user A and user B. 8. User A can interact at some level with any objects that user B bring out of inventory. *Use case "Collaborative Training"* 1. Company A operates a chemical plant in city B. Company A uses virtual world system A to do simulation/training/command-and-control of its plant. 2. City B has an emergency response organization that uses virtual world system B for training and scenario planning. 3. At a defined time, company A and city B agree to connect their worlds for a defined duration to conduct a training excercise related to a fire in the chemical plant. 4. At the defined time, a representation of the detailed model/simulation of the chemical plant shows up at the right address in the virutal world for the city workers. 5. At the defined time, city workers (ambulances, fire trucks, etc) become visible to the chemical plant workers. 6. Interactions between users of the systems include conversations (voice, simulated radio, PSTN). 7. Interactions between users of the systems include a display of the fire as it propagates based on company A simulation models. 8. Interactions between users of the systems include the ability for firefighters to pour water (or other agents) onto the fire, and have the simulation respond. 9. Interactions between users of the systems include the ability for city workers to load a chemical plant worker into a city ambulance. 10. At the pre-determined time, the interoperability ends; the city disappears from the company plant, and the company plant disappears from the city model. 11. Session record/review capability used by the city in virtual world B includes all communications and interactions made in the system including those internal to company/world A. *Use case "Scene Transfer"* 1. A user of virtual world A has prototyped an interesting environment. 2. The user decides to donate that prototype to an organization that uses virtual world system B. 3. The user "exports" his/her prototype to a series of common data containers (textures, meshes, scripts, etc) of some standard format (e g COLLADA, X, FLT). 4. All content that the user has created and owns (no matter what the permission) that is part of the prototype is included in sufficient detail in the export. 5. All content that has "free view/derive" permission that is part of the prototype is included in sufficient detail in the export. 6. No content that is not created-and-owned by the user, and that does not have "free view/derive" permissions, is included in the export, although a reference saying "an object with characteristics C named N was here" may be. 7. The exported data is attributed (in aggregate) to user A. 8. Organization B can load the exported assets into their virtual world. 9. Meshes and textures in a well-known standard format shows up in world B as expected, with attribution to user A, no matter what technology the respective virtual worlds use. 10. Scripting and interactive behavior shows up only if the destination virtual world implements a scripting or behavior system compatible with the source world. *Use case "Analysis"* 1. ISV A creates a system for analyzing movement of avatars in a virtual world 2. The product from ISV A can be connected to any virtual world or worlds implementing interoperability. 3. When the tool is connected, certain patterns of movement are detected and flagged by the tool. 4. The tool can report recognized actions through chat, or through introducing "flag" objects into the world. 5. A virtual world user interacting with the "flag" objects can pull up a web page that gives information about the detected interaction *Use case "Data Logger"* 1. User of virtual world system A purchases a 'data logger' tool from company B. 2. When attaching the data logger tool to the virtual world, the data logger receives information about all the objects, interactions and communication in the system. 3. After the logger has been detached, the data logger tool can be seen as a separate "virtual world peer" and connected to by any virtual world using interoperability. 4. The logger implements play and shuttle controls that allow the action from the original session to be re-played at a later time. Any attached virtual world peer will see the recorded actions. 5. Enough data is available to the logger that search functions like "find the time when avatar X interacted with vehicle Y" can be implemented. 6. Actions by avatars in the connected peers during playback do not affect the objects provided by the logger tool. For purposes of these use cases, we can consider cases where "A" means "OpenSim" and "B" means "OLIVE," or use cases where "A" means Croquet and "B" means "Second Life," or "A" means Project Wonderland and "B" means "Multiverse.net" (although representatives from those two organizations are not yet on the list). From jwatte@gmail.com Wed Feb 25 11:49:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E7D528C2A4 for ; Wed, 25 Feb 2009 11:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u5KONIqTsxu for ; Wed, 25 Feb 2009 11:49:03 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 9316328C2CE for ; Wed, 25 Feb 2009 11:48:05 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so215345ywh.49 for ; Wed, 25 Feb 2009 11:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=K0lX3gkLa+H5szEIYtPgFweifLEut/ndyJY4fD+sC2Y=; b=FNSt2rD/FUiZxd4718xfRWwJqBaSguIvnpVPm6evFOR7vzFhnB0On0FjI6fH750W0Z z0/GawrgPBpjRmakpdjunyVh+gGaJgv86ziWu2t3R1fkjJr5nRoCUhUBikqhIrSIGpYY Pfdppid6XEaf8Gp+szNbdbFGtBsr6hUd4TH5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Cb6so8S/7S5QY4fT4mz+Rmt37NvDBqW8vDICg/MKQ1Lqthpa37xH5YJtnjmLl/2iO8 GsQW0ZT36ke+zlfPHeKxeKuyvU+MLqIG91havMamDeFYV3Lo1ZrGyuySuffjIjnaKlJW GZd9YnuTLUeHbAmaSOwVQZyN2lWYlfDVN6X8I= Received: by 10.100.163.8 with SMTP id l8mr815265ane.127.1235591305864; Wed, 25 Feb 2009 11:48:25 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d29sm3008987and.34.2009.02.25.11.48.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 11:48:25 -0800 (PST) Message-ID: <49A5A086.1050300@gmail.com> Date: Wed, 25 Feb 2009 11:48:22 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Even more compact binary serialization? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 19:49:04 -0000 Catherine Pfeffer wrote: > > Can you view a "xxSD" specification file as an alternative DTD? I e, > the > > output of a specific xxSD file could be one or more of the following: > If the question is "could we build a DTD or a schema to describe the > tags (, , etc.)", of course we could do it. That > would even be the whole point of all subsequent works in this mailing > list: describe the tags and their semantics to allow for virtual > worlds interoperability. > My question is not just to you, but to the list: We view the xxSD description language as a source language, from which we could compile various outputs. Could one of those outputs be a DTD and an XSD? Thus, we don't create the DTD or XSD directly; we create the mapping from xxSD input to DTD and XSD output. Btw, I forgot one other important case for using the xxSD source file: Systems that work on the data as abstract properties would likely parse the source file directly, and use it to understand the data, rather than trying to go through code gen. > > However, I think that you still haven't addressed one big concern, > which > > is the schema-dependent transmission format. Given your XML-ish version > > of a packet, in binary, it could look something like: > > Why would we need two serializations? > There are at least three serialization scenarios: 1) There is a persistent "session" connection. The connection/session is stateful and durable. This connection is likely to talk about the same object types many times, and is likely to send lots of updates to object property values. This session is real-time, interactive, and saving bytes is important. You can assume that the schema will not change while the session is connected. A binary format that wrings every last byte out of "knowing" the schema (which is established during up-front connection negotiation) is what's needed here. 2) There are non-persistent connections, REST-ful, transaction-based, request/response type interactions. Here, saving every byte is not as important. The schema may, theoretically, change between each request. I think the XML serialization is the right choice for this, although some people say they prefer JSON (mostly because that's easier to work with within HTML client-side code). 3) Persistent storage into database records, logs, etc. Here, the ability to reconstruct data that was created on earlier versions of schema is paramount. XML is one possible encoding (and certain databases, such as ORACLE, actually have specific XML support), whereas a more traditional approach would be a flexible, tagged binary format, such as IFF or the currently proposed LLSD binary serialization. > My point is, the current binary serialization is very good and could > be used unchanged (with a few data type additions). I would even call > it "binary XML" since it achieves the same goals of interoperability > and flexibility as XML ;-). And it does it with the same mechanism by > the way: by transporting both the data and the markup in one single file. > I disagree that the current binary representation is "very good" -- it is designed towards case 3, but because XML can solve case 3 just as well (using existing tool sets), I'm more interested in serving case 1. > But if we were to go for XML, then it should be real XML, and not a > "dummy" transposition of the very good binary serialization, because > the result does not match the paradigms behind XML, and is also very > inefficient from a bandwidth point of view. > I agree. I think that current practice within Linden Lab code (or, for that matter, OLIVE code) is not as important as getting this right for the general interoperability case. > Your binary serialization is very compact because it replaces a key > (like "Taper_X" or "NextOwnerMask") with a small number (like 384 or > 17). But the price to pay in terms of flexibility is also very high. > There is no flexibility price to pay, because those numbers are negotiated on a per-session basis. As long as the schema cannot change per session, and the mapping from number to semantic (property, tag) is re-built at the start of each session, there is no loss of generality or flexibility. I took some python code and moved it from approach 3 to approach 1, and it literally took less than a day. Compared to the bandwidth savings for all future interoperable virtual worlds network traffic, I think that's a good trade-off! > > As always, engineering is a matter of compromises. Given the high > number of data types implied, the speed of evolution of virtual > worlds, the huge dimensions of some grids, and the number and > heterogeneity of worlds to interconnect, I think we should pay a lot > of attention to flexibility, even though bandwidth concerns should not > be forgotten. > One additional point: In the protocol I have suggested, the requesting side subscribes to properties by container type, and the sending side will make sure to not send properties that are not interesting to the other side. This allows one side to introduce new data types, without the binary protocol breaking, because the receiving side will simply not subscribe to property identifiers for properties of types that are unknown to it. Sincerely, jw From SMEDDER@exchange.clemson.edu Wed Feb 25 11:58:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8093928C288 for ; Wed, 25 Feb 2009 11:58:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCYzasZ5IVG4 for ; Wed, 25 Feb 2009 11:58:11 -0800 (PST) Received: from smtp1.clemson.edu (smtp1.clemson.edu [130.127.235.21]) by core3.amsl.com (Postfix) with ESMTP id 9496428C188 for ; Wed, 25 Feb 2009 11:58:11 -0800 (PST) Received: from CUMAIL1.CAMPUS.CU.CLEMSON.EDU (backex-2.clemson.edu [130.127.9.165]) by smtp1.clemson.edu (8.14.3/8.14.3) with ESMTP id n1PJvhtR004109 for ; Wed, 25 Feb 2009 14:58:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C99783.4EE99EFF" Date: Wed, 25 Feb 2009 14:57:36 -0500 Message-ID: <49A223BC44ABD74CA49F799FBF27C1B7035B783C@CUMAIL1.CAMPUS.CU.CLEMSON.EDU> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Introductions Thread-Index: AcmXg04DqwPP6aB/RN63TrjhJd4eiA== From: "Suzanne B Medders" To: X-Proofpoint-SPF-Result: error X-Proofpoint-SPF-Record: N/A X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7400:2.4.4, 1.2.40, 4.0.166 definitions=2009-02-25_15:2009-02-10, 2009-02-25, 2009-02-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0811170000 definitions=main-0902250140 Subject: [mmox] Introductions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 19:58:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99783.4EE99EFF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm Suzie Medders in RL, Mirt Tenk in SL. I'm working on an edu vw network, been graciously assisted by others on this list, AW Groupies, etc. etc. My primary interest is enabling dev & sharing of vw content by higher edu around the world, been coordinating quite a bit w/Xugu Madison on that end. My concerns are security & single sign-on access for edu vw, as well as hosting w/in tight edu security constraints. ------_=_NextPart_001_01C99783.4EE99EFF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m Suzie Medders in RL, Mirt Tenk in SL. = I’m working on an edu vw network, been graciously assisted by others on this = list, AW Groupies, etc. etc. My primary interest is enabling dev & sharing = of vw content by higher edu around the world, been coordinating quite a bit = w/Xugu Madison on that end. My concerns are security & single sign-on = access for edu vw, as well as hosting w/in tight edu security = constraints.

------_=_NextPart_001_01C99783.4EE99EFF-- From lisa.dusseault@gmail.com Wed Feb 25 13:44:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129C63A68BC for ; Wed, 25 Feb 2009 13:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMzJ9Gsc0ZLr for ; Wed, 25 Feb 2009 13:44:37 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id 15F033A67FA for ; Wed, 25 Feb 2009 13:44:37 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so185376rvb.49 for ; Wed, 25 Feb 2009 13:44:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MMiEE3/JCdr3/VM0EOtzHBvY90+gCrg9Qiz3Ign6sUM=; b=DUSg63MZNqFV1oV1BhVTHLn26hHrwPVtG35TP4I1isprodnWCZoGHG7VEBDGTyJyMb NXdjWKIZUD5Zr/Lt9N4vqlmnCnoiSdGMFzRdieuUqiHi+NYnlmtTOUtS0RUm+QUrYTgg KZ2qYpA0Dw4MVRHND5oWse0I+ZheLftv5hv+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=O1fZ/VdkikwcUHZghocMxQ0z28ibMF6KiiiCsDSo9BVvV49+sMuRz9tQpS1KSEKomA 7m4VyKzkG5TqeTylR7VjYKYFO9iXG3+6keoQ6EecCd6wVKrFZ12E8h+GnaZ3NagwdPnw 0To0puB/dIe8V0eGgfKeA8XB1nadZA1Cv133o= MIME-Version: 1.0 Received: by 10.141.155.15 with SMTP id h15mr230552rvo.158.1235598297778; Wed, 25 Feb 2009 13:44:57 -0800 (PST) In-Reply-To: <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> References: <49A4A8FA.607@gmail.com> <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> Date: Wed, 25 Feb 2009 13:44:57 -0800 Message-ID: From: Lisa Dusseault To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org, Jon Watte Subject: Re: [mmox] The Structure and Interpretation of LLSD Messages [Was: Re: unefficient binary serialization ?] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 21:44:38 -0000 I really think this is a key difference between good design for an extensible single-party (or at least single-change-owner) protocol, and good design for an interoperable standard. The reason is that we want to shut down extensibility where it would hurt interoperability and backward-compatibility. The result of designing like this means that there are some ways you can't extend the standard; extensions are more limited in the creative ways they can be applied. IOW, the tradeoffs for extensibility are different in standards than for a protocol controlled by one host, e.g. Google PB. More inline: On Tue, Feb 24, 2009 at 9:41 PM, Meadhbh Hamrick (Infinity) wrote: > > ... > > now.. imagine we have a PDU with three members while the second version a= dds a member. for simplicity's sake, let's say they're all integers. > > if used the DTD to define the validation for the message, the first versi= on of the message might look like: > > > > > 13 > 42 > 93 > > > while the new version would look like this: > > > > > 13 > 42 > 93 > 161 > > > so when i (expecting the new version) consume the old version, i do not s= ee qux. but my parser doesn't complain because instead of the DTD of the ne= w PDU, i see a reference to the old PDU and say to myself... "it's okay... = it's just an older version," and i do whatever i have to do to continue pro= cessing in the absence of the qux member i was expecting. even if i'm doing= validation, it's okay, i'm pulling the DTD from the old definition, so we'= re cool. Excellent example, totally agree. > > now... when cathy consumes the new PDU, something similar happens. she se= e's a DTD she's not familiar with, but it's all good.. she grabs teh DTD fr= om URL specified in teh DOCTYPE and moves on with her life, hoping that new= version PDU didn't change the semantics of the three values (foo, bar and = baz) she's familiar with. > > and then one day she receives this from david: > > > > > 13 > 2008-12-15T13:17:23.235Z > 93 > 161 > > > but this is now a serious problem for cathy. the "shape" of the structure= d data now does not match. what does she do? how does she convert that date= into an integer? In a *standard*? Cathy does not. She flags an error. The standard that would have produced the interoperability so far in your example would have said "bar is an integer". In fact, if there's agreed interoperability between Cathy, Meadhbh and David on the foo, bar and baz semantics, then none of them need to be annotated with their datatypes. 13 2008-12-15T13:17:23.235Z 93 161 Result? Cathy returns an error because her XML handling looks like this: try: barval =3D int(xmldoc.getElementsByTagName('bar').data) except ValueError: return new ErrorResponse(400, "Bad Request") Whether there is a role for marking some things as "integer" types right in the protocol, I don't know. But if there's agreed semantics for an operation like "I would like to send you a user to rez with the following avatar information in the following location which may be valid in your world", then the location semantics are probably solid enough to do mostly by marking an integer as an integer in the specification, once and for all, rather than in every request. Lisa From dyerbrookme@juno.com Wed Feb 25 13:52:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D0F3A67C0 for ; Wed, 25 Feb 2009 13:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_05=-1.11, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UWtcUAjweN2 for ; Wed, 25 Feb 2009 13:52:54 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 8F1E73A67FA for ; Wed, 25 Feb 2009 13:52:54 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail11.vgs.untd.com [10.181.12.151]) by smtpout05.vgs.untd.com with SMTP id AABE4MRP5ARS5SF2 for (sender ); Wed, 25 Feb 2009 13:52:59 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkN2fYSsd8+UzJjapkWC1gd8A== Received: (from dyerbrookme@juno.com) by webmail11.vgs.untd.com (jqueuemail) id PAADUEBQ; Wed, 25 Feb 2009 13:52:18 PST Received: from [68.161.198.3] by webmail11.vgs.untd.com with HTTP: Wed, 25 Feb 2009 21:51:16 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Wed, 25 Feb 2009 21:51:16 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090225.165116.16880.0@webmail11.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 1:1:1913000827 X-MAIL-INFO: 27a961fd61d0d0c93165b1992460e400a0a444b0a595c0f09064e55920c96189495059 X-UNTD-Peer-Info: 10.181.12.151|webmail11.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 21:52:55 -0000 http://www.cybertechnews.org/?p=3D882&cpage=3D1#comment-180 So whose trees are those in the background? Who created them in which wo= rld, and were they copied into OpenSim if from Second Life? Also, when teleporting back and forth between worlds, are they taking at= tachments and inventory copies of everything they create or own in eithe= r world? ____________________________________________________________ Debt collectors calling your house? Click here to consolidate into one = payment. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIk3nqYhmn0hDKodbaoCoy= nGipppPdzynC097l2H4bJR6c1QjOOkQ/ From eh2th-mmox@yahoo.com Wed Feb 25 13:56:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732773A6AC7 for ; Wed, 25 Feb 2009 13:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id we4EkEMf2A0h for ; Wed, 25 Feb 2009 13:56:44 -0800 (PST) Received: from web65703.mail.ac4.yahoo.com (web65703.mail.ac4.yahoo.com [76.13.9.95]) by core3.amsl.com (Postfix) with SMTP id C3EBF3A68F0 for ; Wed, 25 Feb 2009 13:56:43 -0800 (PST) Received: (qmail 56248 invoked by uid 60001); 25 Feb 2009 21:57:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=s0czWelB2j2jVFrliV8iyU86+5z6+VUcslKXeVpu11iMg2I0p5mZhBMIvaoAWUVro75mkiBhquxKHN+RTUeB6ny+zpFvH53aaHIL0N4nviHDb2FJB1WdLmcddh/29KP0RTBft5fW/8ycLtspiKrZTIkWzJypk1r+JcuFKCSeQRc=; X-YMail-OSG: mCVLYR0VM1npgQOeTebKNzXefP6h4yWw.VvweDlvx1nIPxbEzou0CxAPN9FLapHuoJLUnmY5iWpuPsrNMRrZmZuQdBkzaKygkH83Z8ic2Icls1NmDJ8zMp58zUmE5OgctmOVwSsZFb.2KOWQA5ofWkBRgnYxSZKoVj3tGnlXuXKHZtF_t4fzR8wSyhbNPzruoWLmONzdWDIOQVPIwgdmmN29vA-- Received: from [72.220.236.152] by web65703.mail.ac4.yahoo.com via HTTP; Wed, 25 Feb 2009 13:57:04 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <49A59D55.8080507@gmail.com> Date: Wed, 25 Feb 2009 13:57:04 -0800 (PST) From: eh2th-mmox@yahoo.com To: Jon Watte , "mmox@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <299878.54638.qm@web65703.mail.ac4.yahoo.com> Subject: Re: [mmox] Use cases X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 21:56:45 -0000 Jon Watte wrote: "*Use case "Scene Transfer"* 1. A user of virtual world A has prototyped an interesting environment. 2. The user decides to donate that prototype to an organization that uses virtual world system B. 3. The user "exports" his/her prototype to a series of common data containers (textures, meshes, scripts, etc) of some standard format (e g COLLADA, X, FLT). 4. All content that the user has created and owns (no matter what the permission) that is part of the prototype is included in sufficient detail in the export." I realize these are only example hypothetical use cases, however, when I take off my developer hat and put on my content creator hat, I would prefer to see something more like the following: 4. All the content which is required by the licensee for *display* of the prototype in the targeted environment, and all content required to display the "freely distributed test drive" redistributed version of the prototype is included in sufficient detail in the export. 4.1 Additional content which may be required for modification of the prototype or for producing derivitive works may also be included as agreed upon between user A and the organization that uses virtual world system B. now back to the XML vs. LLSD debate ;) --Tom ----- Original Message ---- From: Jon Watte To: "mmox@ietf.org" Sent: Wednesday, February 25, 2009 11:34:45 AM Subject: [mmox] Use cases Yesterday, I posted three possible use cases, but I haven't heard any responses. Perhaps it got lost on the way to the list (I don't generally get my own posts back, even though I've tried to configure that in Mailman). Today, I added another two use cases, for a total of five persuasive use cases for virtual world interoperability. You can find them at http://www.interopworld.org/mmox-use-cases, or you can just read the following: The use cases, in brief, are: 1. *Friend Invite* -- you invite me to come visit you in your virtual world, when I'm currently in another world. 2. *Collaborative Training* -- two organizations with different virtual world technologies can collaborate on a defined scenario. 3. *Scene Transfer* -- I can export content that I have rights to from one virtual world, and load as much as possible into another virtual world. 4. *Analysis* -- I can purchase or create a tool that does automatic analysis of events in a virtual world, and hook it up to any world/s I have permission to do it. 5. *Data Logger* -- I can record the events and interactions of a virtual world where I have permission to do it, and later provide that data as a playback (a la YouTube) for anyone to experience "read-only." We are doing 2..5 in OLIVE already, but obviously only within the OLIVE technology domain. A large part of my interest in this field is to be able to do 1..5 across a wide variety of worlds. *Use case "Friend Invite"* 1. User A uses virtual world system A that complies with MMOX simulation interoperability. 2. User B uses virtual world system B that complies with MMOX simulation interoperability. 3. User A wants user B to visit him/her in system/world A, and gets a suitable URL from his/her system (A), and sends this to user B using any transport (mail, IM, integrated communication, carrier pigeon, ...) 4. User B clicks/activates this link. 5. After a brief "loading" screen, user B sees user A in user A's environment, including a representative form of any simulated object in that environment. 6. User B can interact at some level with the objects from user A. 7. Objects that user B take out of inventory show up in some representative form for both user A and user B. 8. User A can interact at some level with any objects that user B bring out of inventory. *Use case "Collaborative Training"* 1. Company A operates a chemical plant in city B. Company A uses virtual world system A to do simulation/training/command-and-control of its plant. 2. City B has an emergency response organization that uses virtual world system B for training and scenario planning. 3. At a defined time, company A and city B agree to connect their worlds for a defined duration to conduct a training excercise related to a fire in the chemical plant. 4. At the defined time, a representation of the detailed model/simulation of the chemical plant shows up at the right address in the virutal world for the city workers. 5. At the defined time, city workers (ambulances, fire trucks, etc) become visible to the chemical plant workers. 6. Interactions between users of the systems include conversations (voice, simulated radio, PSTN). 7. Interactions between users of the systems include a display of the fire as it propagates based on company A simulation models. 8. Interactions between users of the systems include the ability for firefighters to pour water (or other agents) onto the fire, and have the simulation respond. 9. Interactions between users of the systems include the ability for city workers to load a chemical plant worker into a city ambulance. 10. At the pre-determined time, the interoperability ends; the city disappears from the company plant, and the company plant disappears from the city model. 11. Session record/review capability used by the city in virtual world B includes all communications and interactions made in the system including those internal to company/world A. *Use case "Scene Transfer"* 1. A user of virtual world A has prototyped an interesting environment. 2. The user decides to donate that prototype to an organization that uses virtual world system B. 3. The user "exports" his/her prototype to a series of common data containers (textures, meshes, scripts, etc) of some standard format (e g COLLADA, X, FLT). 4. All content that the user has created and owns (no matter what the permission) that is part of the prototype is included in sufficient detail in the export. 5. All content that has "free view/derive" permission that is part of the prototype is included in sufficient detail in the export. 6. No content that is not created-and-owned by the user, and that does not have "free view/derive" permissions, is included in the export, although a reference saying "an object with characteristics C named N was here" may be. 7. The exported data is attributed (in aggregate) to user A. 8. Organization B can load the exported assets into their virtual world. 9. Meshes and textures in a well-known standard format shows up in world B as expected, with attribution to user A, no matter what technology the respective virtual worlds use. 10. Scripting and interactive behavior shows up only if the destination virtual world implements a scripting or behavior system compatible with the source world. *Use case "Analysis"* 1. ISV A creates a system for analyzing movement of avatars in a virtual world 2. The product from ISV A can be connected to any virtual world or worlds implementing interoperability. 3. When the tool is connected, certain patterns of movement are detected and flagged by the tool. 4. The tool can report recognized actions through chat, or through introducing "flag" objects into the world. 5. A virtual world user interacting with the "flag" objects can pull up a web page that gives information about the detected interaction *Use case "Data Logger"* 1. User of virtual world system A purchases a 'data logger' tool from company B. 2. When attaching the data logger tool to the virtual world, the data logger receives information about all the objects, interactions and communication in the system. 3. After the logger has been detached, the data logger tool can be seen as a separate "virtual world peer" and connected to by any virtual world using interoperability. 4. The logger implements play and shuttle controls that allow the action from the original session to be re-played at a later time. Any attached virtual world peer will see the recorded actions. 5. Enough data is available to the logger that search functions like "find the time when avatar X interacted with vehicle Y" can be implemented. 6. Actions by avatars in the connected peers during playback do not affect the objects provided by the logger tool. For purposes of these use cases, we can consider cases where "A" means "OpenSim" and "B" means "OLIVE," or use cases where "A" means Croquet and "B" means "Second Life," or "A" means Project Wonderland and "B" means "Multiverse.net" (although representatives from those two organizations are not yet on the list). _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox From dcolivares@gmail.com Wed Feb 25 14:05:28 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BCA43A6A3F for ; Wed, 25 Feb 2009 14:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWLr0k9-mT24 for ; Wed, 25 Feb 2009 14:05:27 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 0B2DC3A695E for ; Wed, 25 Feb 2009 14:05:26 -0800 (PST) Received: by fxm24 with SMTP id 24so215139fxm.37 for ; Wed, 25 Feb 2009 14:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=9zVQAxVlvwnGiduSq8dmwx/AgHBjx9a7HVLh4duIESA=; b=xikCEBdyFtSJ53hh1qzcRrPWv/xlorKGSEXC0q433uNJM7FHtzArELYQNLt99ff1Tt jr5P0xTqKcmPtQv5Hr+vyV1jDgkT6WZWm6f00M6T6+u9eRwmyLGBG10dxlxbTCYXagS0 1JLsFdFsKZcfAymrPCM9mURA/X7L2NgHCZGOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=DonN/8aaByqqzhaKQ12c414QKvG4XQMd0ZzAZLfMrYV/Z9Zf/4ewn36ECdVv4l0y3w uhSHrY921HHxtQw9FtX9I8faXbJ8sEDsWPgKrURMalL6ZnmWMsUV/2Dy3J8MeBW70Utz cQQ/oTxycfDfoDsjNSirUsOrPKdlVO8ydVzJE= MIME-Version: 1.0 Received: by 10.102.228.10 with SMTP id a10mr306433muh.26.1235599546943; Wed, 25 Feb 2009 14:05:46 -0800 (PST) In-Reply-To: <20090225.165116.16880.0@webmail11.vgs.untd.com> References: <20090225.165116.16880.0@webmail11.vgs.untd.com> Date: Wed, 25 Feb 2009 17:05:46 -0500 Message-ID: From: Dan Olivares To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:05:28 -0000 "So whose trees are those in the background? Who created them in which world, and were they copied into OpenSim if from Second Life?" Nobody, the trees are client side generated.. that means they're in the client and part of the multimedia included in the client. The client is GPL, with the content in the client licensed under the CC. The simulator says, "Hey!, render a pine tree here!", it doesn't say.. render a pine tree here, and use 'this texture' made by user 'x' "Also, when teleporting back and forth between worlds, are they taking attachments and inventory copies of everything they create or own in either world?" I don't know, you're going to need to contact Jani (Jani Pirkola ) or a realXtend representative to find out. Best Regards Daniel Olivares On Wed, Feb 25, 2009 at 4:51 PM, dyerbrookme@juno.com wrote: > http://www.cybertechnews.org/?p=3D882&cpage=3D1#comment-180 > > So whose trees are those in the background? Who created them in which wor= ld, and were they copied into OpenSim if from Second Life? > > Also, when teleporting back and forth between worlds, are they taking att= achments and inventory copies of everything they create or own in either wo= rld? > > ____________________________________________________________ > Debt collectors calling your house? =A0Click here to consolidate into one= payment. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIk3nqYhmn0hDKodbaoCoyn= GipppPdzynC097l2H4bJR6c1QjOOkQ/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From jwatte@gmail.com Wed Feb 25 14:05:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FD63A6A7D for ; Wed, 25 Feb 2009 14:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ifhrc52yq3ml for ; Wed, 25 Feb 2009 14:05:59 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id E81843A695E for ; Wed, 25 Feb 2009 14:05:58 -0800 (PST) Received: by gxk22 with SMTP id 22so572921gxk.13 for ; Wed, 25 Feb 2009 14:06:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=2PEsh3/656e00BzpQcL1ENRiNESqLy0MyidSLuHemcw=; b=D24SVstzZXiZul+5VAFm2aMonbtNAl584TeYurV535lJU5lIiiRJg891i+bVtPO3m9 WziBO8Sr2sW+DUILQ2zBDHkxK5uYIui+qzIS271SHT5Oj1LkqI/VXg0k7dgkM8QqDHDe BD3cUhZX1RHKr8orrlPr2rnQ6AobsTYRPxbM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fbqFMICKtSlJVID945y+h3/54zvaCFuuvNP5Iqeyzl7rM7yebjqTDFbzYyzo4QpSeZ 9itvRyhDiOmmEBaqyjOwpULI6b+Gx4StVzVmsPnoG699a1W9kAg6NfDKZdQ3AtrauSGT /LN2MgX1NmzxFtKSHY/I/tCvR2iWuP7QXLzhU= Received: by 10.100.48.19 with SMTP id v19mr442433anv.102.1235599579297; Wed, 25 Feb 2009 14:06:19 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c28sm8766768anc.5.2009.02.25.14.06.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 14:06:18 -0800 (PST) Message-ID: <49A5C0D8.7040103@gmail.com> Date: Wed, 25 Feb 2009 14:06:16 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: eh2th-mmox@yahoo.com References: <49A59D55.8080507@gmail.com> <299878.54638.qm@web65703.mail.ac4.yahoo.com> In-Reply-To: <299878.54638.qm@web65703.mail.ac4.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Use cases X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:05:59 -0000 eh2th-mmox@yahoo.com wrote: > 4. All content that the user has created and owns (no matter what the > permission) that is part of the prototype is included in > sufficient detail in the export." > > > 4. All the content which is required by the licensee for *display* of the prototype in the targeted environment, and all content required to display the "freely distributed test drive" redistributed version of the prototype is included in sufficient detail in the export. > > 4.1 Additional content which may be required for modification of the prototype or for producing derivitive works may also be included as agreed upon between user A and the organization that uses virtual world system B. > > I think we can keep it more general -- "all content for which suitable permissions exist, or there is an absence of restrictions, is included in the best detail allowed." Sincerely, jw From dcolivares@gmail.com Wed Feb 25 14:39:22 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09B828C0CE for ; Wed, 25 Feb 2009 14:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQFOVb7fWAzI for ; Wed, 25 Feb 2009 14:39:21 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 518213A6AE0 for ; Wed, 25 Feb 2009 14:39:20 -0800 (PST) Received: by bwz26 with SMTP id 26so224735bwz.37 for ; Wed, 25 Feb 2009 14:39:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Qm60Y4UDH7SLpPpX1bL28fvM6leDwIQ65gyWRQ0xMpE=; b=gXshaJvsTXSfuaPSqIkZWqOG8th+M5I5u6JWfykJRvQJnATMIjK6yRZTkEAdX3E0uJ oAvqySoNf/qwAAo+5Z7NYShcehU/qNKyknruKPXG740x0IpR0WOCuS5DqCXy3n39ypjt GTTmR6J9M7HKZCMzZm7kwdnPjQTFd5cJ+Jjcg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Qi64l7O0ozSqlEFuxvAoMxN/kf4WdfljqVaG80y4Ijyd8WTxkrmO6S7irB+rvmCvIW I+zqg8pWyYKQQPcfdjyPP98gmN4cl/nbkobyVsWJFF5sWSZ8nE2fCz2xbRxdFfHV6hDz aIFw3Fgk/t2XZywnkY6/fxk6rQarORFMi9KVs= MIME-Version: 1.0 Received: by 10.103.251.3 with SMTP id d3mr311971mus.72.1235601580825; Wed, 25 Feb 2009 14:39:40 -0800 (PST) In-Reply-To: <20090225.171525.16880.1@webmail11.vgs.untd.com> References: <20090225.171525.16880.1@webmail11.vgs.untd.com> Date: Wed, 25 Feb 2009 17:39:40 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:39:22 -0000 "Daniel, could you let us know which technology vendor you work for, or which world you are spending most of your development time in, under which avatar name?" Once again, this has absolutely no relevance to this discussion. Lets discuss your points; "That's not how it works in fact. Items that appear in OpenSim are either created there from scratch using the same type of tools as Second Life has, i.e. prims and texture uploading, or they are uploaded through the use of Second Inventory, which downloads SL inventory and uploads it on to OpenSim sims, or they are hacked with all the many available hacks out there. So the question is about what's happening in OpenSim in that scene, not about what you might view if you somehow merely open up a window into OpenSim from SL, which is what it sounds like this is doing, but I'd like to hear more about it from the authors, and not speculators." Actually, this is not true with the 'standard tres' on the SecondLifeGrid ( name taken from http://secondlifegrid.net/ ). The protocol specifies that each 'Primitive' has a type identifier called, 'PCode'. There is a PCode for 'Primitive', there is a 'PCode' for an Avatar, there is a PCode for a Tree, there is a 'PCode' for Grass. (Ref: http://wiki.secondlife.com/wiki/PCode ) Additionally, the protocol has an identifier for type specific information called 'State'. Each of the 'standard tree types' have a specific value in this 'State' identifier. There is absolutely no user created content sent to the client for 'standard trees and grass' beyond the fact that it's a tree and the type of tree based on a previously specified limited group of trees that are in the client, which I'll list below; Pine1 =3D 0, Oak =3D 1, TropicalBush1 =3D 2, Palm1 =3D 3, Dogwood =3D 4, TropicalBush2 =3D 5, Palm2 =3D 6, Cypress1 =3D7, Cypress2 =3D 8, Pine2 =3D 9, Plumeria =3D 10, WinterPine1 =3D 11, WinterAspen =3D 12, WinterPine2 =3D 13, Eucalyptus =3D 14, Fern =3D 15, Eelgrass =3D 16, SeaSword =3D 17, Kelp1 =3D 18, BeachGrass1 =3D 19, Kelp2 =3D 20 You can see more 'stuff' about these details in: http://gist.github.com/jhs/libopenmetaverse/blob/0f67dc153a621fb6b4d5133d82= 58f32390221b6e/OpenMetaverse/Primitives/Primitive.cs Based on this evidence, (and the fact that the trees appear to be standard 'Linden' trees) the claims are factually incorrect. Best Regards Daniel Olivares On Wed, Feb 25, 2009 at 5:15 PM, dyerbrookme@juno.com wrote: >>Nobody, the trees are client side generated.. =A0that means they're in > the client and part of the multimedia included in the client. =A0The > client is GPL, with the content in the client licensed under the CC. > The simulator says, "Hey!, render a pine tree here!", it doesn't say.. > =A0render a pine tree here, and use 'this texture' made by user 'x' > > Daniel, could you let us know which technology vendor you work for, or wh= ich world you are spending most of your development time in, under which av= atar name? > > That's not how it works in fact. Items that appear in OpenSim are either = created there from scratch using the same type of tools as Second Life has,= i.e. prims and texture uploading, or they are uploaded through the use of = Second Inventory, which downloads SL inventory and uploads it on to OpenSim= sims, or they are hacked with all the many available hacks out there. So t= he question is about what's happening in OpenSim in that scene, not about w= hat you might view if you somehow merely open up a window into OpenSim from= SL, which is what it sounds like this is doing, but I'd like to hear more = about it from the authors, and not speculators. I've already left a questio= n on their blog. > > Your assurances about CC licenses in the viewer are about the viewer itse= lf, not the things that it views, and CC is not a solution for commerce in = the Metaverse, it's only a solution for collectivism. > > > ____________________________________________________________ > Debt collectors calling your house? =A0Click here to consolidate into one= payment. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIk3kTaQHCkKEl0dXU3gIFO= 00dCRgjO3eWwrFxI84Xd08VnHyB6jm/ > From dyerbrookme@juno.com Wed Feb 25 14:49:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4006328C1A5 for ; Wed, 25 Feb 2009 14:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rHbNzneWCVp for ; Wed, 25 Feb 2009 14:49:39 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 66B5228C188 for ; Wed, 25 Feb 2009 14:49:39 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail24.vgs.untd.com [10.181.12.164]) by smtpout02.vgs.untd.com with SMTP id AABE4MUZTARMYQ72 for (sender ); Wed, 25 Feb 2009 14:49:21 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNLwbUUsdQ4J7lHV6c0kUg2g== Received: (from dyerbrookme@juno.com) by webmail24.vgs.untd.com (jqueuemail) id PAAG3DNL; Wed, 25 Feb 2009 14:48:32 PST Received: from [68.161.198.3] by webmail24.vgs.untd.com with HTTP: Wed, 25 Feb 2009 22:47:39 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Wed, 25 Feb 2009 22:47:39 GMT To: dcolivares@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090225.174739.19932.0@webmail24.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:1:306614269 X-UNTD-Peer-Info: 10.181.12.164|webmail24.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:49:40 -0000 >Once again, this has absolutely no relevance to this discussion. = Actually, no. It does. Because we need to understand which corporate or = personal interests you are flogging here with your recurring snarky repl= ies to me, and your literalist answers to larger questions that surely d= o involve more philosophical debate than you're willing to give them. Other contributors here asked everyone to give their real names and affi= liations. I've done so. While it isn't a requirement from IETF at this s= tage, my understanding is that it is when you make formal presentations = later, is it not? So why hide behind a common name on the Internet, which may or may not b= e a real name, and not display the platform you represent? ____________________________________________________________ Earn your associate's criminal justice degree and start your career trai= ning today. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTKKZuZwh7Uxnqb9ZnDD92E= 03NDxvS2bJPUVazZzuJN59ZeIrVZgeU/ From dcolivares@gmail.com Wed Feb 25 14:51:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF32928C1C2 for ; Wed, 25 Feb 2009 14:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWiTMU1cPLnE for ; Wed, 25 Feb 2009 14:51:38 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 9C34828C1C1 for ; Wed, 25 Feb 2009 14:51:37 -0800 (PST) Received: by bwz26 with SMTP id 26so228974bwz.37 for ; Wed, 25 Feb 2009 14:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5aDMdFjEKM/wY9oFs6DzA3HIsAbBl9ItXQPbQ53SwDk=; b=PXeBm4cdwvqe9ngCf4JQcY5DhcEmDC3whkQxJ0JTHPfyIu1I8wRpqHwxPg8d6kNC7c rjdmsJGtcttvc6eTRmyLXrloSYcGyOqjUaPFBfmSxYyjJOaD+A242Oep7eMpeTHNplLX KE8/DTNoF5TUl1IJbF2SvZh4/BdpgRRFZcF20= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RF0VhVBpLjZo8mhW3QDHFkhTABHVXQ5ehinqX9Ydr/TgrK90bNDa+TClsVmhUysQJj GR1Y2+APaQ+mn++zsH1GnMXj5SGA10EO1Y9kZQ8oCfETAX+b5IFqSXRrbbQ08Rnvzk/0 9XWKW4Gxxe/2Y7LNyeM7cKMiHJuUHs2XMyZQc= MIME-Version: 1.0 Received: by 10.103.175.8 with SMTP id c8mr307904mup.117.1235602317252; Wed, 25 Feb 2009 14:51:57 -0800 (PST) In-Reply-To: <20090225.174739.19932.0@webmail24.vgs.untd.com> References: <20090225.174739.19932.0@webmail24.vgs.untd.com> Date: Wed, 25 Feb 2009 17:51:57 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 22:51:38 -0000 I've already given my introduction. I can also confirm that my name is, indeed Daniel Olivares, to which, Linden Lab has an account with my 'payment information on file'. If it ever was required to confirm it, I'm sure they would were I to ask them to. Best Regards Daniel Olivares On Wed, Feb 25, 2009 at 5:47 PM, dyerbrookme@juno.com wrote: >>Once again, this has absolutely no relevance to this discussion. > > Actually, no. It does. Because we need to understand which corporate or p= ersonal interests you are flogging here with your recurring snarky replies = to me, and your literalist answers to larger questions that surely do invol= ve more philosophical debate than you're willing to give them. > > Other contributors here asked everyone to give their real names and affil= iations. I've done so. While it isn't a requirement from IETF at this stage= , my understanding is that it is when you make formal presentations later, = is it not? > > So why hide behind a common name on the Internet, which may or may not be= a real name, and not display the platform you represent? > > ____________________________________________________________ > Click here to save cash and find low rates on auto loans. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLaW00TZ38PJOzUL8h0vJDc= 5reqqkNFRwVohQ3GrVDrJNTeaD2vQk/ > From dyerbrookme@juno.com Wed Feb 25 15:19:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69CFB3A6AE6 for ; Wed, 25 Feb 2009 15:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-OMI6nzsQnO for ; Wed, 25 Feb 2009 15:19:23 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 597EE3A6B97 for ; Wed, 25 Feb 2009 15:19:23 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail10.vgs.untd.com [10.181.12.150]) by smtpout04.vgs.untd.com with SMTP id AABE4MWRWAKWVB8S for (sender ); Wed, 25 Feb 2009 15:19:16 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNvkVs9y7XHUWsv5K+koaV9Q== Received: (from dyerbrookme@juno.com) by webmail10.vgs.untd.com (jqueuemail) id PAAJSD2G; Wed, 25 Feb 2009 15:18:35 PST Received: from [68.161.198.3] by webmail10.vgs.untd.com with HTTP: Wed, 25 Feb 2009 23:17:40 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Wed, 25 Feb 2009 23:17:40 GMT To: dcolivares@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090225.181740.10290.0@webmail10.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 3:4:2565510819 X-MAIL-INFO: 111aaaaf9797aa1a4ada1a8acb6f9b2b0ee3373f1f4b2eb72e7733 X-UNTD-Peer-Info: 10.181.12.150|webmail10.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:19:24 -0000 >I've already given my introduction. Beyond a name, I don't see one. >I can also confirm that my name is, indeed Daniel Olivares, to which, Linden Lab has an account with my 'payment information on file'. If it ever was required to confirm it, I'm sure they would were I to ask them to. So let me get this straight. Some officers of companies on this list mad= e a big plea for real-life names to be used on this list when they saw "= Prokofy Neva", obviously as a way to try to get rid of what they felt we= re annoying anonymous avatars from SL, so I gave them my RL name and loc= ation (which is easily Googlable anyway); Morgaine Dinova refused to div= ulge her RL name and said it's not a requirement of IETF, and David Levi= ne/Zha Ewry also chimed in to say it was essentially not required until = the later "notewell" stage. = But now Charles and Jon who originally made this demand are not making t= his demand on anyone else now that I've complied, and you can then give = a name that could be various identities on the Internet, from a guy at r= ackspace.com to a DeVry-educated web page maker, and not have to link to= the Second Life avatar where we might glean something about your reputa= tion, JIRA and forum contributions, groups, work in AWG, etc. And when p= ressed, you reply that your common name has a payment info on file with = LL which can confirm this LOL. OK! Just so we're clear what we're dealing with here, which essentially = amounts to...unaccountable avatars all over again : ) ____________________________________________________________ Love Graphic Design? Find a school near you. Click Now. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTOro0L7J2ihFagX1clVyvR= U8g0sYL2c0oF71hFFRhWjU2WYQRbxQk/ From dcolivares@gmail.com Wed Feb 25 15:24:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16DF428C25E for ; Wed, 25 Feb 2009 15:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH8KbiJuqRt8 for ; Wed, 25 Feb 2009 15:24:12 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 96DB728C25D for ; Wed, 25 Feb 2009 15:24:09 -0800 (PST) Received: by bwz26 with SMTP id 26so240278bwz.37 for ; Wed, 25 Feb 2009 15:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=rUb5j0wti8RFXuorJCRShRdT1VIyo8ZIBAHZO5GUs4I=; b=br1e+GZ7TmVP+I0Boko3pqUiwKWi67a2KpRj7sSRYmfMB99AJD03Z5xjl9BogGiMkF 35pny3Tbk2oySapGBCsYPyiZbrHNZFOcz/Z5MtNfq2GCRNJo9F2lHjFfI8ERi/hf0klp KtFQzs3qQfsZFBbO9Un0B4t0y+VSkQoTXzwSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YiHnHBO/yxij74j+5U9pkTJSS1PWBGCxYcC5dkdtTm9NCa3tjpS7LDIzDWcBLwL0wm AwsP0eH6mJd8Cz2aU2vb1J6/N/crJtxyr51m2UHLvPCmyQ8Gn76Tsl8Z4WxK0/sFyLLH mGvz9iP+Kr2V/PoQ7Q4I3VxxG1uKV7XLO2a7Q= MIME-Version: 1.0 Received: by 10.103.227.13 with SMTP id e13mr342448mur.20.1235604269314; Wed, 25 Feb 2009 15:24:29 -0800 (PST) In-Reply-To: <20090225.181740.10290.0@webmail10.vgs.untd.com> References: <20090225.181740.10290.0@webmail10.vgs.untd.com> Date: Wed, 25 Feb 2009 18:24:29 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:24:13 -0000 As far as organizations that a person represents, It doesn't matter on the IETF as all people are representing themselves as individuals as per our IETF area moderator in a previous e-mail. "And when pressed, you reply that your common name has a payment info on file with LL which can confirm this LOL. OK! Just so we're clear what we're dealing with here, which essentially amounts to...unaccountable avatars all over again : )" I also have a card from the DMV, a social security number, a birth certificate, some Tax documents that say that I am who I say that I am. If it is required, I'll present that information to an authorized representative of the IETF. Sincerely Daniel Olivares On Wed, Feb 25, 2009 at 6:17 PM, dyerbrookme@juno.com wrote: >>I've already given my introduction. > > Beyond a name, I don't see one. > >>I can also confirm that my name is, indeed Daniel Olivares, to which, > Linden Lab has an account with my 'payment information on file'. =A0If > it ever was required to confirm it, I'm sure they would were I to ask > them to. > > So let me get this straight. Some officers of companies on this list made= a big plea for real-life names to be used on this list when they saw "Prok= ofy Neva", obviously as a way to try to get rid of what they felt were anno= ying anonymous avatars from SL, so I gave them my RL name and location (whi= ch is easily Googlable anyway); Morgaine Dinova refused to divulge her RL n= ame and said it's not a requirement of IETF, and David Levine/Zha Ewry also= chimed in to say it was essentially not required until the later "notewell= " stage. > > But now Charles and Jon who originally made this demand are not making th= is demand on anyone else now that I've complied, and you can then give a na= me that could be various identities on the Internet, from a guy at rackspac= e.com to a DeVry-educated web page maker, and not have to link to the Secon= d Life avatar where we might glean something about your reputation, JIRA an= d forum contributions, groups, work in AWG, etc. And when pressed, you repl= y that your common name has a payment info on file with LL which can confir= m this LOL. > > OK! Just so we're clear what we're dealing with here, which essentially a= mounts to...unaccountable avatars all over again : ) > > ____________________________________________________________ > Earn your associate's criminal justice degree and start your career train= ing today. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTKKZvOtHAoqsMOnXVoR9wXT= zSyNwOoHzFRuU7wjzbrwb1OqpT1cwI/ > From dyerbrookme@juno.com Wed Feb 25 15:24:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A12228C269 for ; Wed, 25 Feb 2009 15:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL8sZqETff5j for ; Wed, 25 Feb 2009 15:24:55 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 30E6B28C257 for ; Wed, 25 Feb 2009 15:24:55 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail10.vgs.untd.com [10.181.12.150]) by smtpout03.vgs.untd.com with SMTP id AABE4MW3GAMT8422 for (sender ); Wed, 25 Feb 2009 15:24:22 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNuec5zVqm6OZGyiNgHHMTqw== Received: (from dyerbrookme@juno.com) by webmail10.vgs.untd.com (jqueuemail) id PAAJ3MVY; Wed, 25 Feb 2009 15:23:38 PST Received: from [68.161.198.3] by webmail10.vgs.untd.com with HTTP: Wed, 25 Feb 2009 23:22:22 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Wed, 25 Feb 2009 23:22:22 GMT To: dcolivares@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090225.182222.10290.1@webmail10.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 7:3:3646965442 X-MAIL-INFO: 3db3e757d7feb3d72f47fe2fbf1a8b4a636b6bcb6bf393934fae174f43ae177a4783ba77ba3fcfcf87ef0777ef2a5e274e7b6747131f0a7b4e4e6f4e8f2b2bda2b3be3fa772eba3bcbeffb333b83 X-UNTD-Peer-Info: 10.181.12.150|webmail10.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:24:56 -0000 >Actually, this is not true with the 'standard tres' on the SecondLifeGrid ( name taken from http://secondlifegrid.net/ ). The protocol specifies that each 'Primitive' has a type identifier called, 'PCode'. There is a PCode for 'Primitive', there is a 'PCode' for an Avatar, there is a PCode for a Tree, there is a 'PCode' for Grass. (Ref: http://wiki.secondlife.com/wiki/PCode ) Additionally, the protocol has an identifier for type specific information called 'State'. Each of the 'standard tree types' have a specific value in this 'State' identifier. There is absolutely no user created content sent to the client for 'standard trees and grass' beyond the fact that it's a tree and the type of tree based on a previously specified limited group of trees that are in the client, which I'll list below; Pine1 =3D 0, Oak =3D 1, TropicalBush1 =3D 2, Anyone looking at those trees can tell they aren't Linden trees of the s= tandard issue, but look more like Lilith Heart trees. And precisely because they don't look like Linden trees, I asked who is = the author/creator and where were they created. Yes, I realize Linden tree generation is a totally different thingie tha= n the usual prim-making, and works on a different principle of virtualit= y, which I guess you've outlined. BTW, did the Lindens let you copy their tree-generating program, and do = they mind if you port that capacity into other worlds? Because Linden tr= ees are special, in that they can blow in the wind and such the way home= -made trees can't. Some of the Linden trees are nice, but I have to wonder, if you were goi= ng to make another world, even a clone-world reverse-engineered, why on = earth would you copy that dying cocoanut tree and the weird eel grass?! = Couldn't you make something different over there? ____________________________________________________________ Become a Medical Transcriptionist. Click here to find schedules designed= to fit your life. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTJjHaxNmAyItCqkAlDcdx5= EnBR4D8iAtzWiJgUYAtcOSIPDHYyfh2/ From dcolivares@gmail.com Wed Feb 25 15:30:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0BF28C295 for ; Wed, 25 Feb 2009 15:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NRJn+O9q6lk for ; Wed, 25 Feb 2009 15:30:04 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 6E02528C257 for ; Wed, 25 Feb 2009 15:30:03 -0800 (PST) Received: by bwz26 with SMTP id 26so242147bwz.37 for ; Wed, 25 Feb 2009 15:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OIIyNm0yYqbwoOc/WWDLQBsievsq5CyuAJZ0ZNW1W6A=; b=LE9qq1cv/xYVT+Yf6afJUvUJPXVOmiUDUGG0lbizaAM0ar03qxw6sZfBPuVXXrmfFE lnPZZfBKV4kTDfSw0Edr/UEp40omSNxr1xAd8EFoeqfKoxDUwDkG6piV/7fnaX4yWkIK w6Zj3Jc344GDsNrn1GDsCPdNAGosic3JrVviE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YFGCs0LjWOG27oarq9jIT/xcpUO8oB9WRAmZRq/EgmYFKnFyXmb3tkGGal+zKQ+6GJ rfUBPGLGrjXpuRZnYKeDo8bf/PrNi2u1t1YyKFrBqu7Pef7QBxeqkLxySjbkGx72vkgJ eohagNb81ukdqb3Y1tfDEjj13tE+AGHjuteUQ= MIME-Version: 1.0 Received: by 10.103.223.2 with SMTP id a2mr338812mur.54.1235604623671; Wed, 25 Feb 2009 15:30:23 -0800 (PST) In-Reply-To: <20090225.182222.10290.1@webmail10.vgs.untd.com> References: <20090225.182222.10290.1@webmail10.vgs.untd.com> Date: Wed, 25 Feb 2009 18:30:23 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:30:06 -0000 "Anyone looking at those trees can tell they aren't Linden trees of the standard issue, but look more like Lilith Heart trees" To discover the actual identity of those trees, parhaps you should contact Jani. To me, they looked like 'standard linden trees', to you they look like 'Lillith Heart' trees. "BTW, did the Lindens let you copy their tree-generating program, and do they mind if you port that capacity into other worlds? Because Linden trees are special, in that they can blow in the wind and such the way home-made trees can't." The lindens license their client under the GPL, they licence the multimedia content under the Creative Commons Sharealike license. The 'algorithm' for rendering the trees is in the client. The multimedia used in the trees are in the client. Therefore, the onus here is on realXtend to comply with the GPL and CC Sharealike licenses regarding displaying 'standard Linden' trees. "Some of the Linden trees are nice, but I have to wonder, if you were going to make another world, even a clone-world reverse-engineered, why on earth would you copy that dying cocoanut tree and the weird eel grass?! Couldn't you make something different over there?" LOL, indeed, indeed :D Sincerely Daniel Olivares On Wed, Feb 25, 2009 at 6:22 PM, dyerbrookme@juno.com wrote: >>Actually, this is not true with the 'standard tres' on the > SecondLifeGrid ( name taken from http://secondlifegrid.net/ ). =A0 The > protocol specifies that each 'Primitive' has a type identifier called, > 'PCode'. =A0 There is a PCode for 'Primitive', there is a 'PCode' for an > Avatar, there is a PCode for a Tree, there is a 'PCode' for Grass. > (Ref: http://wiki.secondlife.com/wiki/PCode ) =A0Additionally, the > protocol has an identifier for type specific information called > 'State'. =A0 Each of the 'standard tree types' have a specific value in > this 'State' identifier. =A0 There is absolutely no user created content > sent to the client for 'standard trees and grass' beyond the fact that > it's a tree and the type of tree based on a previously specified > limited group of trees that are in the client, which I'll list below; > > Pine1 =3D 0, > Oak =3D 1, > TropicalBush1 =3D 2, > > Anyone looking at those trees can tell they aren't Linden trees of the st= andard issue, but look more like Lilith Heart trees. > > And precisely because they don't look like Linden trees, I asked who is t= he author/creator and where were they created. > > Yes, I realize Linden tree generation is a totally different thingie than= the usual prim-making, and works on a different principle of virtuality, w= hich I guess you've outlined. > > BTW, did the Lindens let you copy their tree-generating program, and do t= hey mind if you port that capacity into other worlds? Because Linden trees = are special, in that they can blow in the wind and such the way home-made t= rees can't. > > Some of the Linden trees are nice, but I have to wonder, if you were goin= g to make another world, even a clone-world reverse-engineered, why on eart= h would you copy that dying cocoanut tree and the weird eel grass?! Couldn'= t you make something different over there? > > ____________________________________________________________ > Love Graphic Design? Find a school near you. Click Now. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTOroy2KGhDyIhzpw9bFepA2= hBUEDYIvudCrEqYNkA7fFsx81qBsw4/ > From dyerbrookme@juno.com Wed Feb 25 15:44:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51DA228C28D for ; Wed, 25 Feb 2009 15:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-8pMHEUFoZo for ; Wed, 25 Feb 2009 15:44:45 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 0BEED28C24F for ; Wed, 25 Feb 2009 15:44:44 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail10.vgs.untd.com [10.181.12.150]) by smtpout03.vgs.untd.com with SMTP id AABE4MX9MAY7SJK2 for (sender ); Wed, 25 Feb 2009 15:44:43 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNuaToAc+bSZvYcD7cIPnaKA== Received: (from dyerbrookme@juno.com) by webmail10.vgs.untd.com (jqueuemail) id PAAK9F24; Wed, 25 Feb 2009 15:44:17 PST Received: from [68.161.198.3] by webmail10.vgs.untd.com with HTTP: Wed, 25 Feb 2009 23:43:19 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Wed, 25 Feb 2009 23:43:19 GMT To: dcolivares@gmail.com X-Mailer: Webmail Version 4.0 Message-Id: <20090225.184319.10290.2@webmail10.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:3:3011594182 X-UNTD-Peer-Info: 10.181.12.150|webmail10.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:44:46 -0000 >The lindens license their client under the GPL, they licence the multimedia content under the Creative Commons Sharealike license. The 'algorithm' for rendering the trees is in the client. The multimedia used in the trees are in the client. Therefore, the onus here is on realXtend to comply with the GPL and CC Sharealike licenses regarding displaying 'standard Linden' trees. When the Lindens opensourced their client back in the day, they rushed o= ut with it because of the reverse-engineering of the client already by l= ibsecondlife (a bad idea which has only led to more griefing not more bu= g-fixing). = But there wasn't any OpenSim quite yet at least not publicly known. Thus= they made this decision based on a conception that people would use the= opensourced clients to make a better client for accessing *Second Life*= itself, not for clone worlds or reverse-engineered worlds which didn't = exist at the moment they released the opensourced code. I'm not aware th= at the license for this client in fact can be construed as meaning "and = any other world that appears that is a clone or reverse engineer of SL".= I imagine there might be different opinions on that. Does the license = say "any for any other worlds that might come along besides SL?" ____________________________________________________________ Click for free info on paralegal training and make up to $150K/ year. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLiTmaW9F5H64UcdSWITSP= TkbMTppw9tBFjN0s4Iojk25VghQ6rsc/ From dcolivares@gmail.com Wed Feb 25 15:52:53 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28323A6886 for ; Wed, 25 Feb 2009 15:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bleMVqxPAyrD for ; Wed, 25 Feb 2009 15:52:52 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 6FE123A6AA7 for ; Wed, 25 Feb 2009 15:52:52 -0800 (PST) Received: by bwz26 with SMTP id 26so249212bwz.37 for ; Wed, 25 Feb 2009 15:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=B8XausRUimMSM7Ju1IM8H8/wLsb9piDn/FH77Uf68QA=; b=XEhfiHWc066nD8n0keoFIj65sD/5FTtdA3aLagTzJjshYWamLu6yfUkRakzA08IucD VXxj1boW5uOS7HOVEZMN5bRJ7p4e7VB7sduZkQAv9GPyRTpjwg+BD/LghORMLKyBc++M MiGAfyoes86NirqpwbVWNVwt1LKzpjyrWcnGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=oZxoCpBVndtzSM3OqcJ3TSYu5dcdpUm5RWbDyPW4ZzbFGbgwulc2JN2ZGHxFl6qXNp dkkyXU+hA9O3bB1lWzWf6xawBDgyDIcYgEzK5nzMZuHapB3ec48TIccOWlp5LpYl8HQQ jjdTbjT3/e5Kygb8CR6YdPd6CSx79xQ5t4m2w= MIME-Version: 1.0 Received: by 10.103.222.1 with SMTP id z1mr350003muq.51.1235605992183; Wed, 25 Feb 2009 15:53:12 -0800 (PST) In-Reply-To: <20090225.184319.10290.2@webmail10.vgs.untd.com> References: <20090225.184319.10290.2@webmail10.vgs.untd.com> Date: Wed, 25 Feb 2009 18:53:12 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:52:53 -0000 GPL v2, is GPL v2 and the CC Sharealike license is what it is regardless of what you think it means or how it was intended when it was licensed that way. You can find a copy of the licenses in the source distribution of the clien= t. Additionally, for convenience, you can find a copy on the web at the following locations: Creative Commons Sharealike http://creativecommons.org/licenses/by-sa/3.0/legalcode GPL v2 http://www.gnu.org/licenses/gpl-2.0.txt Sincerely Daniel Olivares On Wed, Feb 25, 2009 at 6:43 PM, dyerbrookme@juno.com wrote: >>The lindens license their client under the GPL, they licence the > multimedia content under the Creative Commons Sharealike license. =A0The > 'algorithm' for rendering the trees is in the client. =A0The multimedia > used in the trees are in the client. =A0Therefore, the onus here is on > realXtend to comply with the GPL and CC Sharealike licenses regarding > displaying 'standard Linden' trees. > > When the Lindens opensourced their client back in the day, they rushed ou= t with it because of the reverse-engineering of the client already by libse= condlife (a bad idea which has only led to more griefing not more bug-fixin= g). > > But there wasn't any OpenSim quite yet at least not publicly known. Thus = they made this decision based on a conception that people would use the ope= nsourced clients to make a better client for accessing *Second Life* itself= , not for clone worlds or reverse-engineered worlds which didn't exist at t= he moment they released the opensourced code. I'm not aware that the licens= e for this client in fact can be construed as meaning "and any other world = that appears that is a clone or reverse engineer of SL". =A0I imagine there= might be different opinions on that. Does the license say "any for any oth= er worlds that might come along besides SL?" > > > > ____________________________________________________________ > Become a Medical Transcriptionist. Click here to find schedules designed = to fit your life. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTJjHaE1WDoucIwc0bFGTXPd= HhVq4LSJAzz5SJl9nFC8kgmyG8s3c8/ > From john.hurliman@intel.com Wed Feb 25 15:55:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7FD03A6AA7 for ; Wed, 25 Feb 2009 15:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJljUMcep4Kk for ; Wed, 25 Feb 2009 15:55:29 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 92B033A6886 for ; Wed, 25 Feb 2009 15:55:29 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 25 Feb 2009 15:48:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,267,1233561600"; d="scan'208";a="389816379" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga002.jf.intel.com with ESMTP; 25 Feb 2009 16:04:33 -0800 Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by rrsmsx602.amr.corp.intel.com (10.31.0.33) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 25 Feb 2009 16:55:50 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Wed, 25 Feb 2009 16:55:49 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Wed, 25 Feb 2009 16:55:39 -0700 Thread-Topic: [mmox] RealExtend Teleporting Between Worlds Thread-Index: AcmXoKRq5CIUN4HlR3O3so+99yQgJQAAGAQg Message-ID: <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> References: <20090225.182222.10290.1@webmail10.vgs.untd.com> In-Reply-To: <20090225.182222.10290.1@webmail10.vgs.untd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {4E152000-A6D4-41A1-9E3B-21B20BA3DA3C} x-cr-hashedpuzzle: Ax71 CA4V CXuQ Cg33 C1O/ DahK DcXB ESRp EpCY E6Oj FfWw F9L6 GAgn H1p3 KMIh LKlk; 1; bQBtAG8AeABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {4E152000-A6D4-41A1-9E3B-21B20BA3DA3C}; agBvAGgAbgAuAGgAdQByAGwAaQBtAGEAbgBAAGkAbgB0AGUAbAAuAGMAbwBtAA==; Wed, 25 Feb 2009 23:55:39 GMT; UgBFADoAIABbAG0AbQBvAHgAXQAgAFIAZQBhAGwARQB4AHQAZQBuAGQAIABUAGUAbABlAHAAbwByAHQAaQBuAGcAIABCAGUAdAB3AGUAZQBuACAAVwBvAHIAbABkAHMA acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:55:30 -0000 >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >dyerbrookme@juno.com >Sent: Wednesday, February 25, 2009 3:22 PM >To: dcolivares@gmail.com >Cc: mmox@ietf.org; dyerbrookme@juno.com >Subject: Re: [mmox] RealExtend Teleporting Between Worlds > >>Actually, this is not true with the 'standard tres' on the >SecondLifeGrid ( name taken from http://secondlifegrid.net/ ). The >protocol specifies that each 'Primitive' has a type identifier called, >'PCode'. There is a PCode for 'Primitive', there is a 'PCode' for an >Avatar, there is a PCode for a Tree, there is a 'PCode' for Grass. >(Ref: http://wiki.secondlife.com/wiki/PCode ) Additionally, the >protocol has an identifier for type specific information called >'State'. Each of the 'standard tree types' have a specific value in >this 'State' identifier. There is absolutely no user created content >sent to the client for 'standard trees and grass' beyond the fact that >it's a tree and the type of tree based on a previously specified >limited group of trees that are in the client, which I'll list below; > >Pine1 =3D 0, >Oak =3D 1, >TropicalBush1 =3D 2, > >Anyone looking at those trees can tell they aren't Linden trees of the >standard issue, but look more like Lilith Heart trees. > >And precisely because they don't look like Linden trees, I asked who is >the author/creator and where were they created. > >Yes, I realize Linden tree generation is a totally different thingie >than the usual prim-making, and works on a different principle of >virtuality, which I guess you've outlined. > >BTW, did the Lindens let you copy their tree-generating program, and do >they mind if you port that capacity into other worlds? Because Linden >trees are special, in that they can blow in the wind and such the way >home-made trees can't. > >Some of the Linden trees are nice, but I have to wonder, if you were >going to make another world, even a clone-world reverse-engineered, why >on earth would you copy that dying cocoanut tree and the weird eel >grass?! Couldn't you make something different over there? > The Second Life simulators and OpenSim are only sending a single number to = say what type of tree the viewer should render. All of the fancy code for d= rawing the tree and making it blow in the wind is in the Second Life viewer= . I agree that it would be very nice if someone improved the default trees = in the Second Life viewer. This brings up an important topic to consider in interoperability. Most (if= not all) virtual platforms use shortcuts like this to offload processing o= n to the client. But saying "draw tree type 7" doesn't mean the same thing = (or anything) to Forterra, VastPark, etc. Would you create interop versions= of the trees (mesh and texture representations), or just not allow that co= ntent to move across boundaries? John From morgaine.dinova@googlemail.com Wed Feb 25 16:16:53 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF6D73A6B8C for ; Wed, 25 Feb 2009 16:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zn28VvSjgITS for ; Wed, 25 Feb 2009 16:16:52 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 84F823A6886 for ; Wed, 25 Feb 2009 16:16:51 -0800 (PST) Received: by bwz26 with SMTP id 26so255977bwz.37 for ; Wed, 25 Feb 2009 16:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8C/Z1YasfnS5sbHVCWNzm7lxh/sEu61hkpKDs06Ozi8=; b=jDVFo/BkCep1MHyrmPASRF0eGWBUznpMWGnM9ZDj0gjnn/ustnvs/7kOKVIntM30rf I5sSce/7sw9/Ykr7SQLKkNtJpbiSYxG6UHA0b/ffVTSt7OW+lWWx6pJvEMiKbKTblYWJ tvDaOy0mhtoMamDzoCNGogNPmKeBTN6wOrBYI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qfTUbvQ9+b25h7iQ8/2BNALy8FVp1/Iw8MVfLsFWt4Nk84/VfHgcd2RNDKjpoa8zyI vX/MWKRXrnjc3KBAyeuzRkwQxqAZT7fcMf6fJzctllJTAWt+6c8d2BzCW4VYFfecYz3D QnRac9p1Ni2oh9xQ3T9I6mpCyC6qBH+WeHymM= MIME-Version: 1.0 Received: by 10.181.199.19 with SMTP id b19mr218797bkq.191.1235607430978; Wed, 25 Feb 2009 16:17:10 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Feb 2009 00:17:10 +0000 Message-ID: From: Morgaine To: Catherine Pfeffer Content-Type: multipart/alternative; boundary=001636c599ea015ea50463c746c1 Cc: mmox@ietf.org Subject: Re: [mmox] tags X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 00:16:53 -0000 --001636c599ea015ea50463c746c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 25, 2009 at 12:48 PM, Catherine Pfeffer wrote: > > I am currently wondering if there is not an automated way to map the LLSD > abstract view into a real XML-ish serialization. Perhaps that would make > everyone happy. That would keep the very high flexibility of LLSD, have a > lower angle bracket tax, and allow "natural" use of all XML tools. That > would keep the possibility of having three different serializations, even > though I still think that it's a false good idea. > > The technical problem I see with this approach is that the current LLSD > draft does not recognize the special role played by the maps in storing > name-value pairs used by the upper layers. It does not either say that > arrays are made for vectors and quaternions, and so on. There is a lot of > semantics that are evacuated from this draft and that I only know for having > worked with SL client source code as an Open Source contributor. And I don't > see how I could specify such an "intelligent" XML serialization if such > context information is missing. > > Catherine, this is excellent advice that you're giving us about XML, but the underlying hint to "do everything in XML to do it properly" is not a worldview that I can subscribe to everywhere, for very practical and somewhat insurmountable RL engineering reasons. Using XML for communication with Limited Capability Clients can easily be a deal breaker in the application domain that we're talking about, which is characterized by very high rate streaming of object updates over limited bandwidth. Removing a few angle brackets and producing better XML is nice, but a good binary serialization is orders of magnitude faster and at least one order of magnitude more compact, so such improvements are not even in the same ballpark. Perhaps your advice could work at a higher level instead. Replacing LLSD and LLIDL with a pure XML-based abstraction layer would be fine in principle, allowing us to use XML power tools to generate our programming APIs. However, at run time, the interface between wire API and programs needs to be fast and tiny, both to save LCCs from collapse and to reduce the load on servers, so binary serializations are more than slightly important. Even power desktops working over broadband struggle with the object update stream, and that is mostly binary-encoded at the moment in SL so it would be even worse with XML. But this is not an SL-only issue. No systems anywhere benefit from adding orders of magnitude of overhead. The solution might be to use an XML-based IDL to generate an efficient binary encoding, devoid of DTDs and without the performance-destroying string comparisons that are completely unnecessary when the two endpoints have agreed on an interchange spec. Call it XML Protocol Buffers and you'd be onto a winner. ;-) Morgaine. On Wed, Feb 25, 2009 at 12:48 PM, Catherine Pfeffer wrote: > Infinity said: > > about sizes of ints as attributes. > > > > let me pose the question... what is the difference in terms of > > processing expectations if one sends > > > > '12' > > > > vs. sending > > > > '12' ? > > Honestly, having a tag is so ... unusual in the XML world, that I > won't even attempt to answer this detail question and the next ones. We > should simply abandon the idea of having , , and so > on in the data flow. > > In a binary serialization, you need to say : the next four bytes will be > an integer. Or the next 25 bytes will be a 25-bytes long string. Fine. But > there is *no* reason to do the same in an XML file. The angle brackets < > > or the quotes " " are delimiters. They tell you where the data starts and > where it ends, so there is no need to say it an integer or whatever else. > > When you want to pass a key-value pair like > Taper_X = 0.5 > then if we want to stick to XML paradigm, it should be a > ... Taper_X="0.5" ... > attribute of some prim-related tag (14 bytes), and not > ... > Taper_X > 0.5 > ... > in some (36 bytes plus the whitespace). > > The quotes " " tell where "0.5" starts and where it ends. The information > "Taper_X is a float" belongs to the XML schema or DTD, not to the data sent > over the wire. > > What I am trying to say is that the current xxSD XML serialization might > look like XML, but it definitely belongs to another world from a conceptual > point of view. It's like Canada Dry, it looks like beer, but it's no beer. > > What you have come up with is just a rewriting of the binary serialization > that is well-formed XML. That does not make it something that fits naturally > into XML: > - LLIDL plays the same role as XML schemas or DTDs and could simply be > dropped. > - currently, accessing the value of Taper_X from XPath is convoluted and > probably slow, compare: > map/key[. = 'Taper_X']/following-sibling::float[position() = 1] with: > @Taper_X > - I also already mentioned the higher (250%) bandwidth footprint > - etc > > What is the point of having a XML serialization just to have it "look like" > some XML, while it's not really XML? > > > OK, let's try to be positive (for once ;-) ): > > I am currently wondering if there is not an automated way to map the LLSD > abstract view into a real XML-ish serialization. Perhaps that would make > everyone happy. That would keep the very high flexibility of LLSD, have a > lower angle bracket tax, and allow "natural" use of all XML tools. That > would keep the possibility of having three different serializations, even > though I still think that it's a false good idea. > > The technical problem I see with this approach is that the current LLSD > draft does not recognize the special role played by the maps in storing > name-value pairs used by the upper layers. It does not either say that > arrays are made for vectors and quaternions, and so on. There is a lot of > semantics that are evacuated from this draft and that I only know for having > worked with SL client source code as an Open Source contributor. And I don't > see how I could specify such an "intelligent" XML serialization if such > context information is missing. > > (I apologize in advance if this context information is in the LLSD draft > and I did not see it.) > > -- > Cathy > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --001636c599ea015ea50463c746c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 25, 2009 at 12:48 PM, Catherine Pfef= fer <cathypf= effer@gmail.com> wrote:

I am currently wondering if there is not an automated way to map the LLSD abstract view into a real XML-ish serialization. Perhaps that would make everyone happy. That would keep the very high flexibility of LLSD, have a lower angle bracket tax, and allow "natural" use of all XM= L tools. That would keep the possibility of having three different serializations, even though I still think that it's a false good idea.<= br>
The technical problem I see with this approach is that the current LLSD draft does not recognize the special role played by the maps in storing name-value pairs used by the upper layers. It does not either say that arrays are made for vectors and quaternions, and so on. There is a lot of semantics that are evacuated from this draft and that I only know for having worked with SL client source code as an Open Source contributor. And I don't see how I could specify such an "intelligent" XML serialization if such context information is mi= ssing.
=A0

Catherine, this is excellent advice= that you're giving us about XML, but the underlying hint to "do e= verything in XML to do it properly" is not a worldview that I can subs= cribe to everywhere, for very practical and somewhat insurmountable RL engi= neering reasons.

Using XML for communication with Limited Capability Clients can easily = be a deal breaker in the application domain that we're talking about, w= hich is characterized by very high rate streaming of object updates over li= mited bandwidth.=A0 Removing a few angle brackets and producing better XML = is nice, but a good binary serialization is orders of magnitude faster and = at least one order of magnitude more compact, so such improvements are not = even in the same ballpark.

Perhaps your advice could work at a higher level instead.=A0 Replacing = LLSD and LLIDL with a pure XML-based abstraction layer would be fine in pri= nciple, allowing us to use XML power tools to generate our programming APIs= .=A0 However, at run time, the interface between wire API and programs need= s to be fast and tiny, both to save LCCs from collapse and to reduce the lo= ad on servers, so binary serializations are more than slightly important.
Even power desktops working over broadband struggle with the object upd= ate stream, and that is mostly binary-encoded at the moment in SL so it wou= ld be even worse with XML.=A0 But this is not an SL-only issue.=A0 No syste= ms anywhere benefit from adding orders of magnitude of overhead.

The solution might be to use an XML-based IDL to generate an efficient = binary encoding, devoid of DTDs and without the performance-destroying stri= ng comparisons that are completely unnecessary when the two endpoints have = agreed on an interchange spec.=A0 Call it XML Protocol Buffers and you'= d be onto a winner. ;-)

Morgaine.






On Wed,= Feb 25, 2009 at 12:48 PM, Catherine Pfeffer <cathypfeffer@gmail.com> wr= ote:
Infinity said:> about sizes of ints as attributes.
>
> let me pose the qu= estion... what is the difference in terms of =A0
> processing expectations if one sends
>
>=A0 '<integ= er size=3D"8">12</integer>'
>
> vs. sending
>
> '<integer size=3D"32&q= uot;>12</integer>' ?

Honestly, having a &= lt;integer> tag is so ... unusual in the XML world, that I won't eve= n attempt to answer this detail question and the next ones. We should simpl= y abandon the idea of having <integer>, <float>, <string>= and so on in the data flow.

In a binary serialization, you need to say :=A0 the next four bytes wil= l be an integer. Or the next 25 bytes will be a 25-bytes long string. Fine.= But there is *no* reason to do the same in an XML file. The angle brackets= < > or the quotes " " are delimiters. They tell you where = the data starts and where it ends, so there is no need to say it an integer= or whatever else.

When you want to pass a key-value pair like
=A0=A0=A0 Taper_X =3D 0.= 5
then if we want to stick to XML paradigm, it should be a
=A0=A0=A0 = ... Taper_X=3D"0.5" ...
attribute of some prim-related tag (14= bytes), and not
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ...
=A0=A0=A0=A0=A0=A0=A0=A0=A0 <key&g= t;Taper_X</key>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 <float>0.5</f= loat>
=A0=A0=A0=A0=A0=A0=A0=A0=A0 ...
in some <map> (36 byte= s plus the whitespace).

The quotes " " tell where "0.= 5" starts and where it ends. The information "Taper_X is a float&= quot; belongs to the XML schema or DTD, not to the data sent over the wire.=

What I am trying to say is that the current xxSD XML serialization migh= t look like XML, but it definitely belongs to another world from a conceptu= al point of view. It's like Canada Dry, it looks like beer, but it'= s no beer.

What you have come up with is just a rewriting of the binary serialization = that is well-formed XML. That does not make it something that fits naturall= y into XML:
=A0- LLIDL plays the same role as XML schemas or DTDs and co= uld simply be dropped.
=A0- currently, accessing the value of Taper_X from XPath is convoluted and= probably slow, compare:
=A0=A0 map/key[. =3D 'Taper_X']/followi= ng-sibling::float[position() =3D 1]=A0 with:
=A0=A0 @Taper_X
=A0- I a= lso already mentioned the higher (250%) bandwidth footprint
=A0- etc

What is the point of having a XML serialization just to hav= e it "look like" some XML, while it's not really XML?

=
OK, let's try to be positive (for once ;-) ):

I am currently= wondering if there is not an automated way to map the LLSD abstract view i= nto a real XML-ish serialization. Perhaps that would make everyone happy. T= hat would keep the very high flexibility of LLSD, have a lower angle bracke= t tax, and allow "natural" use of all XML tools. That would keep = the possibility of having three different serializations, even though I sti= ll think that it's a false good idea.

The technical problem I see with this approach is that the current LLSD= draft does not recognize the special role played by the maps in storing na= me-value pairs used by the upper layers. It does not either say that arrays= are made for vectors and quaternions, and so on. There is a lot of semanti= cs that are evacuated from this draft and that I only know for having worke= d with SL client source code as an Open Source contributor. And I don't= see how I could specify such an "intelligent" XML serialization = if such context information is missing.

(I apologize in advance if this context information is in the LLSD draf= t and I did not see it.)

--
Cathy

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--001636c599ea015ea50463c746c1-- From jwatte@gmail.com Wed Feb 25 16:55:00 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F2C28C1E7 for ; Wed, 25 Feb 2009 16:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8XM25BAHdWh for ; Wed, 25 Feb 2009 16:54:59 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id F05C728C178 for ; Wed, 25 Feb 2009 16:54:58 -0800 (PST) Received: by fxm24 with SMTP id 24so269290fxm.37 for ; Wed, 25 Feb 2009 16:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Anqtbt16zFF8Mv1SKfBwhWnyOPtFmEHLtCjBJReHHF0=; b=o+Zt14XeEzdf8SCfgSINWNOsAaqxYYqXlLCV6oJ/kdSb4JGORUie7guHdVPlm89r3Q 34VFrPtZtCxprgSYXpgqUK1Rj5hJr68Jqq8bmt/ZRJhXR6Bn9NhsvOe5kIDqsFjFBHIi X8qKmOAz3LhiKfxcyY0g56isCUdqq0AUD/I0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=O7KImbZcUqxDRft+uAOBetPJgk8Hog5QZvmmCn6YrCP8a4S62/L6/LMnmXNHFhcR19 ANpXYkxpl0tafT/WVOueQXWJpabIYv9CTDQD8CLHMcu+gX17JW6RccHL/EPGNithdtX5 jU4C4Ru0xk2WsDCmkkz6nQ1LqaRQWTMXeOcX8= Received: by 10.223.116.207 with SMTP id n15mr1502907faq.78.1235609718663; Wed, 25 Feb 2009 16:55:18 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d26sm7211065nfh.8.2009.02.25.16.55.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 16:55:17 -0800 (PST) Message-ID: <49A5E871.5040704@gmail.com> Date: Wed, 25 Feb 2009 16:55:13 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] tags X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 00:55:00 -0000 Morgaine wrote: > Even power desktops working over broadband struggle with the object > update stream, and that is mostly binary-encoded at the moment in SL > so it would be even worse with XML. But this is not an SL-only > issue. No systems anywhere benefit from adding orders of magnitude of > overhead. Does the current binary encoding encode the actual names and types of properties before sending the values? If so, you could probably cut out at least half, if not more, using the separate schema method. There are other ways to further compact the amount of data sent. In OLIVE, we use an input-synchronous, deterministic simulation model, which means we do about 9-12 users per T1 connection, including voice-over-IP (our min spec says 128 kilobits per user). I would perhaps submit this technology for standardization (with some IP disclosures), but I don't think it's actually appropriate for standardization, because it takes advantage of the fact that the client and the server run *exactly* the same simulations, which probably is not a great approach for an open standard ;-) Sincerely, jw From morgaine.dinova@googlemail.com Wed Feb 25 16:59:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFD83A6B2F for ; Wed, 25 Feb 2009 16:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-ozb725WQGU for ; Wed, 25 Feb 2009 16:59:17 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 94A413A6A9C for ; Wed, 25 Feb 2009 16:59:16 -0800 (PST) Received: by fxm24 with SMTP id 24so270213fxm.37 for ; Wed, 25 Feb 2009 16:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=oqo7pURusNAJ2DHxU0UDLxrgOSk6wkLMq18amYKBIow=; b=nj3ASjXMlgZ7hh4sEsoEOaDVbhren6r6gtR22AgOn6NpgJTq4tzxGW4uODYnBbbUKP Opt8UqeMq57Guausa+G9rWbqxyRv32/kTayNaTIoeYM7vhK+Wt8V16IqG3HJj0iX/8oU YqODKHlXRuigfgziz/eEYwXJxh95bV0DqX3Jg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AUKnKan60IC/BAv79HZhBy6KIHynIz3snGWxtqVDpFgZeyO6JCBN67TMYJhfDMaqgg /HG0G2hXJnFsbF2Zl8BKAnGfjFbgGKarq3oc0wttk0Djb6DyRkfYHvtkSWbwi5phOjqn pYoJf0VDaKmVwoWKaICiwPO6gvcdg7NMKivTQ= MIME-Version: 1.0 Received: by 10.180.242.5 with SMTP id p5mr235931bkh.124.1235609976624; Wed, 25 Feb 2009 16:59:36 -0800 (PST) In-Reply-To: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> Date: Thu, 26 Feb 2009 00:59:36 +0000 Message-ID: From: Morgaine To: Infinity Meadhbh Hamrick Content-Type: multipart/alternative; boundary=001636c5b541bcd6b10463c7dd4f Cc: mmox@ietf.org Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 00:59:18 -0000 --001636c5b541bcd6b10463c7dd4f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Feb 24, 2009 at 4:08 PM, Infinity Meadhbh Hamrick < infinity@lindenlab.com> wrote: so... what started as a pleasant little proposal to take our (the awg's) > pleasant little protocol (ogp) kick it around in public (the mmox mailing > list) and potentially generate some RFCs from it seems to have spawned a > number of discussions. _all_ of the discussions are interesting, but perhaps > not all of them are germane to the proposed task. > I suspect that this is precisely the source of many of the problems that have preoccupied MMOX discussions across many threads. Giving OGP the IETF treatment and generating some very useful RFCs is an admirable cause, an extension of AWG work, and would greatly advance interop between SL-like worlds. Unfortunately, instead of forming an OGP group, MMOX was defined as an interop group expressly targetted at providing interop across many different virtual worlds and MMO technologies. The name of the group makes this clear, and the original statements from both co-chairs endorse the broad view even more vividly. Clearly there is a disconnect between intent and presentation. In this much wider VW context, OGP can at most be one input to the process, and the end result of a successful workgroup would probably be nothing like OGP even if it incorporated some of the good ideas from it. This is the heart of the matter. The Linden goal as you describe it above is one thing, but the IETF group was set up with a totally different declared intent. I wonder if perhaps we could do both, and thus avoid the conflict: separate OGP and MMOX workgroups. An OGP workgroup would be an excellent thing to work on, and as an AWG member I would certainly like to help fill in the parts that OGP has not yet defined. But a MMOX group that targets the broader reaches of VW interop is also highly worthwhile, and much more visionary, and valuable to many more people. Morgaine. On Tue, Feb 24, 2009 at 4:08 PM, Infinity Meadhbh Hamrick < infinity@lindenlab.com> wrote: > so... what started as a pleasant little proposal to take our (the awg's) > pleasant little protocol (ogp) kick it around in public (the mmox mailing > list) and potentially generate some RFCs from it seems to have spawned a > number of discussions. _all_ of the discussions are interesting, but perhaps > not all of them are germane to the proposed task. > > so i ask.. is it appropriate to limit the discussion here to the MMOX > Charter, LLSD, OGP and HyperGrid with occasional reference to the IETF IPR > Disclosure Policy? > > to be sure... we _are_ in the stage where the charter is important to > discuss... but i'm just wondering... and these questions are here to spark > _conversation_, not radical debate. there are rational answers, pro and con, > to each of these questions and teasing them out is important... > * why would we care about HLA, DIS or IEEE-1278? they're already > standardized. (though understanding that the structure of something like OGP > differs from the structure of these protocols _is_ important.) > * why do we care about OLIVE, which is a proprietary protocol with a > single implementation? > * why do we care about MXP whose apparent dependence on another > protocol with unclear IPR encumbrance gives some people on this list the > willies. > > so the questions i pose are... > * pursuit of which of these topics brings us to our goal of an > interoperable virtual worlds? > * what does it mean to be interoperable? > * must we have early agreement on all topics before we move forward > with any component? > > * OGP (Open Grid Protocol) > * should OGP be named something else? > * how do we do the event queue? (COMET? Bayeux? RHTTP? Long Poll?) > * where do we stuff permissions in this model? > * OGP/Teleport is not HyperGrid > * LLSD > * why is LLSD different from XDR? ASN.1? Google ProtocolBuffers? > * 128 bit integers? good enough? > * should LLSD be named something else? > * XML serialization > * maps are too much like apple plists in the XML > serialization. > * MMOX Charter > * we should rename everything > * we should abandon interoperability in favor of general agreement > of model > * IETF > * Virtual Worlds in General > * Previously Established Protocols > * HLA, DIS, IEEE-1278 and related protocols > * OLIVE > * MXP? > * VRML > * Representation of virtual objects > * meshes vs. prims > * interaction models for virtual objects > * Intellectual Property Regimes for Virtual Worlds > * Creative Commons (awesome gateway to free culture or the > ultimate embodiment of evil in the noosphere?) > * DRM (the only way i'll trust you with my content or the > ultimate embodiment of evil in the noosphere?) > * permissions regime > * MPEG-21? > * must we mandate the SL-style c/m/t permission? > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --001636c5b541bcd6b10463c7dd4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 24, 2009 at 4:08 PM, Infinity Meadhb= h Hamrick <i= nfinity@lindenlab.com> wrote:

so... what started as a pleasant little proposal to take our (the awg's) pleasant little protocol (ogp) kick it around in public (the mmox mailing list) and potentially generate some RFCs from it seems to have spawned a number of discussions. _all_ of the discussions are interesting, but perhaps not all of them are germane to the proposed task.
=A0

I suspect that this is precisely the sour= ce of many of the problems that have preoccupied MMOX discussions across ma= ny threads.=A0 Giving OGP the IETF treatment and generating some very usefu= l RFCs is an admirable cause, an extension of AWG work, and would greatly a= dvance interop between SL-like worlds.

Unfortunately, instead of forming an OGP group, MMOX was defined as an = interop group expressly targetted at providing interop across many differen= t virtual worlds and MMO technologies.=A0 The name of the group makes this = clear, and the original statements from both co-chairs endorse the broad vi= ew even more vividly.

Clearly there is a disconnect between intent and presentation.

I= n this much wider VW context, OGP can at most be one input to the process, = and the end result of a successful workgroup would probably be nothing like= OGP even if it incorporated some of the good ideas from it.

This is the heart of the matter.=A0 The Linden goal as you = describe it above is one thing, but the IETF group was set up with a totall= y different declared intent.

I wonder if perhaps we could do both, a= nd thus avoid the conflict:=A0 separate OGP and MMOX workgroups.=A0 An OGP = workgroup would be an excellent thing to work on, and as an AWG member I wo= uld certainly like to help fill in the parts that OGP has not yet defined.= =A0 But a MMOX group that targets the broader reaches of VW interop is also= highly worthwhile, and much more visionary, and valuable to many more peop= le.


Morgaine.






On = Tue, Feb 24, 2009 at 4:08 PM, Infinity Meadhbh Hamrick &l= t;infinity@lindenlab.com><= /span> wrote:
so... what starte= d as a pleasant little proposal to take our (the awg's) pleasant little= protocol (ogp) kick it around in public (the mmox mailing list) and potent= ially generate some RFCs from it seems to have spawned a number of discussi= ons. _all_ of the discussions are interesting, but perhaps not all of them = are germane to the proposed task.

so i ask.. is it appropriate to limit the discussion here to the MMOX Chart= er, LLSD, OGP and HyperGrid with occasional reference to the IETF IPR Discl= osure Policy?

to be sure... we _are_ in the stage where the charter is important to discu= ss... but i'm just wondering... and these questions are here to spark _= conversation_, not radical debate. there are rational answers, pro and con,= to each of these questions and teasing them out is important...
=A0 =A0 =A0 =A0* why would we care about HLA, DIS or IEEE-1278? they'r= e already standardized. (though understanding that the structure of somethi= ng like OGP differs from the structure of these protocols _is_ important.)<= br> =A0 =A0 =A0 =A0* why do we care about OLIVE, which is a proprietary protoc= ol with a single implementation?
=A0 =A0 =A0 =A0* why do we care about MXP whose apparent dependence on ano= ther protocol with unclear IPR encumbrance gives some people on this list t= he willies.

so the questions i pose are...
=A0 =A0 =A0 =A0* pursuit of which of these topics brings us to our goal of= an interoperable virtual worlds?
=A0 =A0 =A0 =A0* what does it mean to be interoperable?
=A0 =A0 =A0 =A0* must we have early agreement on all topics before we move= forward with any component?

* OGP (Open Grid Protocol)
=A0 =A0 =A0 =A0* should OGP be named something else?
=A0 =A0 =A0 =A0* how do we do the event queue? (COMET? Bayeux? RHTTP? Long= Poll?)
=A0 =A0 =A0 =A0* where do we stuff permissions in this model?
=A0 =A0 =A0 =A0* OGP/Teleport is not HyperGrid
* LLSD
=A0 =A0 =A0 =A0* why is LLSD different from XDR? ASN.1? Google ProtocolBuf= fers?
=A0 =A0 =A0 =A0* 128 bit integers? good enough?
=A0 =A0 =A0 =A0* should LLSD be named something else?
=A0 =A0 =A0 =A0* XML serialization
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* maps are too much like apple plists in th= e XML serialization.
* MMOX Charter
=A0 =A0 =A0 =A0* we should rename everything
=A0 =A0 =A0 =A0* we should abandon interoperability in favor of general ag= reement of model
* IETF
* Virtual Worlds in General
=A0 =A0 =A0 =A0* Previously Established Protocols
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* HLA, DIS, IEEE-1278 and related protocols=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* OLIVE
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* MXP?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* VRML
=A0 =A0 =A0 =A0* Representation of virtual objects
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* meshes vs. prims
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* interaction models for virtual objects =A0 =A0 =A0 =A0* Intellectual Property Regimes for Virtual Worlds
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* Creative Commons (awesome gateway to free= culture or the ultimate embodiment of evil in the noosphere?)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* DRM (the only way i'll trust you with= my content or the ultimate embodiment of evil in the noosphere?)
=A0 =A0 =A0 =A0* permissions regime
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* MPEG-21?
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0* must we mandate the SL-style c/m/t permis= sion?
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--001636c5b541bcd6b10463c7dd4f-- From jwatte@gmail.com Wed Feb 25 17:50:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DE5528C1E7 for ; Wed, 25 Feb 2009 17:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XltH8D1FLP5m for ; Wed, 25 Feb 2009 17:50:47 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id C57D028C1C2 for ; Wed, 25 Feb 2009 17:50:47 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so317645ana.4 for ; Wed, 25 Feb 2009 17:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=m3YmdvYkJ4v2yQUSTzY+cjY+HfFssLUmfpKUdkve2F0=; b=tgDycLcpQy5RcH+2Oac54qugt12JXZgTu94vLV45M+BaH5IvJhlayBkxY1xd/rTOGr SqKd5GhCglv7CIDl/QR1AypkgNgbIrYAv3UUteYoTQLONXRKHvVWg5BFt+xI3pvsLAo5 nkLw/PK2GbOP6xIywode2BYQWKcZttVIwIBus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=iMAYhoakTBBz2AhTlw9Ztb7f19N7YVn0bzNLeLfiwUJnxkiiR3uN9J0UEE6WTox+NX h6BQN5QAxczJ/oBDpNuuMABHWT/TT0lnu2bH8rPcMb/Qtf0iepcOFO1mp+M28UwS6opb Ct2oHpTMLlq90SMWS3CmwmJnDliGNvyUDDlUM= Received: by 10.100.227.6 with SMTP id z6mr1093111ang.111.1235613068294; Wed, 25 Feb 2009 17:51:08 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d38sm3965183and.29.2009.02.25.17.51.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 17:51:07 -0800 (PST) Message-ID: <49A5F589.4090803@gmail.com> Date: Wed, 25 Feb 2009 17:51:05 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 01:50:48 -0000 Morgaine wrote: > I wonder if perhaps we could do both, and thus avoid the conflict: > separate OGP and MMOX workgroups. An OGP workgroup would be an > excellent thing to work on, and as an AWG member I would certainly > like to help fill in the parts that OGP has not yet defined. But a > MMOX group that targets the broader reaches of VW interop is also > highly worthwhile, and much more visionary, and valuable to many more > people. Why couldn't OGP stay in the AWG? And assuming that's the split, then would the Second Life people still be interested in the broader interoperability? Sincerely, jw From jwatte@gmail.com Wed Feb 25 18:18:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EC1828C258 for ; Wed, 25 Feb 2009 18:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ss6mVIoAR9R for ; Wed, 25 Feb 2009 18:18:31 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id 931F928C2CF for ; Wed, 25 Feb 2009 18:17:50 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so327089ana.4 for ; Wed, 25 Feb 2009 18:18:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=RPI3oun5aoSadGDonfiMowO/Yk6oTyZGnA/ZiKHXYDg=; b=BQEKjIvrzojBDWHxQdXCxJ0mam3AN5Dw5RujZ6VF3FssTlRNeB511w0BS1HvYR5Ilc O13e/ttrFa9Ms1DinCic7Y75fkFrP9BNGJazgmPcWUpIFhk7JsW479f0q1LBVbRb8anb QuZcyQ1OV2nkAAhQZ/Ba17NJDmj8saqXcsge8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=JB+H4t+AxKTQ7a0ucHe9KZnHYeOPq9zFHIBOg4AuHRJMUih5sMobwFueJ0SMYD9/NB C0p7pG2IjBvEoogJGxcggT6ip3MQTDfTHvybKDdY1y9+exCVJhGv13stR7tFJ0PuW+Mr 91nZ8DK56hNaLsYNTxXzjmguteyblnfxhca3Y= Received: by 10.100.197.7 with SMTP id u7mr1114363anf.96.1235614691019; Wed, 25 Feb 2009 18:18:11 -0800 (PST) Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c28sm14601594anc.25.2009.02.25.18.18.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 18:18:10 -0800 (PST) Message-ID: <49A5FBDF.3070509@gmail.com> Date: Wed, 25 Feb 2009 18:18:07 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] BoF meeting logistics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 02:18:32 -0000 I keep hearing about the BoF next month during the IETF meeting. However, I haven't been able to find any specifics, neither on the Second Life MMOX Wiki nor on the IETF web site. So: Is date, time and place for the meeting known, and if so, what is it? What do I need to do, sign up for, register, etc to attend? Sincerely, jw From morgaine.dinova@googlemail.com Wed Feb 25 18:43:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CA1D28C2A7 for ; Wed, 25 Feb 2009 18:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.062 X-Spam-Level: X-Spam-Status: No, score=-1.062 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5H6JRqBqV60 for ; Wed, 25 Feb 2009 18:43:26 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 93FE83A6783 for ; Wed, 25 Feb 2009 18:43:25 -0800 (PST) Received: by bwz26 with SMTP id 26so288950bwz.37 for ; Wed, 25 Feb 2009 18:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=cpw/065a1oVH1xISb3V2sLDgepwxf30xzSNjihKA3bg=; b=Jt89GC4iaRBa/yvPQd9NfC6rkysbegiU8F4P/r4ZPWW2aGIvsMGP1nAJkYtLiTa2Jy nnsHxE0arunNtpk9nQlkojtxKLgW/BgXaitqRW6u+kqYg7Uu+i2AlL/aTpJmv1ezRikV lAp/S4f8CxINf1idutGkbFT4Q6/TkBe8PCiqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oEibFS6u1k3Ty/tSQcObfl+H5DcFOPkmaRVMjbKsjhYAxMlW4F4QP3ujXfWckp5AMI SEvg0Da4tWYezyNXbL+2EsCmyPxuh9oRbB/dAAbNhK2R7a0rPFat36HGO7ehHWaQKRqQ ZgsQ+Xdh1WgbqXLNkr1Xy+AVROhRVhd2oDga8= MIME-Version: 1.0 Received: by 10.181.61.7 with SMTP id o7mr270961bkk.85.1235616225581; Wed, 25 Feb 2009 18:43:45 -0800 (PST) In-Reply-To: <49A5F589.4090803@gmail.com> References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> <49A5F589.4090803@gmail.com> Date: Thu, 26 Feb 2009 02:43:45 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=00163649914734595d0463c95283 Cc: mmox@ietf.org Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 02:43:27 -0000 --00163649914734595d0463c95283 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 26, 2009 at 1:51 AM, Jon Watte wrote: > Morgaine wrote: > >> I wonder if perhaps we could do both, and thus avoid the conflict: >> separate OGP and MMOX workgroups. An OGP workgroup would be an excellent >> thing to work on, and as an AWG member I would certainly like to help fill >> in the parts that OGP has not yet defined. But a MMOX group that targets >> the broader reaches of VW interop is also highly worthwhile, and much more >> visionary, and valuable to many more people. >> > > Why couldn't OGP stay in the AWG? It's not your place to deny Linden Lab the IETF standardization of their protocols, assuming that two independent reference implementations can be found. The only problem is when it's done under false pretenses. > > > And assuming that's the split, then would the Second Life people still be > interested in the broader interoperability? My belief is that yes, they would, because in addition to having people focussed on improving their current technology, Linden Lab also has many very forward-looking visionaries that can see beyond the current SL. In any case, MMOX was not formed by LL alone: IBM has extremely broad VW interests. If you wish to suggest that those two goals can sometimes be in conflict within LL, then you would be right. But if you were to suggest that it's either/or, then you would be wrong. Morgaine. On Thu, Feb 26, 2009 at 1:51 AM, Jon Watte wrote: > Morgaine wrote: > >> I wonder if perhaps we could do both, and thus avoid the conflict: >> separate OGP and MMOX workgroups. An OGP workgroup would be an excellent >> thing to work on, and as an AWG member I would certainly like to help fill >> in the parts that OGP has not yet defined. But a MMOX group that targets >> the broader reaches of VW interop is also highly worthwhile, and much more >> visionary, and valuable to many more people. >> > > Why couldn't OGP stay in the AWG? > > And assuming that's the split, then would the Second Life people still be > interested in the broader interoperability? > > Sincerely, > > jw > > --00163649914734595d0463c95283 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Feb 26, 2009 at 1:51 AM, Jon Watte <jwatte@gmail.com> wrote:
Morgaine wrote:
I wonder if perhaps we could do both, and thus avoid the conflict: =A0separate OGP and MMOX workgroups. =A0An OGP workgroup would be an excellent thing to work on, and as an AWG member I would certainly like to help fill in the parts that OGP has not yet defined. =A0But a MMOX group that targets the broader reaches of VW interop is also highly worthwhile, and much more visionary, and valuable to many more people.

Why couldn't OGP stay in the AWG?

It's not you= r place to deny Linden Lab the IETF standardization of their protocols, ass= uming that two independent reference implementations can be found.=A0=A0 Th= e only problem is when it's done under false pretenses.


And assuming that's the split, then would the Second Life people still = be interested in the broader interoperability?

My belief is that yes, they would, because in addit= ion to having people focussed on improving their current technology, Linden= Lab also has many very forward-looking visionaries that can see beyond the= current SL.=A0 In any case, MMOX was not formed by LL alone:=A0 IBM has ex= tremely broad VW interests.
=A0
If you wish to suggest that those two goals can sometimes be= in conflict within LL, then you would be right.=A0 But if you were to sugg= est that it's either/or, then you would be wrong.

Morgaine.
<= br>





On Thu, Feb 26, 2009 at = 1:51 AM, Jon Watte <jwatte@gmail.com> wrote:
Morgaine wrote:
I wonder if perhaps we could do both, and thus avoid the conflict: =A0separ= ate OGP and MMOX workgroups. =A0An OGP workgroup would be an excellent thin= g to work on, and as an AWG member I would certainly like to help fill in t= he parts that OGP has not yet defined. =A0But a MMOX group that targets the= broader reaches of VW interop is also highly worthwhile, and much more vis= ionary, and valuable to many more people.

Why couldn't OGP stay in the AWG?

And assuming that's the split, then would the Second Life people still = be interested in the broader interoperability?

Sincerely,

jw


--00163649914734595d0463c95283-- From dcolivares@gmail.com Wed Feb 25 18:56:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77D5B3A6BBF for ; Wed, 25 Feb 2009 18:56:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.66 X-Spam-Level: X-Spam-Status: No, score=-1.66 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAqHu7zMGQjo for ; Wed, 25 Feb 2009 18:56:45 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id 2E2683A6783 for ; Wed, 25 Feb 2009 18:56:45 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so174392fkf.5 for ; Wed, 25 Feb 2009 18:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mtMKGo+DAixuuahgR+wvgWIdp5fFMUl3LsqTnEXALfk=; b=uPIwtFRWLe9hwXZt1mrWVwikk0HObRkGce1KWh7wH69nnfyJ8QJzHCs9yCQmq1r0hz 3tFnTjzGSAZxo7rH4v7C0DSHRBxSCEduTt5x1qQShsE+loiOvm7VzFHA4guj4U4YU8tD 1klWbyUZVl7xJjWSdUM9lu4+PfVGA+KtWnzHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=O9eMOsymxghLG/YDa8Gx3gj9R8vg5z97wJn9cdij0yv5jiaXJs3YusDsq17Vl47p/B fkJPuD+LwmPslg7QGUcgdfLeJUlKlPMiOSsea3qIrrf5A+XH9ngyqQ/fLh1tvb2EHwjb gXdk3jid+XKLZMOFTJpr6t8OeLsuaeW9DBKZ4= MIME-Version: 1.0 Received: by 10.103.138.16 with SMTP id q16mr402632mun.114.1235617025203; Wed, 25 Feb 2009 18:57:05 -0800 (PST) In-Reply-To: References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> <49A5F589.4090803@gmail.com> Date: Wed, 25 Feb 2009 21:57:05 -0500 Message-ID: From: Dan Olivares To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org, Jon Watte Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 02:56:46 -0000 Hey there I'm interested in working on a solid virtual world interoperability standard. I admit, that if this splits up into 'awg' and a more broad standard, I'll probably attempt to participate in both (though my time is limited). And, in tern, end up implementing both. In truth, I don't think this is the best use of resources, however, it may get over the 'stigma' of 'LL'. However.. on the other side of that token, I've never heard a company back down from building a standard because other people think that they're 'big'. I think that the comments by Lisa Dussealt apply here; "A quick note on participation: individuals participate in the IETF, not companies. We have no official differentiation between somebody who works for a company that may or may not benefit from standardization or interoperability, somebody who is representing another organization, and somebody who is acting as a private individual entirely." Lets not kill future development because of company affiliations. I'm sure if Google was the market leader and they had representatives here, they wouldn't step out because other people in the proposed working group were concerned about their influence. My 2c Daniel Olivares On Wed, Feb 25, 2009 at 9:43 PM, Morgaine wrote: > On Thu, Feb 26, 2009 at 1:51 AM, Jon Watte wrote: >> >> Morgaine wrote: >>> >>> I wonder if perhaps we could do both, and thus avoid the conflict: >>> =A0separate OGP and MMOX workgroups. =A0An OGP workgroup would be an ex= cellent >>> thing to work on, and as an AWG member I would certainly like to help f= ill >>> in the parts that OGP has not yet defined. =A0But a MMOX group that tar= gets >>> the broader reaches of VW interop is also highly worthwhile, and much m= ore >>> visionary, and valuable to many more people. >> >> Why couldn't OGP stay in the AWG? > > It's not your place to deny Linden Lab the IETF standardization of their > protocols, assuming that two independent reference implementations can be > found.=A0=A0 The only problem is when it's done under false pretenses. >> >> >> And assuming that's the split, then would the Second Life people still b= e >> interested in the broader interoperability? > > My belief is that yes, they would, because in addition to having people > focussed on improving their current technology, Linden Lab also has many > very forward-looking visionaries that can see beyond the current SL.=A0 I= n any > case, MMOX was not formed by LL alone:=A0 IBM has extremely broad VW > interests. > > If you wish to suggest that those two goals can sometimes be in conflict > within LL, then you would be right.=A0 But if you were to suggest that it= 's > either/or, then you would be wrong. > > Morgaine. > > > > > > > > On Thu, Feb 26, 2009 at 1:51 AM, Jon Watte wrote: >> >> Morgaine wrote: >>> >>> I wonder if perhaps we could do both, and thus avoid the conflict: >>> =A0separate OGP and MMOX workgroups. =A0An OGP workgroup would be an ex= cellent >>> thing to work on, and as an AWG member I would certainly like to help f= ill >>> in the parts that OGP has not yet defined. =A0But a MMOX group that tar= gets >>> the broader reaches of VW interop is also highly worthwhile, and much m= ore >>> visionary, and valuable to many more people. >> >> Why couldn't OGP stay in the AWG? >> >> And assuming that's the split, then would the Second Life people still b= e >> interested in the broader interoperability? >> >> Sincerely, >> >> jw >> > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From morgaine.dinova@googlemail.com Wed Feb 25 19:23:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983903A6AF1 for ; Wed, 25 Feb 2009 19:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iL8JNUAvhtHD for ; Wed, 25 Feb 2009 19:23:28 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 7B8C03A6BB8 for ; Wed, 25 Feb 2009 19:23:27 -0800 (PST) Received: by fxm24 with SMTP id 24so301661fxm.37 for ; Wed, 25 Feb 2009 19:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=T5XkkTJMGJr6h7u+XBiddeJxaRYDPEM1nGmuNh7HF4o=; b=ZOyOHJcNyjCzSwvYgEYYk/WfEyvXccnWtWALgbccF0dEJotc/xBi+1jPqkva4dv9vG SlDBbcd83BvQ2AhaQ2g3oI+OvBTEvGqSP5oPO4GRn4RvT2zhnQL1P65aTw2A6OLxgk4T EXy3jF6B3Skk4Kf0V4mzKIh5xVbT51J4Sjlwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LyAB3lSzhvcVLVa5Rr65cwFB87YfpTr1s22/12YEfVM9aWs25d8IFGpT6UGPEu7JjG JUDVV5HuwnhsqAezUXbaY7+S9b8N1OHKKX8JdCdAZJgWyasdgq7FgC7tSdRWhmknf93G Kmj+EXEi6bcWW30qtRy+o1wgCOXyJmfDQZi7M= MIME-Version: 1.0 Received: by 10.181.147.3 with SMTP id z3mr287736bkn.17.1235618626235; Wed, 25 Feb 2009 19:23:46 -0800 (PST) In-Reply-To: References: <49A4A8FA.607@gmail.com> <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> <497C7FD9-BF36-458F-98C0-BEECAE611E1A@lindenlab.com> <06CF9E4E-6C20-46CB-B092-68F702C2E185@lindenlab.com> Date: Thu, 26 Feb 2009 03:23:46 +0000 Message-ID: From: Morgaine To: Ewen Cheslack-Postava Content-Type: multipart/alternative; boundary=0016364581984b6ee90463c9e123 Cc: mmox@ietf.org Subject: Re: [mmox] The Structure and Interpretation of LLSD Messages [Was: Re: unefficient binary serialization ?] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 03:23:31 -0000 --0016364581984b6ee90463c9e123 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Feb 25, 2009 at 7:19 PM, Ewen Cheslack-Postava wrote: > > I do appreciate the possibility of having a unified data type system > with multiple serialization backends, which would allow for protocol > gateways like that to be fairly trivially implemented. It would just > be a decode->encode in new format. > While such gateways are fine for non-interactive streaming downloads, unfortunately they introduce latency that can ruin the interactive experience. Given that the run-time bloat of having multiple simultaneously active serializations is very minor, it's best to avoid the latency by integrating them as loadable modules at source, so that no translating gateway is needed. Morgaine. On Wed, Feb 25, 2009 at 7:19 PM, Ewen Cheslack-Postava wrote: > On Wed, Feb 25, 2009 at 9:10 AM, Meadhbh Hamrick (Infinity) > wrote: > > i'm relying on rusty neurons to make this assertion, but i think protocol > > buffers will fail if you parse a message with an additional required > member. > > Required/optional is only specified in the IDL. Whether a field is > required is not present in the wire protocol, so the receiving end > would have no way to tell if the unknown field was required by the > sending end. > > > > > but this isn't that big of a deal since we like optional members in LLSD. > > > > but i'm also at a bit of a loss for figuring out how to represent variant > > records with GPB. > > There's no general variant type, but its easy to build one for the > receiving end. > > message Variant { > } > > Everything included in it will simply be pushed to an UnknownFieldSet, > and the complete structure will be maintained. > > However, variants are of debatable use at best. General variants > really aren't that great because you can't rely on their content. I > would think it would generally be better to actually specify the > possible types of data: > > message Name { > optional string string_name = 1; > optional uint32 predefined_name = 2; > } > > If you don't do this, you get stuck with extensibility problems. > Suppose I used the Variant version and I wanted to now support > specifying first and last name separately. The only information I > have about the meaning of the variable is its data type, string. Now > the old system gets a message with 2 strings (or 3 strings, if you > also specify the whole name) in it and has no idea what to do or which > to use. The best you can do is hope that the ordering is nice and > take the first (or maybe the last? seeing the problem with this?). > With pb you could just update it to be > > message Name { > optional string string_name = 1; > optional uint32 predefined_name = 2; > optional string first_name = 3; > optional string last_name = 4; > } > > The multiple strings are not ambiguous. So long as new systems > implementing this also specify the string_name parameter, then > everything works fine between the two. If the updated system so > desires, it could have rules to automatically generate first_name and > last_name from string_name. > > > > > which is to say, i'm sure it can be done and i'm pretty sure it "won't be > > pretty" in the sense that to support variants, you may have to do things > > that avoid using the innate structure representation of GPB. > > If you're referring to the fact that protocol buffers are strongly > typed, then sure, you're avoiding the innate structure representation > of protocol buffers. The point is they thought about this and > provided the tools to handle this when you don't know the structure. > Are you suggesting LLSD does something better in this regard? It > seems to me that, by definition, you can't do anything better since > you don't know the structure of the data. > > > > > and at that point, unless google (or someone else) is opening up an LLSD > > service, maybe the thing to do would be to have a protocol gateway that > > takes LLSD style PDUs in one side and emits GPB messages out the other. > > I do appreciate the possibility of having a unified data type system > with multiple serialization backends, which would allow for protocol > gateways like that to be fairly trivially implemented. It would just > be a decode->encode in new format. > > -Ewen > > > > > On Feb 24, 2009, at 11:27 PM, Ewen Cheslack-Postava wrote: > > > >> Maybe I'm just overlooking something, but how is this a problem? It > >> looks like you added an enum and an optional field using that enum > >> type to the PhoneNumber message type. Why would the serialization > >> engine would fail? It ignores key value pairs it doesn't understand. > >> The encoding provides sufficient type/size information to skip the > >> field without understanding its contents. In fact, it will even > >> collect those fields up and deliver them to you so you can try to use > >> them. Protocol Buffers was designed (or probably more accurately, > >> evolved) to support backwards and forwards compatibility. This is > >> especially critical for google because they do slow rollouts of > >> updated services, so they, at a minimum, have to be compatible between > >> consecutive versions of their protocols. > >> > >> That being said, you certainly do have to be careful about > >> compatibility when updating a message type or creating a new message > >> that might be upgraded in the future. For instance, there are quite a > >> few people who use optional by default so that its possible to remove > >> fields if they are no longer necessary. But this is true for all > >> serializations, so I wouldn't count that as a negative mark against > >> protocol buffers. In fact, I'd say its an argument for it that it can > >> handle it (as can LLSD, Thrift, XML, etc). > >> > >> -Ewen > >> > >> On Tue, Feb 24, 2009 at 11:06 PM, Meadhbh Hamrick (Infinity) > >> wrote: > >>> > >>> imagine you have a .proto file like: > >>> > >>> message Person { > >>> required string name = 1; > >>> required int32 id = 2; > >>> optional string email = 3; > >>> > >>> enum PhoneType { > >>> MOBILE = 0; > >>> HOME = 1; > >>> WORK = 2; > >>> } > >>> > >>> message PhoneNumber { > >>> required string number = 1; > >>> optional PhoneType type = 2 [default = HOME]; > >>> } > >>> > >>> repeated PhoneNumber phone = 4; > >>> } > >>> > >>> and the next rev of the protocol is: > >>> > >>> message Person { > >>> required string name = 1; > >>> required int32 id = 2; > >>> optional string email = 3; > >>> > >>> enum PhoneType { > >>> MOBILE = 0; > >>> HOME = 1; > >>> WORK = 2; > >>> } > >>> > >>> enum PhoneUsage { > >>> > >>> VOICE = 0; > >>> > >>> FAX = 1; > >>> > >>> MODEM = 2; > >>> > >>> } > >>> message PhoneNumber { > >>> required string number = 1; > >>> optional PhoneType type = 2 [default = HOME]; > >>> > >>> optional PhoneUsage type = 3 [default = VOICE]; > >>> } > >>> > >>> repeated PhoneNumber phone = 4; > >>> } > >>> > >>> the problem is that if a endpoint expecting the former consumes the > >>> latter, > >>> the serialization engine barfs. and you (in the application layer) > don't > >>> receive the message in order to try to pick it apart manually (which > kind > >>> of > >>> defeats the purpose of the serialization.) > >>> however, it _is_ an open source project, so we could probably create a > >>> version of the library that adds a "fail silently" mode. > >>> there are also semantics for extending messages, so maybe.. i'd have to > >>> look > >>> at it a little more before passing judgement. > >>> > >>> On Feb 24, 2009, at 10:45 PM, Morgaine wrote: > >>> > >>> Excellent background on LLSD, Infinity! It raises a question: > >>> > >>> On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) > >>> wrote: > >>> > >>> while we have a metric tonne of code that uses the existing LLSD DTD, > >>> ultimately, any additional serialization format that preserves these > >>> processing expectations could be wedged into the system. serialization > >>> formats that did not support these processing expectations would cause > >>> considerable heart burn. > >>> > >>> > >>> One serialization format that many have mentioned here is Google's > >>> Protocol > >>> Buffers. While I have barely started to examine PB myself, it is very > >>> clear > >>> that this serialization is extraordinarily efficient on-the-wire and > also > >>> at > >>> both ends of the wire, as well as catering for the continual change > that > >>> is > >>> inherent in large, evolving systems. A interest in extending the 3-way > >>> serialization of XXSD to Protocol Buffers follows naturally. > >>> > >>> The question that is raised by the quoted paragraph is whether Protocol > >>> Buffers "preserves these processing expectations". If it does then > >>> extending the set of serializations to PB is work that could be done by > >>> those interested in it, as an open project, and picked up by other > users > >>> of > >>> XXSD if they wish. Potentially, the acceleration could be quite > >>> significant, and hence the benefit to Limited Capability Clients very > >>> important. > >>> > >>> On the other hand, if it does not "preserve these processing > >>> expectations" > >>> then there could be a problem. > >>> > >>> Do Lindens (or anyone else here) have any insight on this? > >>> > >>> Morgaine. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) > >>> wrote: > >>> but here's one reason we like LLSD... > >>> > >>> imagine you have two systems that are interoperating... one is owned my > >>> me, > >>> the other is owned by catherine. > >>> > >>> cathy's customers are all banks and insurance companies and are very > >>> conservative, so cathy want's to err on the side of caution in terms of > >>> when > >>> she deploys new features. > >>> > >>> i on the other hand throw caution to the wind because my customers are > >>> all > >>> first person shooter fanatics between the ages of 13 and 21 who demand > >>> the > >>> latest features as soon as possible (otherwise they use david's server) > >>> > >>> it's not hard to see we're eventually going to introduce version slew > >>> which > >>> will make it difficult for cathy and i to participate in the > unregulated > >>> business of marketing virtual life insurance policies to my customers. > in > >>> this example, i'm trying to point out that the both the option to > retain > >>> version parity with cathy and the option to upgrade to the latest > version > >>> are not without drawbacks. > >>> > >>> now.. imagine we have a PDU with three members while the second version > >>> adds > >>> a member. for simplicity's sake, let's say they're all integers. > >>> > >>> if used the DTD to define the validation for the message, the first > >>> version > >>> of the message might look like: > >>> > >>> > >>> >>> 1.0//EN" "http://example.com/pdu/1.0/pdutastic.dtd"> > >>> > >>> 13 > >>> 42 > >>> 93 > >>> > >>> > >>> while the new version would look like this: > >>> > >>> > >>> >>> 1.1//EN" "http://example.com/pdu/1.1/pdutastic.dtd"> > >>> > >>> 13 > >>> 42 > >>> 93 > >>> 161 > >>> > >>> > >>> so when i (expecting the new version) consume the old version, i do not > >>> see > >>> qux. but my parser doesn't complain because instead of the DTD of the > new > >>> PDU, i see a reference to the old PDU and say to myself... "it's > okay... > >>> it's just an older version," and i do whatever i have to do to continue > >>> processing in the absence of the qux member i was expecting. even if > i'm > >>> doing validation, it's okay, i'm pulling the DTD from the old > definition, > >>> so > >>> we're cool. > >>> > >>> now... when cathy consumes the new PDU, something similar happens. she > >>> see's > >>> a DTD she's not familiar with, but it's all good.. she grabs teh DTD > from > >>> URL specified in teh DOCTYPE and moves on with her life, hoping that > new > >>> version PDU didn't change the semantics of the three values (foo, bar > and > >>> baz) she's familiar with. > >>> > >>> and then one day she receives this from david: > >>> > >>> > >>> >>> 1.2//EN" "http://example.com/pdu/1.2/pdutastic.dtd"> > >>> > >>> 13 > >>> 2008-12-15T13:17:23.235Z > >>> 93 > >>> 161 > >>> > >>> > >>> aha! david, trying to steal my core demographic away from me has > upgraded > >>> to > >>> the most recent beta version of the software (now with 13% more > >>> explosions) > >>> > >>> but this is now a serious problem for cathy. the "shape" of the > >>> structured > >>> data now does not match. what does she do? how does she convert that > date > >>> into an integer? > >>> > >>> and this is the question we keep running into as we deploy "loosely > >>> coupled" > >>> systems. how do we fail gracefully and ensure robustness in the > presence > >>> of > >>> PDU schema mismatches? > >>> > >>> the way linden answered this question was to develop LLSD, an abstract > >>> type > >>> system with conversions and defaults. > >>> > >>> the way we would probably have defined the message above would have > been > >>> something like: > >>> > >>> > >>> > >>> > >>> foo > >>> 13 > >>> bar > >>> 2008-12-15T13:17:23.235Z > >>> baz > >>> 93 > >>> qux > >>> 161 > >>> > >>> > >>> > >>> we don't include the doctype id 'cause our DTD never changes. in this > >>> example the LLSD message is shorter 'cause we don't include the DOCTYPE > >>> id, > >>> but even after removing the DOCTYPE id and changing the outer element > to > >>> llsd, the compressed version of the LLSD message is only seven bytes > >>> larger. > >>> (an increase from 154 bytes to 161 bytes, an efficiency loss of 4.5%) > >>> however, i can guarantee you that it took a lot less time to code the > >>> parser > >>> because.. well.. we already had a parser that knew how to unwrap LLSD > >>> messages. > >>> > >>> but we haven't got to the interesting part yet. > >>> > >>> there is a processing expectation with LLSD. we assume we're > >>> de-serializing > >>> a message into a dynamic language like ECMAScript or Python. For > >>> languages > >>> like C++ and Java we create a class that emulates this feature. so.. > all > >>> LLSD PDUs are de-serialized into these LLSD objects, and inside our > >>> application(s), it's these objects that get passed around. so we might > >>> have > >>> code that looks like: > >>> > >>> public foo ( string message ) { > >>> LLSD llsd; > >>> > >>> llsd = LLSD.From( message, LLSD.XML_SERIALIZATION ); > >>> > >>> System.err.println( "hey! foo was %d.\n", (int) llsd.at( "foo" > >>> ).asInteger() ); > >>> > >>> if( ( (int) llsd.at("bar").asInteger() > 100 ) || ( (int) > >>> llsd.at("bar").asInteger() < 0 ) ) { > >>> System.err.println( "bar is not a percentage\n" ); > >>> System.haltAndCatchFire(); > >>> } > >>> > >>> > >>> if( (int) llsd.at("bar").asInteger() < 40 ) { > >>> System.err.println( "sorry, this percent margin is way > too > >>> small for me to be interested.\n" ); > >>> System.haltAndCatchFire(); > >>> } > >>> . > >>> . > >>> . > >>> } > >>> > >>> forgive the javaisms, the alternative was smalltalk and well... let's > not > >>> go > >>> there. > >>> > >>> for the sake of argument let's say we had already determined it was in > >>> XML > >>> format by looking at the Content-Type: header from the request. > >>> > >>> so what we're doing here is not out of the ordinary... we create an > >>> instance > >>> of the LLSD class from the serialization. > >>> > >>> and we print some logging messages. > >>> > >>> and we then try to see if bar is between 0 an 100. > >>> > >>> but the object representing "foo" is a date, not an integer. what > >>> happens? > >>> > >>> in our current implementation of LLSD, we attempt to convert, but > notice > >>> that the conversion from date to integer has no semantic meaning. > >>> because > >>> the conversion is "illegal," the default value is returned. > >>> > >>> the result of running this fragment would be something like > >>> > >>> hey! foo was 0. > >>> sorry, this percent margin is way too small for me to be > >>> interested. > >>> > >>> the important feature here is that we did not allow the "presentation > >>> layer" > >>> to create an error. we did the best we could to interpret the sense of > >>> the > >>> message, even to the point of making a nonsensical conversion. we allow > >>> this > >>> to happen because we assume that at the application layer, we're going > to > >>> do > >>> parameter checking. so the reasoning was... if we're going to be doing > >>> parameter checking anyway, why would we want to allow the presentation > >>> layer > >>> to fail a message that would have generated a result that could be > >>> checked > >>> at the application layer? > >>> > >>> i hope you've enjoyed this installment of "the structure and > >>> interpretation > >>> of LLSD messages." and i hope it helps explain our motivations for > >>> designing > >>> LLSD and it's serializations the way we did... and while we have a > metric > >>> tonne of code that uses the existing LLSD DTD, ultimately, any > additional > >>> serialization format that preserves these processing expectations could > >>> be > >>> wedged into the system. serialization formats that did not support > these > >>> processing expectations would cause considerable heart burn. > >>> > >>> -cheers > >>> -meadhbh > >>> > >>> On Feb 24, 2009, at 6:12 PM, Jon Watte wrote: > >>> > >>> Catherine Pfeffer wrote: > >>> That's precisely all the HUGE strength of LLSD. Having information > about > >>> what the data is intermingled with the data itself makes it very > flexible > >>> and future-proof. > >>> But that is simply not necessary. If you transmit a reference to the > >>> schema > >>> you use when you initiate connection, then all future transmissions > >>> during > >>> that connection session can use the knowledge of that schema to highly > >>> optimize traffic. Network traffic is actually one of the scarce > resources > >>> when you start scaling up really large virtual worlds. There are cases > >>> where > >>> an entire office (20 people or more) share a single T1 connection to > the > >>> Internet, and expect to have a good virtual world experience for > multiple > >>> users at the same time. > >>> > >>> > >>> Honestly, here, the bandwidth is not lost, compared to the advantages. > >>> > >>> > >>> I think it is, because the size difference is quite significant. > >>> > >>> In summary, their binary serialization is as flexible as XML data. > >>> Perhaps > >>> I'm wrong, but to me it's an unique case in all computer science of a > >>> binary > >>> format that would be so flexible. > >>> > >>> Don't overextend yourself :-) AIFF/RIFF has pretty much the same > >>> flexibility, as does TLV (also used in OSCAR), a number of "binary XML" > >>> proposals, and a number of protocols that have all done more or less > the > >>> same thing ever since computers were interconnected on a larger scale > in > >>> the > >>> '80s. > >>> > >>> Sincerely, > >>> > >>> jw > >>> > >>> _______________________________________________ > >>> mmox mailing list > >>> mmox@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmox > >>> > >>> _______________________________________________ > >>> mmox mailing list > >>> mmox@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmox > >>> > >>> > >>> > >>> _______________________________________________ > >>> mmox mailing list > >>> mmox@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmox > >>> > >>> > > > > > --0016364581984b6ee90463c9e123 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 25, 2009 at 7:19 PM, Ewen Cheslack-P= ostava <ewencp@gmail.com> wrote:

I do appreciate the possibility of having a unified data type system with multiple serialization backends, which would allow for protocol
gateways like that to be fairly trivially implemented. =A0It would just
be a decode->encode in new format.


While such gateway= s are fine for non-interactive streaming downloads, unfortunately they intr= oduce latency that can ruin the interactive experience.=A0 Given that the r= un-time bloat of having multiple simultaneously active serializations is ve= ry minor, it's best to avoid the latency by integrating them as loadabl= e modules at source, so that no translating gateway is needed.

Morgaine.



=A0



On Wed, Feb 25, 2009 at 7:19 PM, Ewen Cheslack-Postava <ewencp@gmai= l.com> wrote:
On Wed, Feb 25, 2009 at 9:10 AM, Meadhbh Hamrick (Infinity)
<infinity@li= ndenlab.com> wrote:
> i'm relying on rusty neurons to make this assertion, but i think p= rotocol
> buffers will fail if you parse a message with an additional required m= ember.

Required/optional is only specified in the IDL. Whether a field is required is not present in the wire protocol, so the receiving end
would have no way to tell if the unknown field was required by the
sending end.

>
> but this isn't that big of a deal since we like optional members i= n LLSD.
>
> but i'm also at a bit of a loss for figuring out how to represent = variant
> records with GPB.

There's no general variant type, but its easy to build one for th= e
receiving end.

message Variant {
}

Everything included in it will simply be pushed to an UnknownFieldSet,
and the complete structure will be maintained.

However, variants are of debatable use at best. =A0General variants
really aren't that great because you can't rely on their content. = =A0I
would think it would generally be better to actually specify the
possible types of data:

message Name {
=A0optional string string_name =3D 1;
=A0optional uint32 predefined_name =3D 2;
}

If you don't do this, you get stuck with extensibility problems.
Suppose I used the Variant version and I wanted to now support
specifying first and last name separately. =A0The only information I
have about the meaning of the variable is its data type, string. =A0Now
the old system gets a message with 2 strings (or 3 strings, if you
also specify the whole name) in it and has no idea what to do or which
to use. =A0The best you can do is hope that the ordering is nice and
take the first (or maybe the last? seeing the problem with this?).
With pb you could just update it to be

message Name {
=A0optional string string_name =3D 1;
=A0optional uint32 predefined_name =3D 2;
=A0optional string first_name =3D 3;
=A0optional string last_name =3D 4;
}

The multiple strings are not ambiguous. =A0So long as new systems
implementing this also specify the string_name parameter, then
everything works fine between the two. =A0If the updated system so
desires, it could have rules to automatically generate first_name and
last_name from string_name.

>
> which is to say, i'm sure it can be done and i'm pretty sure i= t "won't be
> pretty" in the sense that to support variants, you may have to do= things
> that avoid using the innate structure representation of GPB.

If you're referring to the fact that protocol buffers are strongl= y
typed, then sure, you're avoiding the innate structure representation of protocol buffers. =A0The point is they thought about this and
provided the tools to handle this when you don't know the structure. Are you suggesting LLSD does something better in this regard? =A0It
seems to me that, by definition, you can't do anything better since
you don't know the structure of the data.

>
> and at that point, unless google (or someone else) is opening up an LL= SD
> service, maybe the thing to do would be to have a protocol gateway tha= t
> takes LLSD style PDUs in one side and emits GPB messages out the other= .

I do appreciate the possibility of having a unified data type system<= br> with multiple serialization backends, which would allow for protocol
gateways like that to be fairly trivially implemented. =A0It would just
be a decode->encode in new format.

-Ewen

>
> On Feb 24, 2009, at 11:27 PM, Ewen Cheslack-Postava wrote:
>
>> Maybe I'm just overlooking something, but how is this a proble= m? =A0It
>> looks like you added an enum and an optional field using that enum=
>> type to the PhoneNumber message type. =A0Why would the serializati= on
>> engine would fail? =A0It ignores key value pairs it doesn't un= derstand.
>> The encoding provides sufficient type/size information to skip the=
>> field without understanding its contents. In fact, it will even >> collect those fields up and deliver them to you so you can try to = use
>> them. Protocol Buffers was designed (or probably more accurately,<= br> >> evolved) to support backwards and forwards compatibility. =A0This = is
>> especially critical for google because they do slow rollouts of >> updated services, so they, at a minimum, have to be compatible bet= ween
>> consecutive versions of their protocols.
>>
>> That being said, you certainly do have to be careful about
>> compatibility when updating a message type or creating a new messa= ge
>> that might be upgraded in the future. =A0For instance, there are q= uite a
>> few people who use optional by default so that its possible to rem= ove
>> fields if they are no longer necessary. =A0But this is true for al= l
>> serializations, so I wouldn't count that as a negative mark ag= ainst
>> protocol buffers. =A0In fact, I'd say its an argument for it t= hat it can
>> handle it (as can LLSD, Thrift, XML, etc).
>>
>> -Ewen
>>
>> On Tue, Feb 24, 2009 at 11:06 PM, Meadhbh Hamrick (Infinity)
>> <in= finity@lindenlab.com> wrote:
>>>
>>> imagine you have a .proto file like:
>>>
>>> message Person {
>>> =A0required string name =3D 1;
>>> =A0required int32 id =3D 2;
>>> =A0optional string email =3D 3;
>>>
>>> =A0enum PhoneType {
>>> =A0 MOBILE =3D 0;
>>> =A0 HOME =3D 1;
>>> =A0 WORK =3D 2;
>>> =A0}
>>>
>>> =A0message PhoneNumber {
>>> =A0 required string number =3D 1;
>>> =A0 optional PhoneType type =3D 2 [default =3D HOME];
>>> =A0}
>>>
>>> =A0repeated PhoneNumber phone =3D 4;
>>> }
>>>
>>> and the next rev of the protocol is:
>>>
>>> message Person {
>>> =A0required string name =3D 1;
>>> =A0required int32 id =3D 2;
>>> =A0optional string email =3D 3;
>>>
>>> =A0enum PhoneType {
>>> =A0 MOBILE =3D 0;
>>> =A0 HOME =3D 1;
>>> =A0 WORK =3D 2;
>>> =A0}
>>>
>>> =A0enum PhoneUsage {
>>>
>>> =A0 VOICE =3D 0;
>>>
>>> =A0 FAX =3D 1;
>>>
>>> =A0 MODEM =3D 2;
>>>
>>> =A0}
>>> =A0message PhoneNumber {
>>> =A0 required string number =3D 1;
>>> =A0 optional PhoneType type =3D 2 [default =3D HOME];
>>>
>>> =A0 optional PhoneUsage type =3D 3 [default =3D VOICE];
>>> =A0}
>>>
>>> =A0repeated PhoneNumber phone =3D 4;
>>> }
>>>
>>> the problem is that if a endpoint expecting the former consume= s the
>>> latter,
>>> the serialization engine barfs. and you (in the application la= yer) don't
>>> receive the message in order to try to pick it apart manually = (which kind
>>> of
>>> defeats the purpose of the serialization.)
>>> however, it _is_ an open source project, so we could probably = create a
>>> version of the library that adds a "fail silently" m= ode.
>>> there are also semantics for extending messages, so maybe.. i&= #39;d have to
>>> look
>>> at it a little more before passing judgement.
>>>
>>> On Feb 24, 2009, at 10:45 PM, Morgaine wrote:
>>>
>>> Excellent background on LLSD, Infinity! =A0It raises a questio= n:
>>>
>>> On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) >>> <infinity@lindenlab.com> wrote:
>>>
>>> while we have a metric tonne of code that uses the existing LL= SD DTD,
>>> ultimately, any additional serialization format that preserves= these
>>> processing expectations could be wedged into the system. seria= lization
>>> formats that did not support these processing expectations wou= ld cause
>>> considerable heart burn.
>>>
>>>
>>> One serialization format that many have mentioned here is Goog= le's
>>> Protocol
>>> Buffers. =A0While I have barely started to examine PB myself, = it is very
>>> clear
>>> that this serialization is extraordinarily efficient on-the-wi= re and also
>>> at
>>> both ends of the wire, as well as catering for the continual c= hange that
>>> is
>>> inherent in large, evolving systems. =A0A interest in extendin= g the 3-way
>>> serialization of XXSD to Protocol Buffers follows naturally. >>>
>>> The question that is raised by the quoted paragraph is whether= Protocol
>>> Buffers "preserves these processing expectations". = =A0If it does then
>>> extending the set of serializations to PB is work that could b= e done by
>>> those interested in it, as an open project, and picked up by o= ther users
>>> of
>>> XXSD if they wish. =A0Potentially, the acceleration could be q= uite
>>> significant, and hence the benefit to Limited Capability Clien= ts very
>>> important.
>>>
>>> On the other hand, if it does not "preserve these process= ing
>>> expectations"
>>> then there could be a problem.
>>>
>>> Do Lindens (or anyone else here) have any insight on this?
>>>
>>> Morgaine.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Feb 25, 2009 at 5:41 AM, Meadhbh Hamrick (Infinity) >>> <infinity@lindenlab.com> wrote:
>>> but here's one reason we like LLSD...
>>>
>>> imagine you have two systems that are interoperating... one is= owned my
>>> me,
>>> the other is owned by catherine.
>>>
>>> cathy's customers are all banks and insurance companies an= d are very
>>> conservative, so cathy want's to err on the side of cautio= n in terms of
>>> when
>>> she deploys new features.
>>>
>>> i on the other hand throw caution to the wind because my custo= mers are
>>> all
>>> first person shooter fanatics between the ages of 13 and 21 wh= o demand
>>> the
>>> latest features as soon as possible (otherwise they use david&= #39;s server)
>>>
>>> it's not hard to see we're eventually going to introdu= ce version slew
>>> which
>>> will make it difficult for cathy and i to participate in the u= nregulated
>>> business of marketing virtual life insurance policies to my cu= stomers. in
>>> this example, i'm trying to point out that the both the op= tion to retain
>>> version parity with cathy and the option to upgrade to the lat= est version
>>> are not without drawbacks.
>>>
>>> now.. imagine we have a PDU with three members while the secon= d version
>>> adds
>>> a member. for simplicity's sake, let's say they're= all integers.
>>>
>>> if used the DTD to define the validation for the message, the = first
>>> version
>>> of the message might look like:
>>>
>>> <?xml version=3D"1.0"?>
>>> <!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined De= rivatives ML PDU
>>> 1.0//EN" "http://example.com/pdu/1.0/pdutastic.dtd&q= uot;>
>>> <pdutastic>
>>> =A0<foo type=3D"integer">13</foo>
>>> =A0<bar type=3D"integer">42</bar>
>>> =A0<baz type=3D"integer">93</baz>
>>> </pdutastic>
>>>
>>> while the new version would look like this:
>>>
>>> <?xml version=3D"1.0"?>
>>> <!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined De= rivatives ML PDU
>>> 1.1//EN" "http://example.com/pdu/1.1/pdutastic.dtd&q= uot;>
>>> <pdutastic>
>>> =A0<foo type=3D"integer">13</foo>
>>> =A0<bar type=3D"integer">42</bar>
>>> =A0<baz type=3D"integer">93</baz>
>>> =A0<qux type=3D"integer">161</qux>
>>> </pdutastic>
>>>
>>> so when i (expecting the new version) consume the old version,= i do not
>>> see
>>> qux. but my parser doesn't complain because instead of the= DTD of the new
>>> PDU, i see a reference to the old PDU and say to myself... &qu= ot;it's okay...
>>> it's just an older version," and i do whatever i have= to do to continue
>>> processing in the absence of the qux member i was expecting. e= ven if i'm
>>> doing validation, it's okay, i'm pulling the DTD from = the old definition,
>>> so
>>> we're cool.
>>>
>>> now... when cathy consumes the new PDU, something similar happ= ens. she
>>> see's
>>> a DTD she's not familiar with, but it's all good.. she= grabs teh DTD from
>>> URL specified in teh DOCTYPE and moves on with her life, hopin= g that new
>>> version PDU didn't change the semantics of the three value= s (foo, bar and
>>> baz) she's familiar with.
>>>
>>> and then one day she receives this from david:
>>>
>>> <?xml version=3D"1.0"?>
>>> <!DOCTYPE pdutastic PUBLIC "-//MMOX//Poorly Defined De= rivatives ML PDU
>>> 1.2//EN" "http://example.com/pdu/1.2/pdutastic.dtd&q= uot;>
>>> <pdutastic>
>>> =A0<foo type=3D"integer">13</foo>
>>> =A0<bar type=3D"date">2008-12-15T13:17:23.235Z= </bar>
>>> =A0<baz type=3D"integer">93</baz>
>>> =A0<qux type=3D"integer">161</qux>
>>> </pdutastic>
>>>
>>> aha! david, trying to steal my core demographic away from me h= as upgraded
>>> to
>>> the most recent beta version of the software (now with 13% mor= e
>>> explosions)
>>>
>>> but this is now a serious problem for cathy. the "shape&q= uot; of the
>>> structured
>>> data now does not match. what does she do? how does she conver= t that date
>>> into an integer?
>>>
>>> and this is the question we keep running into as we deploy &qu= ot;loosely
>>> coupled"
>>> systems. how do we fail gracefully and ensure robustness in th= e presence
>>> of
>>> PDU schema mismatches?
>>>
>>> the way linden answered this question was to develop LLSD, an = abstract
>>> type
>>> system with conversions and defaults.
>>>
>>> the way we would probably have defined the message above would= have been
>>> something like:
>>>
>>> <?xml version=3D"1.0"?>
>>> <llsd>
>>> =A0<map>
>>> =A0 <key>foo</key>
>>> =A0 <integer>13</integer>
>>> =A0 <key>bar</key>
>>> =A0 <date>2008-12-15T13:17:23.235Z</date>
>>> =A0 <key>baz</key>
>>> =A0 <integer>93</integer>
>>> =A0 <key>qux</key>
>>> =A0 <integer>161</integer>
>>> =A0</map>
>>> </llsd>
>>>
>>> we don't include the doctype id 'cause our DTD never c= hanges. in this
>>> example the LLSD message is shorter 'cause we don't in= clude the DOCTYPE
>>> id,
>>> but even after removing the DOCTYPE id and changing the outer = element to
>>> llsd, the compressed version of the LLSD message is only seven= bytes
>>> larger.
>>> (an increase from 154 bytes to 161 bytes, an efficiency loss o= f 4.5%)
>>> however, i can guarantee you that it took a lot less time to c= ode the
>>> parser
>>> because.. well.. we already had =A0a parser that knew how to u= nwrap LLSD
>>> messages.
>>>
>>> but we haven't got to the interesting part yet.
>>>
>>> there is a processing expectation with LLSD. we assume we'= re
>>> de-serializing
>>> a message into a dynamic language like ECMAScript or Python. F= or
>>> languages
>>> like C++ and Java we create a class that emulates this feature= . so.. all
>>> LLSD PDUs are de-serialized into these LLSD objects, and insid= e our
>>> application(s), it's these objects that get passed around.= so we might
>>> have
>>> code that looks like:
>>>
>>> public foo ( string message ) {
>>> =A0 =A0 =A0 LLSD llsd;
>>>
>>> =A0 =A0 =A0 llsd =3D LLSD.From( message, LLSD.XML_SERIALIZATIO= N );
>>>
>>> =A0 =A0 =A0 System.err.println( "hey! foo was %d.\n"= , (int) llsd.at( "foo= "
>>> ).asInteger() );
>>>
>>> =A0 =A0 =A0 if( ( (int) llsd.at("bar").asInteger() > 100 ) || ( (int)
>>> llsd.at("= ;bar").asInteger() < 0 ) ) {
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 System.err.println( "bar is n= ot a percentage\n" );
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 System.haltAndCatchFire();
>>> =A0 =A0 =A0 }
>>>
>>>
>>> =A0 =A0 =A0 if( (int) llsd.at("bar").asInteger() < 40 ) {
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 System.err.println( "sorry, t= his percent margin is way too
>>> small for me to be interested.\n" );
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 System.haltAndCatchFire();
>>> =A0 =A0 =A0 }
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 .
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 .
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 .
>>> }
>>>
>>> forgive the javaisms, the alternative was smalltalk and well..= . let's not
>>> go
>>> there.
>>>
>>> for the sake of argument let's say we had already determin= ed it was in
>>> XML
>>> format by looking at the Content-Type: header from the request= .
>>>
>>> so what we're doing here is not out of the ordinary... we = create an
>>> instance
>>> of the LLSD class from the serialization.
>>>
>>> and we print some logging messages.
>>>
>>> and we then try to see if bar is between 0 an 100.
>>>
>>> but the object representing "foo" is a date, not an = integer. what
>>> happens?
>>>
>>> in our current implementation of LLSD, we attempt to convert, = but notice
>>> that the conversion from date to integer has no semantic meani= ng.
>>> =A0because
>>> the conversion is "illegal," the default value is re= turned.
>>>
>>> the result of running this fragment would be something like >>>
>>> =A0 =A0 =A0 hey! foo was 0.
>>> =A0 =A0 =A0 sorry, this percent margin is way too small for me= to be
>>> interested.
>>>
>>> the important feature here is that we did not allow the "= presentation
>>> layer"
>>> to create an error. we did the best we could to interpret the = sense of
>>> the
>>> message, even to the point of making a nonsensical conversion.= we allow
>>> this
>>> to happen because we assume that at the application layer, we&= #39;re going to
>>> do
>>> parameter checking. so the reasoning was... if we're going= to be doing
>>> parameter checking anyway, why would we want to allow the pres= entation
>>> layer
>>> to fail a message that would have generated a result that coul= d be
>>> checked
>>> at the application layer?
>>>
>>> i hope you've enjoyed this installment of "the struct= ure and
>>> interpretation
>>> of LLSD messages." and i hope it helps explain our motiva= tions for
>>> designing
>>> LLSD and it's serializations the way we did... and while w= e have a metric
>>> tonne of code that uses the existing LLSD DTD, ultimately, any= additional
>>> serialization format that preserves these processing expectati= ons could
>>> be
>>> wedged into the system. serialization formats that did not sup= port these
>>> processing expectations would cause considerable heart burn. >>>
>>> -cheers
>>> -meadhbh
>>>
>>> On Feb 24, 2009, at 6:12 PM, Jon Watte wrote:
>>>
>>> Catherine Pfeffer wrote:
>>> That's precisely all the HUGE strength of LLSD. Having inf= ormation about
>>> what the data is intermingled with the data itself makes it ve= ry flexible
>>> and future-proof.
>>> But that is simply not necessary. If you transmit a reference = to the
>>> schema
>>> you use when you initiate connection, then all future transmis= sions
>>> during
>>> that connection session can use the knowledge of that schema t= o highly
>>> optimize traffic. Network traffic is actually one of the scarc= e resources
>>> when you start scaling up really large virtual worlds. There a= re cases
>>> where
>>> an entire office (20 people or more) share a single T1 connect= ion to the
>>> Internet, and expect to have a good virtual world experience f= or multiple
>>> users at the same time.
>>>
>>>
>>> Honestly, here, the bandwidth is not lost, compared to the adv= antages.
>>>
>>>
>>> I think it is, because the size difference is quite significan= t.
>>>
>>> In summary, their binary serialization is as flexible as XML d= ata.
>>> Perhaps
>>> I'm wrong, but to me it's an unique case in all comput= er science of a
>>> binary
>>> format that would be so flexible.
>>>
>>> Don't overextend yourself :-) AIFF/RIFF has pretty much th= e same
>>> flexibility, as does TLV (also used in OSCAR), a number of &qu= ot;binary XML"
>>> proposals, and a number of protocols that have all done more o= r less the
>>> same thing ever since computers were interconnected on a large= r scale in
>>> the
>>> '80s.
>>>
>>> Sincerely,
>>>
>>> jw
>>>
>>> _______________________________________________
>>> mmox mailing list
>>> mmox@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/mmox
>>>
>>> _______________________________________________
>>> mmox mailing list
>>> mmox@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/mmox
>>>
>>>
>>>
>>> _______________________________________________
>>> mmox mailing list
>>> mmox@ietf.o= rg
>>> https://www.ietf.org/mailman/listinfo/mmox
>>>
>>>
>
>

--0016364581984b6ee90463c9e123-- From jwatte@gmail.com Wed Feb 25 20:18:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2D13A687F for ; Wed, 25 Feb 2009 20:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1qoAPico4Xc for ; Wed, 25 Feb 2009 20:18:57 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id D57AE3A6963 for ; Wed, 25 Feb 2009 20:18:56 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so403893wfd.31 for ; Wed, 25 Feb 2009 20:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=D1IvLwG9ISKPbb0pqBWK2Pi0jRjWvk5m4sBRd3GrFBM=; b=CyQDVF1fXojZmGHYQIFnvC6xTYHIrbvM6mrIAdYFNgy5N2+sPFmGkM5UbkdL7Tvu+l 1/hUtqdCWHz6M8skynHhoK1qx6djQd9c0lmU9iA+aa+3uhpc3VcwxRNk5zXNNLPz4zWU 897kAJL435676KYZ5mPtvxQPsMzMMD6VCQAeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BRb2AjmIAgOo2hvEKyEYgzkqVJt93wN6dtBscEeAMGBnV+4m4Wy3l5UJiFoqDADLjI CSGNEldVyym7XNuMNUl3iu6dupuH26gNCILWhpoV+2Li6A3oICbezIlyd4LH9E6DAice h9RmOG1h/JkHb25nfVm8CaZpDGtD6EUe2QV2k= Received: by 10.142.155.17 with SMTP id c17mr435225wfe.223.1235621957326; Wed, 25 Feb 2009 20:19:17 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id 30sm3872372wff.7.2009.02.25.20.19.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 20:19:16 -0800 (PST) Message-ID: <49A61843.7020001@gmail.com> Date: Wed, 25 Feb 2009 20:19:15 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> <49A5F589.4090803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] taxonomy of topics X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 04:18:57 -0000 Morgaine wrote: > On Thu, Feb 26, 2009 at 1:51 AM, Jon Watte > wrote: > > > Why couldn't OGP stay in the AWG? > > > It's not your place to deny Linden Lab the IETF standardization of > their protocols, assuming that two independent reference > implementations can be found. The only problem is when it's done > under false pretenses. I think you're assuming some meaning I did not intend. It was an honest question: What could you do, with Second Life protocols, through a narrowly focused, Second Life centric IETF group, that you could not do, potentially faster and easier, in the AWG? > > IBM has extremely broad VW interests. I can't help but have noticed :-) > > If you wish to suggest that those two goals can sometimes be in > conflict within LL, then you would be right. But if you were to > suggest that it's either/or, then you would be wrong. I am suggesting nothing; I am asking questions because I don't feel I have a good read on the situation, and I am honestly interested in the answers. Sincerely, jw From jwatte@gmail.com Wed Feb 25 20:27:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B859E3A6844 for ; Wed, 25 Feb 2009 20:27:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oY4FvZIjnKHS for ; Wed, 25 Feb 2009 20:27:21 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id E6F8D3A6B34 for ; Wed, 25 Feb 2009 20:27:20 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so319856rvb.49 for ; Wed, 25 Feb 2009 20:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=A/1iwdCpkZXqL6+DwE/6VL+JSbJ/tD4ekexz2BLYAp8=; b=Su/HH7isve/VDE38LPwgMWwP4woBMmhgOfkdwNFJKzXcCnmY8psfm5JiZAU+YsLl8X WgcrUuvzj9/uhCitVEMqigF9i5ZdP1m+2gk/khhW4CAhIiaERJoG18CdJ7/9CdPANfVx Yuq14PRk5iKza9wX1Qgn7TzAYOUhavt9V5EvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KJSdteJ4jXK9caq8SNf3n0yoSNcr5rrI+sI7lBjjRwUKvkV3sH+7IDe7dLsfuv2BRG dDvF3tzo6L9ayObnqO4If3lvxeNZoB0CTReyj+QaEqKCeSJaQAAz2mqfAy+XAcQBdGOP 4NyfAu0Mqgy99P/c1jjb9uyXidgi+aYUvqMLE= Received: by 10.141.105.18 with SMTP id h18mr401237rvm.109.1235622461886; Wed, 25 Feb 2009 20:27:41 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id c20sm507988rvf.1.2009.02.25.20.27.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 25 Feb 2009 20:27:41 -0800 (PST) Message-ID: <49A61A3C.1090109@gmail.com> Date: Wed, 25 Feb 2009 20:27:40 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <49A4A8FA.607@gmail.com> <024355C7-0753-451F-9542-4478D27A2802@lindenlab.com> <497C7FD9-BF36-458F-98C0-BEECAE611E1A@lindenlab.com> <06CF9E4E-6C20-46CB-B092-68F702C2E185@lindenlab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] The Structure and Interpretation of LLSD Messages [Was: Re: unefficient binary serialization ?] X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 04:27:21 -0000 Morgaine wrote: > While such gateways are fine for non-interactive streaming downloads, > unfortunately they introduce latency that can ruin the interactive > experience. In my experience, having done exactly that in some solutions, that technical argument doesn't hold water in practice. As long as the gateway is close to the source (or destination), and the translator is implemented competently, the addition in latency can be fractions of a millisecond. Compared to just random noise and jitter from the greater Internet, you would be hard pressed to even reliably measure that. That being said, if someone is proposing the origination of high-volume real-time data as XML, then I have to respectfully disagree with the proposal on general principle -- for the same reason that we don't try to originate, say, streaming video, or telephony voice data as XML. When it will generally be transfered binary, you probably want to originate it binary, to avoid the dual overhead of first generating XML, and then un-generating it again. Sincerely, jw From morgaine.dinova@googlemail.com Wed Feb 25 20:52:43 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1210B28C19D for ; Wed, 25 Feb 2009 20:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id av3riR9gN6iC for ; Wed, 25 Feb 2009 20:52:41 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 5699A28C190 for ; Wed, 25 Feb 2009 20:52:41 -0800 (PST) Received: by fxm24 with SMTP id 24so319289fxm.37 for ; Wed, 25 Feb 2009 20:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=H5MunRJrzZLFdhRfDXvvbDbyXPUNQ3tDMKpoFOvV2Jg=; b=elneoJfghtYZ7z0CRjlD755IdmiKx+4GXM+wH98BoGZJEvDkpjI2YwAx1gZq8u1xxG kgl1pi19Gf7bCh3472yfAXOEb+Q9HNNY0HeZzm0SFuILCzQDd88aakc5ks+B12wv3+iu NmrKtXab8GFRiqh2784dQ4xP8Mga6yqbxfbGQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kIgwdbwZ77k7H8HJo7GkxgAMXts2jniaBQkiPuM690nNBaP5J3fYTjbCpaMA+kmAzN IcP0lDKCHjxviFAltlEMW2P8za9BHraBjQK8zyqioqsfWCKM8GPOvGzscYz6oUq67rA9 iR4wjg/wQ4d0Pzx7R43d3U8Qq7HEAGZTZVsLM= MIME-Version: 1.0 Received: by 10.181.148.2 with SMTP id a2mr305656bko.117.1235623981147; Wed, 25 Feb 2009 20:53:01 -0800 (PST) In-Reply-To: <27a487810902241253v1f2c5b82q9dac1cd39e34ec07@mail.gmail.com> References: <27a487810902241253v1f2c5b82q9dac1cd39e34ec07@mail.gmail.com> Date: Thu, 26 Feb 2009 04:53:01 +0000 Message-ID: From: Morgaine To: William George Content-Type: multipart/alternative; boundary=0016e6de17a778e8020463cb209b Cc: mmox@ietf.org Subject: Re: [mmox] Time to rethink the commercial angle X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 04:52:43 -0000 --0016e6de17a778e8020463cb209b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Feb 24, 2009 at 8:53 PM, William George wrote: In order to sidestep some of the thorny (and circular) discussions on > property rights, as well as the petty technical arguments backed by > "customer interests", I propose that only worlds with free access and only > unencumbered objects be allowed to interoperate, at least to start. > The word "allowed" isn't appropriate since there is no permission required to distribute unencumbered objects nor to interoperate. Apart from that though, the spirit and promise and viability of what you envisage is clear. The future of open grids is unbounded, simply because unencumbered object exchange is unhampered by any constraints except computer resources, and enthusiasm in the open community probably exceeds the known physical constraints of teh universe. ;-) Since the free and open grids have assets that are either public domain or licensed under free-distribution licenses like GPL, BSD, CC and others, it makes no sense whatsoever to hold back interop between such open worlds just because the proprietary worlds can't get their act together. Fortunately, they're not being held back in the slightest. ;-) Morgaine. On Tue, Feb 24, 2009 at 8:53 PM, William George wrote: > In order to sidestep some of the thorny (and circular) discussions on > property rights, as well as the petty technical arguments backed by > "customer interests", I propose that only worlds with free access and only > unencumbered objects be allowed to interoperate, at least to start. > > The commercial objectives are taking up too much of _my_ limited > bandwidth. > > Remember when the internet did not have any commercial interests? This was > up until 1994, not really that long ago. > > Waka > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --0016e6de17a778e8020463cb209b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Feb 24, 2009 at 8:53 PM, William George <wjgeorge@dceo.rutgers.edu> wrote:

In order to sidestep some of the thorny (and circular) discussions on property rights, as well as the petty technical arguments backed by "customer interests", I propose that only worlds with free access= and only unencumbered objects be allowed to interoperate, at least to start.


The word "allowed" isn't appropriat= e since there is no permission required to distribute unencumbered objects = nor to interoperate.

Apart from that though, the spirit and promise = and viability of what you envisage is clear.=A0 The future of open grids is= unbounded, simply because unencumbered object exchange is unhampered by an= y constraints except computer resources, and enthusiasm in the open communi= ty probably exceeds the known physical constraints of teh universe. ;-)

Since the free and open grids have assets that are either public domain= or licensed under free-distribution licenses like GPL, BSD, CC and others,= it makes no sense whatsoever to hold back interop between such open worlds= just because the proprietary worlds can't get their act together.
=A0
Fortunately, they're not being held back in the slightest. ;-)=

Morgaine.






On = Tue, Feb 24, 2009 at 8:53 PM, William George <wjgeorge@dceo.rutgers.edu> wrote:
In order to sides= tep some of the thorny (and circular) discussions on property rights, as we= ll as the petty technical arguments backed by "customer interests"= ;, I propose that only worlds with free access and only unencumbered object= s be allowed to interoperate, at least to start.

The commercial objectives are taking up too much of=A0 _my_ limited ban= dwidth.

Remember when the internet did not have any commercial inter= ests? This was up until 1994, not really that long ago.

Waka


_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--0016e6de17a778e8020463cb209b-- From morgaine.dinova@googlemail.com Wed Feb 25 22:56:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7568428C280 for ; Wed, 25 Feb 2009 22:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8Qsprc4pW+O for ; Wed, 25 Feb 2009 22:56:55 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id AAF7F28C1DE for ; Wed, 25 Feb 2009 22:56:54 -0800 (PST) Received: by fxm24 with SMTP id 24so346396fxm.37 for ; Wed, 25 Feb 2009 22:57:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=jVNJRoZZC0UbNxctdta04iYQz/zy55NMDoTp4d86LyA=; b=vnqwUE9HFvB3kIkrKftPAXz/UeCaBh7bNRYIDnD1u7knEg4Kn3j/sdpbhtkZxwk0YS mjfcv2YkiihsWL3/TU04pp2fhplyM8Vw8sEMGRYOvGwE6nITFuF/+NbYcLhlGPGOM+SD XxJbB9Jug1Zb1BkvVewOsDeSFIIsa4WnN7XYQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NSniAqNC3zvJSCRxFabzLeajVeqp+NncvKKd4fe3KWvg058yKrwbwl9PiR+5yPfN14 4Eu0zELusdAm/aZVewNic64KNrBWoBgC+/OFHuzVe/OnOSr1QKFJAILnxl9+FwP0qvQi fVuruusJVXSu/JT0ZzQ0rWpg4PxtRa/SOep/k= MIME-Version: 1.0 Received: by 10.181.37.6 with SMTP id p6mr347553bkj.29.1235631434820; Wed, 25 Feb 2009 22:57:14 -0800 (PST) In-Reply-To: References: <27a487810902241253v1f2c5b82q9dac1cd39e34ec07@mail.gmail.com> Date: Thu, 26 Feb 2009 06:57:14 +0000 Message-ID: From: Morgaine To: William George Content-Type: multipart/alternative; boundary=001636c5b387beebe60463ccdc4b Cc: mmox@ietf.org Subject: Re: [mmox] Time to rethink the commercial angle X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 06:56:56 -0000 --001636c5b387beebe60463ccdc4b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I need to correct something on my previous post: On Thu, Feb 26, 2009 at 4:53 AM, Morgaine wrote: > > Since the free and open grids have assets that are either public domain or > licensed under free-distribution licenses like GPL, BSD, CC and others, it > makes no sense whatsoever to hold back interop between such open worlds just > because the proprietary worlds can't get their act together. > > Fortunately, they're not being held back in the slightest. ;-) > I should qualify my last line slightly. The open worlds are not being held back for interop *among themselves*. However, they are being held back currently by the fact that items created on proprietary worlds *without any kind of encumbrances* ("full perm" in SL terminology) cannot be marked as "interoperable" by their creators, and hence cannot currently be released to open grids despite this being their author's desire. This is a failure of proprietary grids or worlds to put their interop money where their mouth is, given that there are no rights, permissions nor licensing barriers to permitting this. That's a pity, and it's not specific to SL. Morgaine. On Thu, Feb 26, 2009 at 4:53 AM, Morgaine wrote: > On Tue, Feb 24, 2009 at 8:53 PM, William George > wrote: > > In order to sidestep some of the thorny (and circular) discussions on >> property rights, as well as the petty technical arguments backed by >> "customer interests", I propose that only worlds with free access and only >> unencumbered objects be allowed to interoperate, at least to start. >> > > > The word "allowed" isn't appropriate since there is no permission required > to distribute unencumbered objects nor to interoperate. > > Apart from that though, the spirit and promise and viability of what you > envisage is clear. The future of open grids is unbounded, simply because > unencumbered object exchange is unhampered by any constraints except > computer resources, and enthusiasm in the open community probably exceeds > the known physical constraints of teh universe. ;-) > > Since the free and open grids have assets that are either public domain or > licensed under free-distribution licenses like GPL, BSD, CC and others, it > makes no sense whatsoever to hold back interop between such open worlds just > because the proprietary worlds can't get their act together. > > Fortunately, they're not being held back in the slightest. ;-) > > Morgaine. > > > > > > > On Tue, Feb 24, 2009 at 8:53 PM, William George > wrote: > >> In order to sidestep some of the thorny (and circular) discussions on >> property rights, as well as the petty technical arguments backed by >> "customer interests", I propose that only worlds with free access and only >> unencumbered objects be allowed to interoperate, at least to start. >> >> The commercial objectives are taking up too much of _my_ limited >> bandwidth. >> >> Remember when the internet did not have any commercial interests? This was >> up until 1994, not really that long ago. >> >> Waka >> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> >> > --001636c5b387beebe60463ccdc4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I need to correct something on my previous post:=

On Thu, Feb 26, 2009 at 4:53 AM, Morgaine <morgaine.dinova@googlemail.c= om> wrote:
=A0
Since= the free and open grids have assets that are either public domain or licensed under free-distribution licenses like GPL, BSD, CC and others, it makes no sense whatsoever to hold back interop between such open worlds just because the proprietary worlds can't get their act together.
=A0
Fortunately, they're not being held back in the slightest. ;-)=
=A0

I should qualif= y my last line slightly.=A0=A0 The open worlds are not being held back for = interop among themselves.

However, they are being held back currently by the fact that items crea= ted on proprietary worlds without any kind of encumbrances ("fu= ll perm" in SL terminology) cannot be marked as "interoperable&qu= ot; by their creators, and hence cannot currently be released to open grids= despite this being their author's desire.

This is a failure of proprietary grids or worlds to put the= ir interop money where their mouth is, given that there are no rights, perm= issions nor licensing barriers to permitting this.=A0 That's a pity, an= d it's not specific to SL.

Morgaine.







On = Thu, Feb 26, 2009 at 4:53 AM, Morgaine <morgaine.dinova@googlemail.com><= /span> wrote:
On Tue, Feb 24, 2009 at 8:53 PM, William George <= wjgeorge@dce= o.rutgers.edu> wrote:

In order to sidestep some of the thorny (and circular) discussions on property rights, as well as the petty technical arguments backed by "customer interests", I propose that only worlds with free access= and only unencumbered objects be allowed to interoperate, at least to start.


The word "allowed" isn't appr= opriate since there is no permission required to distribute unencumbered ob= jects nor to interoperate.

Apart from that though, the spirit and pr= omise and viability of what you envisage is clear.=A0 The future of open gr= ids is unbounded, simply because unencumbered object exchange is unhampered= by any constraints except computer resources, and enthusiasm in the open c= ommunity probably exceeds the known physical constraints of teh universe. ;= -)

Since the free and open grids have assets that are either public domain= or licensed under free-distribution licenses like GPL, BSD, CC and others,= it makes no sense whatsoever to hold back interop between such open worlds= just because the proprietary worlds can't get their act together.
=A0
Fortunately, they're not being held back in the slightest. ;-)=

Morgaine.






On Tue, F= eb 24, 2009 at 8:53 PM, William George <wjgeorge@dceo.rutgers.edu<= /a>> wrote:
_____________________________________= __________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox



--001636c5b387beebe60463ccdc4b-- From cs@comlounge.net Thu Feb 26 01:14:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97DC3A6953 for ; Thu, 26 Feb 2009 01:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvo2btto-rit for ; Thu, 26 Feb 2009 01:14:48 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 97AF83A692F for ; Thu, 26 Feb 2009 01:14:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 6F79E1CE0278; Thu, 26 Feb 2009 10:15:08 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZuluA4L9myh; Thu, 26 Feb 2009 10:15:07 +0100 (CET) Received: from [192.168.178.40] (pD9EBE7C6.dip.t-dialin.net [217.235.231.198]) by post.comlounge.net (Postfix) with ESMTP id 3769F1CE023B; Thu, 26 Feb 2009 10:15:07 +0100 (CET) Message-ID: <49A65D92.3060606@comlounge.net> Date: Thu, 26 Feb 2009 10:14:58 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Hurliman, John" References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 09:14:49 -0000 Hurliman, John schrieb: >> -----Original Message----- > This brings up an important topic to consider in interoperability. > Most (if not all) virtual platforms use shortcuts like this to > offload processing on to the client. But saying "draw tree type 7" > doesn't mean the same thing (or anything) to Forterra, VastPark, etc. > Would you create interop versions of the trees (mesh and texture > representations), or just not allow that content to move across > boundaries? I think requiring having some data in the client will not scale. Why not give it an URL as well and just tell the client to cache it long enough? Should be easy with a REST approach. For SL it might be trees for a game it might in fact be everything if no user generated content is allowed. A specialized game client could even be so clever as to download it in advance and have some proprietary way of checking whether it's still uptodate or not. Or it might be a list of things to preload with a caching header on that list and a must-revalidate. Then only if the list changes you have to download it again. -- Christian -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From lenglish5@cox.net Thu Feb 26 01:54:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05E953A6A35 for ; Thu, 26 Feb 2009 01:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.795 X-Spam-Level: X-Spam-Status: No, score=0.795 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T19r0g7Eh71G for ; Thu, 26 Feb 2009 01:54:32 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id A52493A6806 for ; Thu, 26 Feb 2009 01:54:32 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090226095453.LCRC10385.fed1rmmtao107.cox.net@fed1rmimpo02.cox.net>; Thu, 26 Feb 2009 04:54:53 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id LZut1b0024N6T0Q04Zutan; Thu, 26 Feb 2009 04:54:53 -0500 X-Authority-Analysis: v=1.0 c=1 a=AfYVl4n-8fwA:10 a=5qzUSljf7S4A:10 a=Wajolswj7cQA:10 a=iuokir-T9fviaQsludoA:9 a=O-K-ysWpKUna9hEZmKJMhyTGN18A:4 a=C35D7iIojSgA:10 X-CM-Score: 0.00 Message-ID: <49A666ED.6040508@cox.net> Date: Thu, 26 Feb 2009 02:54:53 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Christian Scholz References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> In-Reply-To: <49A65D92.3060606@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 09:54:34 -0000 Christian Scholz wrote: > Hurliman, John schrieb: >>> -----Original Message----- > >> This brings up an important topic to consider in interoperability. >> Most (if not all) virtual platforms use shortcuts like this to >> offload processing on to the client. But saying "draw tree type 7" >> doesn't mean the same thing (or anything) to Forterra, VastPark, etc. >> Would you create interop versions of the trees (mesh and texture >> representations), or just not allow that content to move across >> boundaries? > > I think requiring having some data in the client will not scale. Why > not give it an URL as well and just tell the client to cache it long > enough? Should be easy with a REST approach. For SL it might be trees > for a game it might in fact be everything if no user generated content > is allowed. > A specialized game client could even be so clever as to download it in > advance and have some proprietary way of checking whether it's still > uptodate or not. > Or it might be a list of things to preload with a caching header on > that list and a must-revalidate. Then only if the list changes you > have to download it again. > Seems to me that some default content might be distributable as libraries/plugins. Any world that wants to allow the display of SL-like trees could toss out "SL tree-type 7" in the appropriate message. Likewise with some other standardized content found in other worlds. Would LL or any other world-provider want to do this? If it facilitates interop, perhaps... Just as there eventually will be universal avatar formats, there might be universal generic trees, etc. Hmmm... prims, anyone? L From adam@deepthink.com.au Thu Feb 26 01:57:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51323A6BED for ; Thu, 26 Feb 2009 01:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUHw2PhB4OGd for ; Thu, 26 Feb 2009 01:57:20 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id C7E8A3A6806 for ; Thu, 26 Feb 2009 01:57:20 -0800 (PST) Received: from ntxedgeus01.exchange.xchg (ntxedgeus01.lxa.perfora.net [172.23.130.34]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1Lcczr1G2S-0001KY; Thu, 26 Feb 2009 04:57:40 -0500 Received: from ntxhubus01.exchange.xchg (172.23.130.14) by ntxedgeus01.exchange.xchg (172.23.130.34) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 26 Feb 2009 04:49:17 -0500 Received: from winxbeus19.exchange.xchg ([172.23.130.79]) by ntxhubus01.exchange.xchg ([172.23.130.14]) with mapi; Thu, 26 Feb 2009 04:57:10 -0500 From: "Frisby, Adam" To: "lenglish5@cox.net" , Christian Scholz Date: Thu, 26 Feb 2009 04:57:05 -0500 Thread-Topic: [mmox] RealExtend Teleporting Between Worlds Thread-Index: AcmX+EtdP1HhmcsPRdiYXbJsRj2UuQAABKxg Message-ID: <63FAD4F222230A4EA79DE9E8BE664735056D2DD8@winxbeus19.exchange.xchg> References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> <49A666ED.6040508@cox.net> In-Reply-To: <49A666ED.6040508@cox.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Provags-ID: V01U2FsdGVkX19v41LjK+NKVYiAR2cQcUYkjBGtMIML+5tV1Q6 1gW2cMRQGR5dghz7BNoTzYPEPcH5JJA48I+kjzvLTz6LKzBoJ Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 09:57:21 -0000 If this is to be done, my suggestion would be to not pick LL-style trees, a= nd standardise on something which more resembles a L-System description. (o= r perhaps build a standard interface which resembles something like speedtr= ee) Adam > -----Original Message----- > From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of > Lawson English > Sent: Thursday, 26 February 2009 1:55 AM > To: Christian Scholz > Cc: mmox@ietf.org > Subject: Re: [mmox] RealExtend Teleporting Between Worlds > > Christian Scholz wrote: > > Hurliman, John schrieb: > >>> -----Original Message----- > > > >> This brings up an important topic to consider in interoperability. > >> Most (if not all) virtual platforms use shortcuts like this to > >> offload processing on to the client. But saying "draw tree type 7" > >> doesn't mean the same thing (or anything) to Forterra, VastPark, > etc. > >> Would you create interop versions of the trees (mesh and texture > >> representations), or just not allow that content to move across > >> boundaries? > > > > I think requiring having some data in the client will not scale. Why > > not give it an URL as well and just tell the client to cache it long > > enough? Should be easy with a REST approach. For SL it might be trees > > for a game it might in fact be everything if no user generated > content > > is allowed. > > A specialized game client could even be so clever as to download it > in > > advance and have some proprietary way of checking whether it's still > > uptodate or not. > > Or it might be a list of things to preload with a caching header on > > that list and a must-revalidate. Then only if the list changes you > > have to download it again. > > > Seems to me that some default content might be distributable as > libraries/plugins. Any world that wants to allow the display of SL-like > trees could toss out "SL tree-type 7" in the appropriate message. > Likewise with some other standardized content found in other worlds. > Would LL or any other world-provider want to do this? If it facilitates > interop, perhaps... Just as there eventually will be universal avatar > formats, there might be universal generic trees, etc. Hmmm... prims, > anyone? > > L > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From cathypfeffer@gmail.com Thu Feb 26 02:07:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A97A23A6A35 for ; Thu, 26 Feb 2009 02:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stmouP0nyWZd for ; Thu, 26 Feb 2009 02:07:51 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id CDDCA3A688C for ; Thu, 26 Feb 2009 02:07:48 -0800 (PST) Received: by bwz26 with SMTP id 26so414445bwz.37 for ; Thu, 26 Feb 2009 02:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=5nv3xrSFGw6S1kZs0SEIxHqV5rj+aGyPeyccr2DsmQ4=; b=As9IHXog7Argf0eSFNaGMo/+59hJpkAltQBmBF59Rh42zDwiAugOmzB1HLpXhVgen8 ERk3V2ak7ulIU/wf0zBoajdH+9L2qZIFITF+kgqhWT0iMSKrJdpsqqbQonfjmnTdXhhM 4zlcrm3oOcIsWkUQWuheNJmlRzLFOoSxAChm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UOfn2sezMCx33mrZPLp4Uca6lhAvTmMqd/p+cS2XjpYjKsEl0b2tiOO18UwZ5o8OOH q2k9hd+Q3HYi+O1WKDuTBA7LRZibvqKe2Eet67UMnU/c3Kpogjvu8hOQ/1bgM8iKIslP BCdLz+TL/4AUEDn0qCcSiBm99Y5EXI6Ae4oEM= MIME-Version: 1.0 Received: by 10.181.199.6 with SMTP id b6mr395250bkq.137.1235642889272; Thu, 26 Feb 2009 02:08:09 -0800 (PST) Date: Thu, 26 Feb 2009 11:08:09 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636c5a2677bfc6b0463cf872d Subject: [mmox] Three serializations X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 10:07:52 -0000 --001636c5a2677bfc6b0463cf872d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > so. again. let me reiterate the issues we have with "the XML way." > > first off, XML is for us, not a first order representational system. Finally! I'm really glad to hear that. If XML serialization is not a first class citizen in the protocol, then why is it presented at the same level as the other serializations in the LLSD draft? Why bother with it at all? Implementing three serializations (plus perhaps a serialization negotiation) mechanism will mean tons of more work for everyone. Excuse me, but the considerations you expressed behind the choice of having a XML serialization ("because we need JSON too", and "not co-mingle application semantics with presentation logic") do not explain why an XML serialization would be necessary. To me this sounds like, "We'd like to separate our data view from the on the on-the-wire protocol. Oh cool, that means we could change serialization of the fly. As a proof of concept, here is an XML serialization that could please the XML nerds out there!". That is not a valid argumentation in favour of an XML serialization. Virtual Worlds exchange lots of data: spatial, graphical, multimedia. That makes binary formats an obvious choice, be it LLSD (or whatever its future name), Google buffers, or anything else. You have come with something great, Infinity. Your binary format is an extraordinary middle way between compactness and flexibility. It achieves what Corba and UNO and others have always tried to do, but in a much simpler, bullet-proof, way. On the other hand, transposing it one-to-one to XML does not really work. When it takes you 1 byte to encode "integer" in the binary serialization, it take you 19 bytes in the XML serialization ( ... ). Again, your XML might look like XML, but it is not real XML: 1) You don't take profit of XML validation mechanisms Having very low-level data types like or makes validation look like more a wellformed-ness test than real validation. There is not even a way to control that a color is in the RGB range, or even that a vector has three coordinates. This XML really works at a semantics level that is too low. It's like writing an assembler program with binary codes in an array of char in a C++ program ;-). The external grammar is C++, but the inside content is still assembler. 2) Your XML format does not fit well into DOM parsing or XSLT/XPath transformations The XPath expression map/key[. = 'Taper_X']/following-sibling::float[position() = 1] speaks for itself, at a place where people normally do @Taper_X (I have not checked that this expression works, but the real one must not be very far away in terms of complexity) Jon was right when saying about maps that this is "a terrible serialization". 3) One of the major advantages of XML is that it's human-readable. But the data types like or clutter the file. Embedded XML tags are replaced with nested s. So even that does not work well. So, if the native XML tools are of little use, why bother with XML at all? -- Cathy --001636c5a2677bfc6b0463cf872d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > so. again. let me reiterate the issues we have with "the XML way.= "
>
> first off, XML is for us, not a first order represen= tational system. =C2=A0

Finally! I'm really glad to hear that.
If XML serialization is not a first class citizen in the protocol, then= why is it presented at the same level as the other serializations in the L= LSD draft? Why bother with it at all?

Implementing three serializati= ons (plus perhaps a serialization negotiation) mechanism will mean tons of = more work for everyone.

Excuse me, but the considerations you expressed behind the choice of ha= ving a XML serialization ("because we need JSON too", and "n= ot co-mingle application semantics with presentation logic") do not ex= plain why an XML serialization would be necessary. To me this sounds like, = "We'd like to separate our data view from the on the on-the-wire p= rotocol. Oh cool, that means we could change serialization of the fly. As a= proof of concept, here is an XML serialization that could please the XML n= erds out there!". That is not a valid argumentation in favour of an XM= L serialization.

Virtual Worlds exchange lots of data: spatial, graphical, multimedia. T= hat makes binary formats an obvious choice, be it LLSD (or whatever its fut= ure name), Google buffers, or anything else.

You have come with some= thing great, Infinity. Your binary format is an extraordinary middle way be= tween compactness and flexibility. It achieves what Corba and UNO and other= s have always tried to do, but in a much simpler, bullet-proof, way.

On the other hand, transposing it one-to-one to XML does not really wor= k. When it takes you 1 byte to encode "integer" in the binary ser= ialization, it take you 19 bytes in the XML serialization (<integer> = ... </integer>).

Again, your XML might look like XML, but it is not real XML:

1) You don't take profit of XML validation mechanisms

Having ve= ry low-level data types like <integer> or <float> makes validat= ion look like more a wellformed-ness test than real validation.

There is not even a way to control that a color is in the RGB range, or= even that a vector has three coordinates.

This XML really works at = a semantics level that is too low. It's like writing an assembler progr= am with binary codes in an array of char in a C++ program ;-). The external= grammar is C++, but the inside content is still assembler.


2) Your XML format does not fit well into DOM parsing or XSLT/XPath= transformations

The XPath expression
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 map/key[. =3D 'Taper_X']/following-sibling::float[position() = =3D 1]
speaks for itself, at a place where people normally do
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 @Taper_X
(I have not checked that this ex= pression works, but the real one must not be very far away in terms of comp= lexity)

Jon was right when saying about maps that this is "a te= rrible serialization".


3) One of the major advantages of XML is that it's human-readab= le. But the data types like <integer> or <array> clutter the fi= le. Embedded XML tags are replaced with nested <map>s. So even that d= oes not work well.


So, if the native XML tools are of little use, why bother with XML = at all?

--
Cathy
--001636c5a2677bfc6b0463cf872d-- From cathypfeffer@gmail.com Thu Feb 26 02:13:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07D613A688C for ; Thu, 26 Feb 2009 02:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjyQqJVix5ec for ; Thu, 26 Feb 2009 02:13:47 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id 028B928C0F7 for ; Thu, 26 Feb 2009 02:13:46 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so235079fkf.5 for ; Thu, 26 Feb 2009 02:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=lj82yBOlv3esbfGrBOUSIoagVnKs9tm96g4+y07k1UQ=; b=wrvSF7qMu8l6+d9o9FcudWKtX/SujJchOXPz35RBvvNbszDRmgHJoOPGuilP/OdPKw rOgilTyKp6Wua2wZHCKu501BxBKIyhRjtdGbQe1vwc5BwuBfF6NuPEVs6/C4+ufyRHfv nCP7r32KF6N3m0+ZJZNcuiGqd8cmrRMJFmraM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rnlmPjaCaeO4gipvkv7H0gSov1MhikpiUR8WhYn3Df0qQrCcpx6thCrWxXF1hHXh3w SbsiM1fTT031OB/lP/BTnWQftP4ZshmBIISBME6Y9KC34ivpxssPCtIJ2yfjuy/ogs0r TUv7RdwOi1ErhP5tYGL+PoiyeOIV1yCOpiEXE= MIME-Version: 1.0 Received: by 10.181.222.5 with SMTP id z5mr391078bkq.170.1235643247079; Thu, 26 Feb 2009 02:14:07 -0800 (PST) Date: Thu, 26 Feb 2009 11:14:07 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636c5a81ccfb1070463cf9c2a Subject: [mmox] Agree to disagree? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 10:13:48 -0000 --001636c5a81ccfb1070463cf9c2a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Infinity wrote: > to paraphrase... we think the "XML way" does not buy us anything. we > respect that other people might have a different preference or set of > requirements related to XML. but you have to respect that we're not > going to abandon a key portion of what makes our architecture > resilient in the face of version slew. so why not just agree to > disagree about it, allow virtual world deployers make up their own > minds about which presentation tier to adopt. Because exchange standards are about agreeing on a common language. -- Cathy --001636c5a81ccfb1070463cf9c2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Infinity wrote:
> to paraphrase... we think the "XML way" d= oes not buy us anything. we =C2=A0
> respect that other people might = have a different preference or set of =C2=A0
> requirements related t= o XML. but you have to respect that we're not =C2=A0
> going to abandon a key portion of what makes our architecture =C2=A0> resilient in the face of version slew. so why not just agree to =C2= =A0
> disagree about it, allow virtual world deployers make up their = own =C2=A0
> minds about which presentation tier to adopt.

Because exchange = standards are about agreeing on a common language.

-- =
Cathy
--001636c5a81ccfb1070463cf9c2a-- From cathypfeffer@gmail.com Thu Feb 26 02:22:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64BB3A6A32 for ; Thu, 26 Feb 2009 02:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpEQ-TmXj3y3 for ; Thu, 26 Feb 2009 02:22:57 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id BE2C43A68AF for ; Thu, 26 Feb 2009 02:22:56 -0800 (PST) Received: by fxm24 with SMTP id 24so426826fxm.37 for ; Thu, 26 Feb 2009 02:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=sPYtgYj5VUIfPcTiYJF5ZSdjnaB8L4dm7/mm+EpAMvw=; b=D7M+D055f7fiZTsJv6MaMjgLJqGxeEgS+VgwSfh7XJDFcsfgADwy2foAw+zzD0h24l XDsbv/m273ovB0m9uyYd+gtBwo/LN4Z4VYCHSCtubXJEhgZAwIeeLXXh6+OlgGu82ewn FzKWq6iPy345gqjFKms56xZRiUd/6cdkBjC/A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=mPmN6tUY+cUrrlgWmAzFqb8QYdsZ0JoWA/YJ+W0/aJ8474xmtjbXTHFA/3w39QdZWb lH0etGLiun/lUOASKzqP/0O8QlO9abAoYoWXY2PZsWCSoLMFC4OpUG3+OqejJGlfFsSl u23CwOQjVyp4aMC58TXZwoou2q3/EOdc3lN0Q= MIME-Version: 1.0 Received: by 10.181.199.6 with SMTP id b6mr399752bkq.137.1235643796929; Thu, 26 Feb 2009 02:23:16 -0800 (PST) Date: Thu, 26 Feb 2009 11:23:16 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636c5a26795be270463cfbd18 Subject: [mmox] LLSD => XML way X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 10:22:58 -0000 --001636c5a26795be270463cfbd18 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Infinity wrote: > I would also argue that if we could develop a mechanical scheme to > convert between LLIDL and "the XML way" XML DTD, we could interoperate > with such systems will less ambiguity. Very true. But as this represents some work, and as I have a company to run IRL, I would say that, before jumping into that technical solution, there should be consensus here that we really need three serializations to make virtual worlds interoperable. Who on this list, besides the 700 kilograms gorilla (Linden Lab, their own words IIRC ;-) ), has a strong desire and an use case for non-binary formats? -- Cathy --001636c5a26795be270463cfbd18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Infinity wrote:
> I would also argue that if we could develop a mecha= nical scheme to =C2=A0
> convert between LLIDL and "the XML way&= quot; XML DTD, we could interoperate =C2=A0
> with such systems will = less ambiguity.

Very true.

But as this represents some work, and a= s I have a company to run IRL, I would say that, before jumping into that t= echnical solution, there should be consensus here that we really need three= serializations to make virtual worlds interoperable.

Who on this list, besides the 700 kilograms gorilla (Linden Lab, their = own words IIRC ;-) ), has a strong desire and an use case for non-binary fo= rmats?

--
Cathy
--001636c5a26795be270463cfbd18-- From cathypfeffer@gmail.com Thu Feb 26 02:57:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A70BD28C1F8 for ; Thu, 26 Feb 2009 02:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.314 X-Spam-Level: X-Spam-Status: No, score=-1.314 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBL5z5ZQN7jn for ; Thu, 26 Feb 2009 02:57:05 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 7CD5F28C187 for ; Thu, 26 Feb 2009 02:57:04 -0800 (PST) Received: by bwz26 with SMTP id 26so435869bwz.37 for ; Thu, 26 Feb 2009 02:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=IS8wWaXShOPlJRrH3fusPCyX433zemmeNZFRQit6AwM=; b=vlj3QExAfskxaVwverbbMMj7enBG/RQgLQpVZk6X1/uDZlRy70gFqv4wo8YGF0c4g/ 2GTCJoK5mACW6xs/yVa+yt5w/qc3w3kcBKYumJGSl6Veb8LDUmlW2JpuDRiI4F7xy/t/ TJteNIZwPNAQImIwzJ9NcD799drR8FLq/v9ag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=kBQ/AFIUPlE7E8VO9Lf/VRFc5fpHmZFsbfjn9Now986V+gNAxrCZUebieIkzTnUaBF 1IkjYdVFVrQ/D8Glv8aRQcp/u1zo6VykoLy7GSjW9NbAtJlRQrmZHtd24rItJhWpHqJ8 5KWXckwJsHLGbCDoRLZP/5b9OhU7I8Rwb5wSo= MIME-Version: 1.0 Received: by 10.181.216.12 with SMTP id t12mr411602bkq.122.1235645844726; Thu, 26 Feb 2009 02:57:24 -0800 (PST) Date: Thu, 26 Feb 2009 11:57:24 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636c59860a4a3630463d03798 Subject: [mmox] Better XML maps X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 10:57:05 -0000 --001636c59860a4a3630463d03798 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Meadhbh, I know this contradicts what I just said on the list, but I am trying to be very honest intellectually, so here is a technical trick to make XML maps a less "terrible serialization": Replace ... Taper_X 0.5 ... with ... 0.5 ... That's 20 characters versus 11, but so much more DOM and XPath friendly. Corresponding XPath expression is map/entry[@key = 'Taper_X']/float You can go down to 12 bytes if you use instead of . (but believe me, drop XML and JSON serializations... simple is beautiful) -- Cathy --001636c59860a4a3630463d03798 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Hi Meadhbh,


I know this contradicts what I just said on the list, but I am trying to be very honest intellectually, so here is a technical trick to make XML maps a less "terrible serialization":


Replace

<map>

...

<key>Taper_X</key>

<float>0.5</float>

...

</map>

with

<map>

...

<entry key="Taper_X">

<float>0.5</float>

</entry>

...

</map>


That's 20 characters versus 11, but so much more DOM and XPath friendly.


Corresponding XPath expression is

map/entry[@key = 'Taper_X']/float


You can go down to 12 bytes if you use <e> instead of <entry>.


(but believe me, drop XML and JSON serializations... simple is beautiful)

--
Cathy
--001636c59860a4a3630463d03798-- From cathypfeffer@gmail.com Thu Feb 26 04:10:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFED93A6803 for ; Thu, 26 Feb 2009 04:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuE857mFZte6 for ; Thu, 26 Feb 2009 04:10:30 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id 8DC523A6801 for ; Thu, 26 Feb 2009 04:10:29 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so258803fkf.5 for ; Thu, 26 Feb 2009 04:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=lq9Db5C92Zy1eNjmiMaB17DTzl+usgZqvXbTvY0YJLE=; b=wf8I9x1VL+mGu3NEpaCiElWAzokWmct61B3ZKsqW0QwejtbKcJ8gCUDlHe95ri0Mfb /h2zqfeE7LU88wkZgfWPBrkzzgrGfBU7mreBNk55Gg6itvaYGL+yEPlM5bnXqmUwpifX hiflzmzgLna0k3DIfAjLYyFSQFSsV5Q0Ilx78= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ybb4QgXKRpJLm+DFvLpy5UWTwOxmPinngKCFECly3cJFsuhs5WC59NDpCSoSGb9SJg h1QGabhlC0rdVzcBg1Y4DIbk8bg2R7YkFm9DmI7NYZ+khRzpSk8wfLhrEYhPYiJlDbpX 7b+ncoJOwQIFQTTOOgMyNG0rFkdLRPGaMBnFQ= MIME-Version: 1.0 Received: by 10.181.209.1 with SMTP id l1mr429030bkq.139.1235650250016; Thu, 26 Feb 2009 04:10:50 -0800 (PST) Date: Thu, 26 Feb 2009 13:10:49 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016e6d6484e3808dc0463d13ed9 Subject: [mmox] Automatic generation of the schema X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 12:10:31 -0000 --0016e6d6484e3808dc0463d13ed9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Jon said: > My question is not just to you, but to the list: > We view the xxSD description language as a source language, from which > we could compile various outputs. > Could one of those outputs be a DTD and an XSD? Thus, we don't create > the DTD or XSD directly; we create the mapping from xxSD input to DTD > and XSD output. I can't answer for the list, so I will answer for myself ;-) : Yes, that should be possible. Infinity asked too if there would be a mechanical way to map conceptual xxSD into the "XML way". I think the answer is "yes", although it has more a chance to be a "compilation" from xxIDL to XSD or DTD, than from binary xxSD. Or it could even take the form of a C++ library that would produce both the schema and the data. Not sure. That would need to be investigated. Currently, LLSD data flow mixes three things: - the data (102.5 meters); - the data type (float); - the field name (POSITION_X). While this is acceptable in a binary stream, and provides an incredible flexibility, it is most unusual in the XML world, and also wastes a lot of bandwidth (compare 'i' to ""). Okay, you can compress with gzip, but then you both lose human readability and processor cycles. In the XML world, - data (102.5 meters) appears in the data packets; - data type (integer) goes to the XSD schema; - the field name (POSITION_X) appears both in the data packets (but as a tag, not as ordinary data), and in the XSD schema. The advantage of separating the schema from the data is that you can send the schema only once at the beginning of the communication of a viewer with a given simulator. You don't need to repeat that the X position is a float each time your avatar moves 10 centimeters to the left. Of course, all these efforts make sense only if there is a real need for XML stuff. -- Cathy --0016e6d6484e3808dc0463d13ed9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jon said:
> My question is not just to you, but to the list:
> = We view the xxSD description language as a source language, from which
= > we could compile various outputs.
> Could one of those outputs b= e a DTD and an XSD? Thus, we don't create
> the DTD or XSD directly; we create the mapping from xxSD input to DTD =
> and XSD output.

I can't answer for the list, so I will = answer for myself ;-) :

Yes, that should be possible. Infinity asked= too if there would be a mechanical way to map conceptual xxSD into the &qu= ot;XML way". I think the answer is "yes", although it has mo= re a chance to be a "compilation" from xxIDL to XSD or DTD, than = from binary xxSD. Or it could even take the form of a C++ library that woul= d produce both the schema and the data. Not sure. That would need to be inv= estigated.

Currently, LLSD data flow mixes three things:
=C2=A0 - the data (102= .5 meters);
=C2=A0 - the data type (float);
=C2=A0 - the field name (= POSITION_X).

While this is acceptable in a binary stream, and provid= es an incredible flexibility, it is most unusual in the XML world, and also= wastes a lot of bandwidth (compare 'i' to "<integer><= ;/integer>"). Okay, you can compress with gzip, but then you both l= ose human readability and processor cycles.

In the XML world,
=C2=A0 - data (102.5 meters) appears in the data p= ackets;
=C2=A0 - data type (integer) goes to the XSD schema;
=C2=A0 -= the field name (POSITION_X) appears both in the data packets (but as a tag= , not as ordinary data), and in the XSD schema.

The advantage of separating the schema from the data is that you can send the schema only once at the beginning of the communication of a viewer= with a given simulator. You don't need to repeat that the X position i= s a float each time your avatar moves 10 centimeters to the left.

Of course, all these efforts make sense only if there is a real need fo= r XML stuff.

--
Cathy
--0016e6d6484e3808dc0463d13ed9-- From cathypfeffer@gmail.com Thu Feb 26 04:41:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3FB3A6BAA for ; Thu, 26 Feb 2009 04:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VD2NpPOqmkfz for ; Thu, 26 Feb 2009 04:41:50 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 0616D3A6AAA for ; Thu, 26 Feb 2009 04:41:49 -0800 (PST) Received: by bwz26 with SMTP id 26so480217bwz.37 for ; Thu, 26 Feb 2009 04:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=1lOYHWzM99R9WWw5F0oKVZRk1KXm/VaAY8x4LkOztCE=; b=hDNHGqYHuV+50ocI7nV0w+vutH0phN01rLShq+i+exZIvJeNKV8Vl1SvAJUq25DJPP N2kQABt0RBcvdjQbGMJQwyPSkqdIhyc90xttcTA7RMuNMVTeWWmn46Dsdpjk/gomTisj 49dMzPBPu+SL2iZ0KbWFjgw3B267SDRQFX8As= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=TPZdZxjZ96H+cO+1LO2OM3Nuyf5Sq4TpEVUdDToRZbvrBNw8KJuLKABBIP+K7/5GEM v7tqV62MKYTYUHN5tkYH1gLUyAP+tOObKBXA9nBcKqXgueCXkQx1XUTW2O8f4s7eBb8H uzhSpbDO1ZT37GQIX9g5oTW1n+1eq+Zw3uLXk= MIME-Version: 1.0 Received: by 10.181.48.13 with SMTP id a13mr446207bkk.43.1235652130369; Thu, 26 Feb 2009 04:42:10 -0800 (PST) Date: Thu, 26 Feb 2009 13:42:10 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001485f91c304beff80463d1ae14 Subject: [mmox] Jeeps and jungle roads X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 12:41:51 -0000 --001485f91c304beff80463d1ae14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Lisa wrote: > In a *standard*? Cathy does not. She flags an error. The standard > that would have produced the interoperability so far in your example > would have said "bar is an integer". > > In fact, if there's agreed interoperability between Cathy, Meadhbh and > David on the foo, bar and baz semantics, then none of them need to be > annotated with their datatypes. Yeah. That's strange, isn't it? ;-) But remind the Lindens are pioneers, and pioneers don't always think in the conventional way ;-). I'd like to take Infinity's defense on this one. A standard is about agreeing. But a standard also needs to evolve. It needs to address the case where some people haven't / don't want to implement 100% of it. A standard needs to acknowledge the fact that everyone has not the same user base and the same use cases. In the VW case there is the additional requirement that, even inside of a single grid, the protocol won't be the same on each simulator, and end users will also use viewers that handle different versions of the protocol. Also, Virtual Worlds are very young and the technology evolves at an incredible rate. That's a mess (sorry for the word) that even HTML, another client-server protocol that has evolved a lot over time, never had to face at the same scale. I think that's why Lindens have designed something (binary LLSD) that beats in flexibility even what modern XML does, while remaining very simple (sometimes oversimplified, if we consider that all scalars are signed 32 bits). There is a price to pay for this flexibility and simplicity, for example they need to send the data types together with the data, and they have to define a whole range of on-the-fly conversions, but this price is minor when compared to the benefits. > try: > barval = int(xmldoc.getElementsByTagName('bar').data) > except ValueError: > return new ErrorResponse(400, "Bad Request") I think that's precisely what the Lindens want to avoid. They never want to reject data, they rather attempt to do their best with unexpected data, because the user experience must continue, even in a degraded mode, and never have the viewer display "400 Bad Request". If protocols were cars, then LLSD would be a jeep. Jeeps don't stop when the road is not perfectly flat and unencumbered. -- Cathy --001485f91c304beff80463d1ae14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lisa wrote:
> In a *standard*? =C2=A0Cathy does not. =C2=A0She flags = an error. =C2=A0The standard
> that would have produced the interoper= ability so far in your example
> would have said "bar is an inte= ger".
>
> In fact, if there's agreed interoperability between Cathy,= Meadhbh and
> David on the foo, bar and baz semantics, then none of = them need to be
> annotated with their datatypes.

Yeah. That&#= 39;s strange, isn't it? ;-) But remind the Lindens are pioneers, and pi= oneers don't always think in the conventional way ;-).

I'd like to take Infinity's defense on this one.

A stand= ard is about agreeing. But a standard also needs to evolve. It needs to add= ress the case where some people haven't / don't want to implement 1= 00% of it. A standard needs to acknowledge the fact that everyone has not t= he same user base and the same use cases. In the VW case there is the addit= ional requirement that, even inside of a single grid, the protocol won'= t be the same on each simulator, and end users will also use viewers that h= andle different versions of the protocol. Also, Virtual Worlds are very you= ng and the technology evolves at an incredible rate. That's a mess (sor= ry for the word) that even HTML, another client-server protocol that has ev= olved a lot over time, never had to face at the same scale.

I think that's why Lindens have designed something (binary LLSD) th= at beats in flexibility even what modern XML does, while remaining very sim= ple (sometimes oversimplified, if we consider that all scalars are signed 3= 2 bits). There is a price to pay for this flexibility and simplicity, for e= xample they need to send the data types together with the data, and they ha= ve to define a whole range of on-the-fly conversions, but this price is min= or when compared to the benefits.

> try:
> =C2=A0 =C2=A0 barval =3D int(xmldoc.getElementsByTagN= ame('bar').data)
> except ValueError:
> =C2=A0 =C2=A0 r= eturn new ErrorResponse(400, "Bad Request")

I think that&#= 39;s precisely what the Lindens want to avoid. They never want to reject da= ta, they rather attempt to do their best with unexpected data, because the = user experience must continue, even in a degraded mode, and never have the = viewer display "400 Bad Request".

If protocols were cars, then LLSD would be a jeep. Jeeps don't stop= when the road is not perfectly flat and unencumbered.

--
Cathy<= br> --001485f91c304beff80463d1ae14-- From cathypfeffer@gmail.com Thu Feb 26 05:02:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726C43A6BE1 for ; Thu, 26 Feb 2009 05:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy7PSclbibtl for ; Thu, 26 Feb 2009 05:02:37 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 1CC173A6AAA for ; Thu, 26 Feb 2009 05:02:36 -0800 (PST) Received: by bwz26 with SMTP id 26so489986bwz.37 for ; Thu, 26 Feb 2009 05:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=yDWBaeXAXv136pTw3VlotnbUHwW59a3EmAi4CddSfb0=; b=Cj3VQTM5HMOxQb+kDjos1jIHrjNzfzsUHzg4LRBVSd24303C4VmJ0OCJMZ7UVRtHeJ EjzD645FzoPhp6C+h6gZhBZ5OoHMA/VU1cvqFPli7ZwymwoEdn+aNL8xfWxdJU7CzUyI IQuIIkNof49Arcs5mtwQJh4lUWrX313sHocCc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hoh0DC6awgONqlNAkau8Ba8lQ+bBRd/bTCfERehzJZ2vZIN5Q6wbFg8902a8oZ5aLs dVCEejy0WW1YhaJOKbAB5pZtS2v6RGxhqE6MSNvfOmyMOoXfAmSQCBosU222nBvHxR0E fWvL+MqKpHbpTwxseS9wrJSaMzNaLrTHKqls0= MIME-Version: 1.0 Received: by 10.181.228.9 with SMTP id f9mr447420bkr.103.1235653377792; Thu, 26 Feb 2009 05:02:57 -0800 (PST) Date: Thu, 26 Feb 2009 14:02:57 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636697576a61c260463d1f8e9 Subject: [mmox] Good XML or no XML at all X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:02:38 -0000 --001636697576a61c260463d1f8e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Catherine, this is excellent advice that you're giving us about XML, but the > underlying hint to "do everything in XML to do it properly" is not a > worldview that I can subscribe to everywhere, for very practical and > somewhat insurmountable RL engineering reasons. > > Using XML for communication with Limited Capability Clients can easily be a > deal breaker in the application domain that we're talking about, (...) We fully agree. XML does not fit well into virtual worlds context. Then don't do XML. My point was: if you are really to do XML (for whatever obscure reason which I don't know yet), then, at least, please, do it correctly. Don't just transpose one-by-one the binary serialization. When I translate a text from German to French, for example, I don't simply replace each German word with the equivalent French word. The result would be terrible ;-). (And yes, protocols also have a lot of context, just like human languages. Behind XML there is a lot of paradigms and good practice, it does not just boil down to a syntax) Binary serialization goes well on Limited Capacity Clients. OK. Choose this one. Don't misunderstand me. I'm a big XML fan. I use XML everyday and partially make a living out of it. But there are simply cases, like streamed video, where it is not the right technical choice. -- Cathy --001636697576a61c260463d1f8e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Catherine, this is excellent advice that you're giving us about XM= L, but the
> underlying hint to "do everything in XML to do it p= roperly" is not a
> worldview that I can subscribe to everywhere= , for very practical and
> somewhat insurmountable RL engineering reasons.
>
> Using = XML for communication with Limited Capability Clients can easily be a
&g= t; deal breaker in the application domain that we're talking about,=C2= =A0 (...)

We fully agree. XML does not fit well into virtual worlds context. Then= don't do XML.

My point was: if you are really to do XML (for wh= atever obscure reason which I don't know yet), then, at least, please, = do it correctly. Don't just transpose one-by-one the binary serializati= on.

When I translate a text from German to French, for example, I don't= simply replace each German word with the equivalent French word. The resul= t would be terrible ;-).

(And yes, protocols also have a lot of cont= ext, just like human languages. Behind XML there is a lot of paradigms and = good practice, it does not just boil down to a syntax)

Binary serialization goes well on Limited Capacity Clients. OK. Choose = this one.

Don't misunderstand me. I'm a big XML fan. I use X= ML everyday and partially make a living out of it. But there are simply cas= es, like streamed video, where it is not the right technical choice.

--
Cathy
--001636697576a61c260463d1f8e9-- From jesrad@gmail.com Thu Feb 26 05:56:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8612C3A6A83 for ; Thu, 26 Feb 2009 05:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmfv5me-CGJm for ; Thu, 26 Feb 2009 05:56:00 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 0F9C43A692E for ; Thu, 26 Feb 2009 05:55:59 -0800 (PST) Received: by bwz26 with SMTP id 26so513995bwz.37 for ; Thu, 26 Feb 2009 05:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8/2V7JyA7edxye5i8IvUBWpjELgpIo4qyi6Wxe0i27A=; b=CYgbhZ/0CxZ4I9xjXXiKQj3wFmrSwYYteW1Y8aewlhUUOG/YVHIhfm7jhj4FiGNGe6 A2a+5ldMB+K0bpkeWXpChlbB9517HDAIA+Rcrqyj/VGH8l0nDKqY5Xb5c+vmCAA9Wtql Vnnl1UlFtJT7VJf20a/OywXMn5LZ2e6GKN1wA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=P21Fx5ERlTcKipFIMeunVOGhzNQD511nv3fjgZ49IGZv9GvMWBBsO7Z6OfJ7dy1w3V Ojlw9kYn9drH6J+DO1JNydJNv6Sdq3Tmt2V35b0ACpIQO1uSUS87zOQcF+GHX9CEWkmK aKPSMvOb+HTa5xCZiq0gjgk4tzplSvUNPx63w= MIME-Version: 1.0 Received: by 10.181.139.10 with SMTP id r10mr471841bkn.11.1235656580456; Thu, 26 Feb 2009 05:56:20 -0800 (PST) In-Reply-To: References: <27a487810902241253v1f2c5b82q9dac1cd39e34ec07@mail.gmail.com> Date: Thu, 26 Feb 2009 14:56:20 +0100 Message-ID: <53cd6c2e0902260556p636ed903w5e2862326ec42ea1@mail.gmail.com> From: Jesrad To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org, William George Subject: Re: [mmox] Time to rethink the commercial angle X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:56:01 -0000 To be honest the thing that really stops a lot of content from moving out of the SL grid and onto the open grids, is the lack of micropayment on the latter. Otherwise it's fairly trivial to upload the same textures and paste the same scripts from one to the other. I sure would appreciate an export/import tool for prim structures, but even there exact copies are easy to make, though tedious. On Thu, Feb 26, 2009 at 7:57 AM, Morgaine wrote: > I need to correct something on my previous post: > > On Thu, Feb 26, 2009 at 4:53 AM, Morgaine > wrote: >> >> >> Since the free and open grids have assets that are either public domain = or >> licensed under free-distribution licenses like GPL, BSD, CC and others, = it >> makes no sense whatsoever to hold back interop between such open worlds = just >> because the proprietary worlds can't get their act together. >> >> Fortunately, they're not being held back in the slightest. ;-) >> > > I should qualify my last line slightly.=A0=A0 The open worlds are not bei= ng held > back for interop among themselves. > > However, they are being held back currently by the fact that items create= d > on proprietary worlds without any kind of encumbrances ("full perm" in SL > terminology) cannot be marked as "interoperable" by their creators, and > hence cannot currently be released to open grids despite this being their > author's desire. > > This is a failure of proprietary grids or worlds to put their interop mon= ey > where their mouth is, given that there are no rights, permissions nor > licensing barriers to permitting this.=A0 That's a pity, and it's not spe= cific > to SL. > > Morgaine. > > > > > > > > On Thu, Feb 26, 2009 at 4:53 AM, Morgaine > wrote: >> >> On Tue, Feb 24, 2009 at 8:53 PM, William George >> wrote: >> >>> In order to sidestep some of the thorny (and circular) discussions on >>> property rights, as well as the petty technical arguments backed by >>> "customer interests", I propose that only worlds with free access and o= nly >>> unencumbered objects be allowed to interoperate, at least to start. >> >> >> The word "allowed" isn't appropriate since there is no permission requir= ed >> to distribute unencumbered objects nor to interoperate. >> >> Apart from that though, the spirit and promise and viability of what you >> envisage is clear.=A0 The future of open grids is unbounded, simply beca= use >> unencumbered object exchange is unhampered by any constraints except >> computer resources, and enthusiasm in the open community probably exceed= s >> the known physical constraints of teh universe. ;-) >> >> Since the free and open grids have assets that are either public domain = or >> licensed under free-distribution licenses like GPL, BSD, CC and others, = it >> makes no sense whatsoever to hold back interop between such open worlds = just >> because the proprietary worlds can't get their act together. >> >> Fortunately, they're not being held back in the slightest. ;-) >> >> Morgaine. >> >> >> >> >> >> >> On Tue, Feb 24, 2009 at 8:53 PM, William George >> wrote: >>> >>> In order to sidestep some of the thorny (and circular) discussions on >>> property rights, as well as the petty technical arguments backed by >>> "customer interests", I propose that only worlds with free access and o= nly >>> unencumbered objects be allowed to interoperate, at least to start. >>> >>> The commercial objectives are taking up too much of=A0 _my_ limited >>> bandwidth. >>> >>> Remember when the internet did not have any commercial interests? This >>> was up until 1994, not really that long ago. >>> >>> Waka >>> >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >> > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From cathypfeffer@gmail.com Thu Feb 26 05:59:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F7D328C2A0 for ; Thu, 26 Feb 2009 05:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbai7QfZPMHh for ; Thu, 26 Feb 2009 05:59:02 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id EF63528C0E0 for ; Thu, 26 Feb 2009 05:59:01 -0800 (PST) Received: by fxm24 with SMTP id 24so525677fxm.37 for ; Thu, 26 Feb 2009 05:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=0FFXcBy1ewlzbU6g4IsfsXowEOr4pLCokUL4x9iquKY=; b=S8Su0e2TR+1Inu1MtMgo/Z5nL0beZjKorGb8J3FCYDeAFiOgoWzXxqOFDe4PjKOft1 nsM6jh9PzBOVDaToXiaaT1EMqLuijX0VzkN+0Tpg5P6CAAJGPEfbqvGp4tqay97vLzAC MRKcOBJlN8DReGrcrKYnN0XPrgcXV2JJOK7mM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Dn8QsXOow4s7oDzFPR5QkYBqqJ1vEJx51AnKjn7q5Pm620iLFUiuaMvNCulnJz5nxb T9KfD9A6uWBD39lrC0Mh2ZwtcvZ0JvbPINNwD/iyalK0GgP2nVD54xuuTZEQYbU1fEEW x0Osbi9+inuWkHm5UOjLTYcCye7nM37K1aS0c= MIME-Version: 1.0 Received: by 10.181.218.14 with SMTP id v14mr467449bkq.54.1235656762319; Thu, 26 Feb 2009 05:59:22 -0800 (PST) Date: Thu, 26 Feb 2009 14:59:22 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=0016e6d99bef61e4280463d2c2a1 Subject: [mmox] Field names as numbers? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 13:59:03 -0000 --0016e6d99bef61e4280463d2c2a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Does the current binary encoding encode the actual names and types of > properties before sending the values? It does not encode them *before* sending them. It intermixes the data, the data types and the field names. The data is always next to its type and next to its name. > If so, you could probably cut out > at least half, if not more, using the separate schema method. Yes we could. Yes it would be a significant bandwidth win. I am not sure I like this idea of replacing keys like "Nose_Orientation" with numbers like 443: - a protocol dump would be harder to debug (you'd need a table to know what each field means). - it would be less simple in a program because you would need to look up in a table to solve the indirections - it is error prone (it is easier to mix field 443 with field 442 than to mix field "Nose_Orientation" with field "Associated_Sound") - if you have been unable to transmit the packet containing the table, you can't do anything anymore I have very bad memories of ISO 2709 (http://en.wikipedia.org/wiki/ISO_2709) which also takes the "tags are numbers" approach. But I realize the reasons above are somehow weak. With such a reasoning, we would not use schemas with XML files either. Perhaps Infinity has better arguments pro or against it. -- Cathy --0016e6d99bef61e4280463d2c2a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Does the current binary encoding encode the actual names and types of =
> properties before sending the values?

It does not encode th= em *before* sending them. It intermixes the data, the data types and the fi= eld names. The data is always next to its type and next to its name.

> If so, you could probably cut out
> at least half, if not more, using the separate schema method.

Yes we could. Yes it would be a significant bandwidth win.

I am = not sure I like this idea of replacing keys like "Nose_Orientation&quo= t; with numbers like 443:
=C2=A0- a protocol dump would be harder to deb= ug (you'd need a table to know what each field means).
=C2=A0- it would be less simple in a program because you would need to look= up in a table to solve the indirections
=C2=A0- it is error prone (it i= s easier to mix field 443 with field 442 than to mix field "Nose_Orien= tation" with field "Associated_Sound")
=C2=A0- if you have been unable to transmit the packet containing the table= , you can't do anything anymore
I have very bad memories of ISO 2709= (http://en.wikipedia.org= /wiki/ISO_2709) which also takes the "tags are numbers" appro= ach.

But I realize the reasons above are somehow weak. With such a reasoning= , we would not use schemas with XML files either. Perhaps Infinity has bett= er arguments pro or against it.

--
Cathy
--0016e6d99bef61e4280463d2c2a1-- From dyerbrookme@juno.com Thu Feb 26 06:45:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6A028C271 for ; Thu, 26 Feb 2009 06:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Au6o43TdFUm for ; Thu, 26 Feb 2009 06:45:48 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 3424F28C213 for ; Thu, 26 Feb 2009 06:45:48 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail20.vgs.untd.com [10.181.12.160]) by smtpout02.vgs.untd.com with SMTP id AABE4PLZ7AVGXCFA for (sender ); Thu, 26 Feb 2009 06:45:17 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkN+dyWk/uqL+0e8aC9aetVYw== Received: (from dyerbrookme@juno.com) by webmail20.vgs.untd.com (jqueuemail) id PAB7R4C3; Thu, 26 Feb 2009 06:44:40 PST Received: from [68.161.198.3] by webmail20.vgs.untd.com with HTTP: Thu, 26 Feb 2009 14:44:33 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Thu, 26 Feb 2009 14:44:33 GMT To: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090226.094433.12397.0@webmail20.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 8:4:2726866956 X-MAIL-INFO: 3d2e3ebe5bdedadfcb5b9a3a4b9a9a4a4f6fc79e9e935ba3ae0e4f4fce X-UNTD-Peer-Info: 10.181.12.160|webmail20.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 159 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 14:45:49 -0000 > On Tue, Feb 24, 2009 at 8:53 PM, William George >> wrote: >> >>> In order to sidestep some of the thorny (and circular) discussion= s on >>> property rights, as well as the petty technical arguments backe= d by >>> "customer interests", I propose that only worlds with free acce= ss and only >>> unencumbered objects be allowed to interoperate, at leas= t to start. >> >> >> The word "allowed" isn't appropriate since there is no permission = required >> to distribute unencumbered objects nor to interoperate. >> >> Apart from that though, the spirit and promise and viability of wh= at you >> envisage is clear.? The future of open grids is unbounded, sim= ply because >> unencumbered object exchange is unhampered by any constra= ints except >> computer resources, and enthusiasm in the open community = probably exceeds >> the known physical constraints of teh universe. ;-) >> >> Since the free and open grids have assets that are either public doma= in or >> licensed under free-distribution licenses like GPL, BSD, CC and= others, it >> makes no sense whatsoever to hold back interop between su= ch open worlds just >> because the proprietary worlds can't get their ac= t together. >> >> Fortunately, they're not being held back in the slightest. ;-) >> >> Morgaine. I'd like to debunk an urban legend here, the persistent meme that there = is "all this pent-up desire to create and distribute free objects" and t= hat evil proprietary software companies, greedy landlords who oppose int= eroperability, and other assorted creator-fascists are all that is stand= ing in the way of a huge tide of wonderful free full-permed user-generat= ed objects flowing throughout the Metaverse. There is no such thing, despite the persistence of the hawking of this m= eme by interested parties. First of all, given that the Internet *is* a copy machine, nobody needs = a special Creative Commons license or a special interoperability regime = to see stuff distributed. It happens anyway, and it's only a small perce= ntage of nerds who will peer at the fine print and reproduce the license= s in the finicky way that the CC boosters wish. I'd like to see statisti= cs on the actual issuing of CC "licenses" and actual compliance versus n= on-use (especially that second part, always forgotten!) to be able to as= sess this more scientifically, rather than ideologically. Judging from t= he SL context, the CC lobby is niche and tiny and not representative of = the wishes of the overwhelming majority of creators who are there to *se= ll* items in a micropayment system *with permissions*. The fact is, each time this discussion is raised in SL, no creators or = merchants clamour to be able to perm up their creations for other worlds= . The JIRA "yes" votes aren't about the desire to "free" content that is= trivial to "free" anyway; it's about placing restrictions on content to= prevent theft. There is a tiny cadre of persistent lobbyists, usually s= andboxing weapons gadget or weapons makers whose sales depend on word of= mouth in niche categories rather than search/places, who claim that thi= s is "needed" in "new markets". It's not. Most merchants when you talk t= o them about this don't understand the issues, and when it is explained,= they instantly want the ability to *turn off* distribution in the open = worlds to prevent theft. They simply don't buy the argument that they wi= ll "get more customers" if they join the stampede to the Metaverse becau= se...there are no currencies or economies in those other worlds (duh!). = = You can't openly scorn commerce and currency systems, as Adam Frisby has= done, and indicate it's only a modular add-on, and then in the same bre= ath, say, oh, merchants want interoperability because this opens new mar= kets for them. There aren't new markets in technocommunist regimes, ther= e are only new opportunities for theft and loss. I think most creators are waiting to see just how it goes with the open = worlds and the willingness of platform operators to abide TOS and DMCA t= akedown notices. I think they'd adjust their behaviours accordingly. If = it seemed that "trustworthy" didn't just mean some wonky server symmetry= but actual human behaviour to trust, then they'd check off their produc= ts. The minute this broke down and incidents of theft began appearing, t= hey'd start unchecking. They would literally follow the news every day a= nd check accordingly and would want this flexibility. They'd even begin = to demand granularity -- check off for this world, and not that world. The confusion on the reality of this situation comes from the widespread= practice of making freebies as loss-leaders or to help newbies to build= up customer lists for the future. These two very fundamental motivation= s for making full-perm items are utterly absent as a context in open sim= s where there is absolute scorn for commerce and currency *and where the= re is no economy*. So to claim that because merchants have all these fre= ebies with full perms that their intent is to spread freebies in other c= ontexts without commerce is duplicitous. = Prokofy Neva ____________________________________________________________ Digital Photography - Click Now. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTDvmQrhHg8wV6uSGl77n5n= qNdiLHLM4DMe4n8BxGiHHEDa6afMWLu/ From mccahill@duke.edu Thu Feb 26 07:15:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D89528C2AE for ; Thu, 26 Feb 2009 07:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSbyl0V2a5Sj for ; Thu, 26 Feb 2009 07:15:38 -0800 (PST) Received: from smtp.duke.edu (smtp-03.oit.duke.edu [152.3.174.16]) by core3.amsl.com (Postfix) with ESMTP id A686B28C11A for ; Thu, 26 Feb 2009 07:15:36 -0800 (PST) Received: from smtp.duke.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 72E488172; Thu, 26 Feb 2009 10:15:57 -0500 (EST) Received: from dyn-152-3-125-25.oit.duke.edu (dyn-152-3-125-25.oit.duke.edu [152.3.125.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.duke.edu (Postfix) with ESMTP id 2C0B08144; Thu, 26 Feb 2009 10:15:57 -0500 (EST) Message-Id: <21354166-1CB0-4124-A46E-12F336CB955A@duke.edu> From: "Mark P. McCahill" To: mmox@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 10:15:55 -0500 References: <05E4C6F6-14A9-42AF-9314-A51F8DF0A7C3@lindenlab.com> X-Mailer: Apple Mail (2.930.3) X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2009.2.26.150143 Subject: [mmox] A question for the moderator and MMOX chairs X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 15:15:39 -0000 Is it feasible to attempt to form two working groups? Morgaine points out that there are essentially two camps in this mailing list - one focused on the AWG/OGP work and another interested in a broader vision for MMOX and suggests splitting the discussion. David Levine has a strawman proposal for MMOX that is significantly different in intents and focus from the OGP proposal that was originally put forward for this group. How are we going to reconcile this difference in approach? On Feb 25, 2009, at 7:59 PM, Morgaine wrote: > On Tue, Feb 24, 2009 at 4:08 PM, Infinity Meadhbh Hamrick > wrote: > > so... what started as a pleasant little proposal to take our (the > awg's) pleasant little protocol (ogp) kick it around in public (the > mmox mailing list) and potentially generate some RFCs from it seems > to have spawned a number of discussions. _all_ of the discussions > are interesting, but perhaps not all of them are germane to the > proposed task. > > > I suspect that this is precisely the source of many of the problems > that have preoccupied MMOX discussions across many threads. Giving > OGP the IETF treatment and generating some very useful RFCs is an > admirable cause, an extension of AWG work, and would greatly advance > interop between SL-like worlds. > > Unfortunately, instead of forming an OGP group, MMOX was defined as > an interop group expressly targetted at providing interop across > many different virtual worlds and MMO technologies. The name of the > group makes this clear, and the original statements from both co- > chairs endorse the broad view even more vividly. > > Clearly there is a disconnect between intent and presentation. > > In this much wider VW context, OGP can at most be one input to the > process, and the end result of a successful workgroup would probably > be nothing like OGP even if it incorporated some of the good ideas > from it. > > This is the heart of the matter. The Linden goal as you describe it > above is one thing, but the IETF group was set up with a totally > different declared intent. > > I wonder if perhaps we could do both, and thus avoid the conflict: > separate OGP and MMOX workgroups. An OGP workgroup would be an > excellent thing to work on, and as an AWG member I would certainly > like to help fill in the parts that OGP has not yet defined. But a > MMOX group that targets the broader reaches of VW interop is also > highly worthwhile, and much more visionary, and valuable to many > more people. > > > Morgaine. > From jesrad@gmail.com Thu Feb 26 07:32:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF143A6A4C for ; Thu, 26 Feb 2009 07:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4YBA08eG2Ka for ; Thu, 26 Feb 2009 07:32:19 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 3A96228C213 for ; Thu, 26 Feb 2009 07:32:19 -0800 (PST) Received: by fxm24 with SMTP id 24so571672fxm.37 for ; Thu, 26 Feb 2009 07:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=I8bHSfNyhLj0b/a39kU67pj2w13t8VfMNUSfFaW8Ifo=; b=wv/oHrdZFqOpI7I0MyrFwu1npEXeczmJktGVGmRXuclMyNpArnIK2g76nBcXWxUb8I WGvu+KD36UbKCaRz+4t0Q9KwhVIkJ2nsZSGw4aVtcQVs8jW1l98KPGitliLpebPxkrM8 m/pRRlmQ1oY/tZ3rSZMTV+3w6aGubPw2iSFts= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=lZpPEOBcl2nCVD+hPT68TBe8vWA2wrNE15jkSrGXQ4VvAS6ErDx2w5G82kKfaEpBy/ x/g19XSMOPjmzgC0rBPAGJyY91wBoX7vQGrwMiE3o55ehaKAGxdj3c4lxfq8kbookaHL qeHnpt5H1XG10ZMc03sBCfZDvAAfGIz1em9RU= MIME-Version: 1.0 Received: by 10.181.222.1 with SMTP id z1mr490552bkq.112.1235662359639; Thu, 26 Feb 2009 07:32:39 -0800 (PST) In-Reply-To: <20090226.094433.12397.0@webmail20.vgs.untd.com> References: <20090226.094433.12397.0@webmail20.vgs.untd.com> Date: Thu, 26 Feb 2009 16:32:39 +0100 Message-ID: <53cd6c2e0902260732y71bad6afka351f26526eab5d6@mail.gmail.com> From: Jesrad To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 159 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 15:32:21 -0000 The english language sucks for not having two different words for free as-in-beer and free as-in-speech, like how french has gratuit and libre respectively. It makes debate over such topics pretty difficult if not downright useless, in addition to being off the scope of MMOX (at the moment at least). On Thu, Feb 26, 2009 at 3:44 PM, dyerbrookme@juno.com wrote: >> On Tue, Feb 24, 2009 at 8:53 PM, William George >>> wrote: >>> >>> In order to sidestep some of the thorny (and circular) discussions = on >>> property rights, as well as the petty technical arguments backed by = >>> "customer interests", I propose that only worlds with free access and o= nly >>> unencumbered objects be allowed to interoperate, at least to start. >>> >>> >>> The word "allowed" isn't appropriate since there is no permission > required >> to distribute unencumbered objects nor to interoperate. >>> >> Apart from that though, the spirit and promise and viability of what= you >> envisage is clear.? The future of open grids is unbounded, simply b= ecause >> unencumbered object exchange is unhampered by any constraints exc= ept >> computer resources, and enthusiasm in the open community probably ex= ceeds >> the known physical constraints of teh universe. ;-) >>> >>> Since the free and open grids have assets that are either public domain= or >> licensed under free-distribution licenses like GPL, BSD, CC and othe= rs, it >> makes no sense whatsoever to hold back interop between such open = worlds just >> because the proprietary worlds can't get their act together. >>> >>> Fortunately, they're not being held back in the slightest. ;-) >>> >>> Morgaine. > > I'd like to debunk an urban legend here, the persistent meme that there i= s "all this pent-up desire to create and distribute free objects" and that = evil proprietary software companies, greedy landlords who oppose interopera= bility, and other assorted creator-fascists are all that is standing in the= way of a huge tide of wonderful free full-permed user-generated objects fl= owing throughout the Metaverse. > > There is no such thing, despite the persistence of the hawking of this me= me by interested parties. > > First of all, given that the Internet *is* a copy machine, nobody needs a= special Creative Commons license or a special interoperability regime to s= ee stuff distributed. It happens anyway, and it's only a small percentage o= f nerds who will peer at the fine print and reproduce the licenses in the f= inicky way that the CC boosters wish. I'd like to see statistics on the act= ual issuing of CC "licenses" and actual compliance versus non-use (especial= ly that second part, always forgotten!) to be able to assess this more scie= ntifically, rather than ideologically. Judging from the SL context, the CC = lobby is niche and tiny and not representative of the wishes of the overwhe= lming majority of creators who are there to *sell* items in a micropayment = system *with permissions*. > > The fact is, each time this discussion =A0is raised in SL, no creators or= merchants clamour to be able to perm up their creations for other worlds. = The JIRA "yes" votes aren't about the desire to "free" content that is triv= ial to "free" anyway; it's about placing restrictions on content to prevent= theft. There is a tiny cadre of persistent lobbyists, usually sandboxing w= eapons gadget or weapons makers whose sales depend on word of mouth in nich= e categories rather than search/places, who claim that this is "needed" in = "new markets". It's not. Most merchants when you talk to them about this do= n't understand the issues, and when it is explained, they instantly want th= e ability to *turn off* distribution in the open worlds to prevent theft. T= hey simply don't buy the argument that they will "get more customers" if th= ey join the stampede to the Metaverse because...there are no currencies or = economies in those other worlds (duh!). > > You can't openly scorn commerce and currency systems, as Adam Frisby has = done, and indicate it's only a modular add-on, and then in the same breath,= say, oh, merchants want interoperability because this opens new markets fo= r them. There aren't new markets in technocommunist regimes, there are only= new opportunities for theft and loss. > > I think most creators are waiting to see just how it goes with the open w= orlds and the willingness of platform operators to abide TOS and DMCA taked= own notices. I think they'd adjust their behaviours accordingly. If it seem= ed that "trustworthy" didn't just mean some wonky server symmetry but actua= l human behaviour to trust, then they'd check off their products. The minut= e this broke down and incidents of theft began appearing, they'd start unch= ecking. They would literally follow the news every day and check accordingl= y and would want this flexibility. They'd even begin to demand granularity = -- check off for this world, and not that world. > > The confusion on the reality of this situation comes from the widespread = practice of making freebies as loss-leaders or to help newbies to build up = customer lists for the future. These two very fundamental motivations for m= aking full-perm items are utterly absent as a context in open sims where th= ere is absolute scorn for commerce and currency *and where there is no econ= omy*. So to claim that because merchants have all these freebies with full = perms that their intent is to spread freebies in other contexts without com= merce is duplicitous. > > Prokofy Neva > > ____________________________________________________________ > Digital Photography - Click Now. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTDvmQrhHg8wV6uSGl77n5nq= NdiLHLM4DMe4n8BxGiHHEDa6afMWLu/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From jesrad@gmail.com Thu Feb 26 07:34:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF9628C128 for ; Thu, 26 Feb 2009 07:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxxBNzQcxGCa for ; Thu, 26 Feb 2009 07:34:10 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 14C533A6BF6 for ; Thu, 26 Feb 2009 07:34:09 -0800 (PST) Received: by fxm24 with SMTP id 24so572635fxm.37 for ; Thu, 26 Feb 2009 07:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=w+E4wgMZv4YSPQXNCez58WlVzqMZX6FZXpTUqHAppYM=; b=aSpvz2xs0PxwBIwKGPTyxncO4o3bEBF+3UrkyzumVOHW9k8UsiWVzZI8tJJkJdNkZK mBjp/UuEHzpnvDvpvT3mu/ivNUXrAXOYjfYc7caPx7Pbq4UpLxpj2EHeWszGeiQJ19lJ C7cDzXcj3R7BUh5mCRr7HvMzNdGfzcY04KXIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=lgNLvl+dsMMAHU12jaNQ0H4Pu2gOztgROPGrYn3RzQ9CcDmhnyQGhwiN8snYuDRZLH S69EAcjcz2nlI8SPBwWh4NhPXXrZIJ8cl4F6Yz+LTZmLdeVXd/dklF7Hw5uLcnPiMmKI +FiGyBQNmpgc9fzuT1f9XbwFMx0lSUzPqUDMs= MIME-Version: 1.0 Received: by 10.181.145.7 with SMTP id x7mr486482bkn.159.1235662470700; Thu, 26 Feb 2009 07:34:30 -0800 (PST) Date: Thu, 26 Feb 2009 16:34:30 +0100 Message-ID: <53cd6c2e0902260734t7336df2dp2a97bd93b5db792b@mail.gmail.com> From: Jesrad To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [mmox] A tentative top-down analysis X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 15:34:11 -0000 As an answer to Catherine's call for more top-down views of the MMOX project to complement the bottom-up approach, here is a collection of thoughts on MMOX as viewed from afar: What exactly, deep down to the bottom line, is the function that a VW executes ? => it establishes data links (or at the very least signals links to be established) between virtual entities residing on a vast number of networked machines so they can interact. At the core, a VW is a ROUTER. A number of these special routers also include their own "network endpoints" supporting entities specific to the VW (like a combat stats database, an inventory server, etc.), for specific forms of interaction, but as far as interoperability goes these are particular cases of a more general layout (for example SL residents may set up their own combat stats databases for other SL residents to use, the case which will interest us later is whether access to a VW combat stats server should be uniform across all interoperable grids). In the context of interoperability of grids, we must treat each grid itself as a node of a relatively small P2P network. There is no "supergrid" nor any central "interoperability to go" service for existing grids to plug into as registered clients, nor will the be in any foreseeable future. Thus, the interoperability protocol has to be a decentralized protocol. (this means it will need decentralized discovery, for one, since we probably do not want to limit the protocol to hand-coded, static cross-grid links) The routing mechanism of this protocol is dictated by the inner routing that the VWs realize on their own inner network. In many cases a Virtual World mimicks functions of the real world in the way it opens and destroys links between entities, for example entities each have a location in the virtual world, and if two entities have locations that are close enough then a link of "mutual presence" is opened between them (whether this "presence routing" is done centrally or is distributed has no impact at the interoperability level, since centralized VWs will use a central gateway while P2P VWs will implement it in the nodes - only the MMOX endpoints change here). This is the minimal interaction which is universal to all "worldy" entities. There are other forms of interaction that not all entities are capable of, like collision, chat, left-mouse click, edition request or Fire Magic attack, and the set differs between VWs. (because it extends this mechanism, the interoperability protocol has to transport the universal, common interaction "routing" services like this "mutual presence": it must provide the necessary signalling for opening and closing down relevant links between the entities across grids - and though that sounds a very pedantic way of stating the obvious it still goes better with actually saying it) VWs also have non-realistic mechanism of establishing routes/links between entities: entire kinds of interaction are disconnected from the consideration of world "physical" presence. Instant messaging and other forms of real-time, synchronous or asynchronous communication (be it IM, monetary transfer or VoIP streams) between entities are social-based instead of geography-based. (this fully justifies the decision to split Agent and Region domains, so that forms of interaction based on presence don't get mixed up with interaction forms based on social ties: each kind follows a different routing model. So far I see no other domains than these two, but then maybe Delivery could be one if MMOX also defines the exchange or push-through of content, identity and money between grids - that would make HyperGrid the first example of a Delivery Domain service) Of course, there needs to be some way to distinguish between the entities that constitute a VW in order to address them at the MMOX level and authenticate/accept their transmissions. For those entities that represent people (us invaders from meat space) this implies a general identity authentication system. That one was a given already, but it's worth mentioning here because it fits as a particular case of a wider mechanism that also identifies all the other (non-meat space) entities of the VW: this consideration should remain in our minds when we discuss OpenID, OAuth and other schemes - servers/objects/Scripts may want to chat/transfer inventory/animate objects cross-grid, too ! To sum up so far, if I'm not mistaken: - MMOX is a decentralized P2P routing protocol with automatic discovery and at least two different routing schemes for Agent/social and Region/geo domains of interaction, and possibly a third for Delivery/Exchange, - the routes established by the MMOX protocol will tunnel the VW's services encapsulated in MMOX datagrams through the grids' limits (whatever the centralization/distribution of those services inside each grid, which only changes the endpoints) - MMOX datagrams address specific entities of specific grids in a uniform way (with auth) so significant work is needed to come up with a good common denominator of an addressing scheme, that works well with the discovery service(s) retained - PDUs of Region/geo services are transported to all the relevant entities that are mutually present (hence the seperate routing scheme), while PDUs of Agent/social services are routed according to specific social info (groups, etc.) and PDUs of other domains (Delivery ?) are treated in yet another way. Question: do each domain (Agent, Region, Delivery) requires its own distinct discovery service ? I tend to think yes, but I'm unsure and confused. From morgaine.dinova@googlemail.com Thu Feb 26 09:32:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224923A68BD for ; Thu, 26 Feb 2009 09:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8P5hCHem-LyZ for ; Thu, 26 Feb 2009 09:32:44 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 5A45D3A6830 for ; Thu, 26 Feb 2009 09:32:43 -0800 (PST) Received: by fxm24 with SMTP id 24so638277fxm.37 for ; Thu, 26 Feb 2009 09:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BOOYO5a3GefGyRJj6sdxNTTkUFcNk7oCVrW3x7K/zLw=; b=G9/ZY3qPlibVpV2RPHh6PgCYbfOmUg9aBVghTD2rOLEPNgU+lLQfo5Me5zo0e3V14g W3+sgfehbNjBfF2HqDS/GovrZmcmQKbW71hlQK1/eG0GhkVto0UHoMP3p1wz8Tll5hhe 1K3YgVCF4QbcspYIsFizZZjxNk4812xp4KAac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hs+eXfDkyjFB/EWeXfmDVhMoImAy3vekw+P3+Yv+qnauuJYUYWbWhgAPrJyUPurbIP u+17DC8WuhQ4wAgo/ka1fmGtPMp783OT84+rvl6oWApdLlBkmm+7ASMpLXCV6JDZCHDI 6OzJSCkm2YTIgnX5JuPRblYkaGEn3FDv+vXcw= MIME-Version: 1.0 Received: by 10.181.210.8 with SMTP id m8mr528399bkq.69.1235669584074; Thu, 26 Feb 2009 09:33:04 -0800 (PST) In-Reply-To: <53cd6c2e0902260734t7336df2dp2a97bd93b5db792b@mail.gmail.com> References: <53cd6c2e0902260734t7336df2dp2a97bd93b5db792b@mail.gmail.com> Date: Thu, 26 Feb 2009 17:33:04 +0000 Message-ID: From: Morgaine To: Jesrad Content-Type: multipart/alternative; boundary=001636c5a2b19e58a60463d5be21 Cc: "mmox@ietf.org" Subject: Re: [mmox] A tentative top-down analysis X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 17:32:46 -0000 --001636c5a2b19e58a60463d5be21 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A very good top-down analysis, Jesrad. On Thu, Feb 26, 2009 at 3:34 PM, Jesrad wrote: > > In the context of interoperability of grids, we must treat each grid > itself as a node of a relatively small P2P network. There is no > "supergrid" nor any central "interoperability to go" service for > existing grids to plug into as registered clients, nor will the be in > any foreseeable future. Thus, the interoperability protocol has to be > a decentralized protocol. > > (this means it will need decentralized discovery, for one, since we > probably do not want to limit the protocol to hand-coded, static > cross-grid links) > The above deserves underlining in red, because pre-interop VW providers (especially large ones) typically think of themselves as operating centralized services of the web kind, but this mental model actually breaks down in the expanded metaverse. As the interoperating metaverse grows, providers can no longer think of customers' clients as performing short-lived accesses to their servers and then going away to access someone else's servers. Instead, N providers may be supplying continual object state updates for the items owned by an agent who is not registered with any of them. What's more, those updates will often need to continue even when (i) the avatar is currently offline, and when (ii) the items are dispersed across many other worlds, and when (iii) the avatar is currently in a world with which they do not have direct interop. The last point is particularly revealing: provider A may have an explicit agreement to interoperate with provider B, and provider B may have an agreement with provider C, without A and C having any direct agreement whatsoever. Yet, an avatar registered on B and wearing an unencumbered object from A will naturally be visiting world C, and the worn object must continue to fulfil its normal purpose or interop has failed. The pattern of activity seen by VW providers is clearly going to be very different to that seen in centralized web scenarios where consumers and communication endpoints have a 1:1 mapping. Instead it will be much closer to the random mesh of connectivity typical of P2P networks. > (this fully justifies the decision to split Agent and Region domains, > so that forms of interaction based on presence don't get mixed up with > interaction forms based on social ties: each kind follows a different > routing model. So far I see no other domains than these two, but then > maybe Delivery could be one if MMOX also defines the exchange or > push-through of content, identity and money between grids - that would > make HyperGrid the first example of a Delivery Domain service) > I see several other domains that should operate independently to free metaverse inhabitants from the tyranny of tied choices. Starting with the first two for completeness, my minimum list would be: 1. Agent Domain (entry point for some agent-oriented services) 2. Region Domain (stateless world simulation services) 3. Communication Domain (groups, IM, PM, various transports) 4. Object Domain (storage of interoperable objects and avatars) 5. Execution Domain (delivery of power to OD objects) 6. Geographical Domain (terrain and topology services) 7. Fiscal Domain (everything to do with VW currencies) Decoupling the various services in this way means that all parties involved can pick and choose the best providers in each category, instead of having to live with the misery of (say) failing IM or non-scalable regions that another party could do better. This is as much a benefit for VW providers as for VW inhabitants, because subcontracting a service to a specialist can very often be more cost effective than reinventing the wheel in-house and poorly. Morgaine. > > On Thu, Feb 26, 2009 at 3:34 PM, Jesrad wrote: > As an answer to Catherine's call for more top-down views of the MMOX > project to complement the bottom-up approach, here is a collection of > thoughts on MMOX as viewed from afar: > > What exactly, deep down to the bottom line, is the function that a VW > executes ? > > => it establishes data links (or at the very least signals links to be > established) between virtual entities residing on a vast number of > networked machines so they can interact. > > At the core, a VW is a ROUTER. A number of these special routers also > include their own "network endpoints" supporting entities specific to > the VW (like a combat stats database, an inventory server, etc.), for > specific forms of interaction, but as far as interoperability goes > these are particular cases of a more general layout (for example SL > residents may set up their own combat stats databases for other SL > residents to use, the case which will interest us later is whether > access to a VW combat stats server should be uniform across all > interoperable grids). > > In the context of interoperability of grids, we must treat each grid > itself as a node of a relatively small P2P network. There is no > "supergrid" nor any central "interoperability to go" service for > existing grids to plug into as registered clients, nor will the be in > any foreseeable future. Thus, the interoperability protocol has to be > a decentralized protocol. > > (this means it will need decentralized discovery, for one, since we > probably do not want to limit the protocol to hand-coded, static > cross-grid links) > > The routing mechanism of this protocol is dictated by the inner > routing that the VWs realize on their own inner network. In many cases > a Virtual World mimicks functions of the real world in the way it > opens and destroys links between entities, for example entities each > have a location in the virtual world, and if two entities have > locations that are close enough then a link of "mutual presence" is > opened between them (whether this "presence routing" is done centrally > or is distributed has no impact at the interoperability level, since > centralized VWs will use a central gateway while P2P VWs will > implement it in the nodes - only the MMOX endpoints change here). This > is the minimal interaction which is universal to all "worldy" > entities. There are other forms of interaction that not all entities > are capable of, like collision, chat, left-mouse click, edition > request or Fire Magic attack, and the set differs between VWs. > > (because it extends this mechanism, the interoperability protocol has > to transport the universal, common interaction "routing" services like > this "mutual presence": it must provide the necessary signalling for > opening and closing down relevant links between the entities across > grids - and though that sounds a very pedantic way of stating the > obvious it still goes better with actually saying it) > > VWs also have non-realistic mechanism of establishing routes/links > between entities: entire kinds of interaction are disconnected from > the consideration of world "physical" presence. Instant messaging and > other forms of real-time, synchronous or asynchronous communication > (be it IM, monetary transfer or VoIP streams) between entities are > social-based instead of geography-based. > > (this fully justifies the decision to split Agent and Region domains, > so that forms of interaction based on presence don't get mixed up with > interaction forms based on social ties: each kind follows a different > routing model. So far I see no other domains than these two, but then > maybe Delivery could be one if MMOX also defines the exchange or > push-through of content, identity and money between grids - that would > make HyperGrid the first example of a Delivery Domain service) > > Of course, there needs to be some way to distinguish between the > entities that constitute a VW in order to address them at the MMOX > level and authenticate/accept their transmissions. For those entities > that represent people (us invaders from meat space) this implies a > general identity authentication system. That one was a given already, > but it's worth mentioning here because it fits as a particular case of > a wider mechanism that also identifies all the other (non-meat space) > entities of the VW: this consideration should remain in our minds when > we discuss OpenID, OAuth and other schemes - servers/objects/Scripts > may want to chat/transfer inventory/animate objects cross-grid, too ! > > To sum up so far, if I'm not mistaken: > - MMOX is a decentralized P2P routing protocol with automatic > discovery and at least two different routing schemes for Agent/social > and Region/geo domains of interaction, and possibly a third for > Delivery/Exchange, > - the routes established by the MMOX protocol will tunnel the VW's > services encapsulated in MMOX datagrams through the grids' limits > (whatever the centralization/distribution of those services inside > each grid, which only changes the endpoints) > - MMOX datagrams address specific entities of specific grids in a > uniform way (with auth) so significant work is needed to come up with > a good common denominator of an addressing scheme, that works well > with the discovery service(s) retained > - PDUs of Region/geo services are transported to all the relevant > entities that are mutually present (hence the seperate routing > scheme), while PDUs of Agent/social services are routed according to > specific social info (groups, etc.) and PDUs of other domains > (Delivery ?) are treated in yet another way. > > Question: do each domain (Agent, Region, Delivery) requires its own > distinct discovery service ? I tend to think yes, but I'm unsure and > confused. > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --001636c5a2b19e58a60463d5be21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A very good top-down analysis, Jesrad.

On= Thu, Feb 26, 2009 at 3:34 PM, Jesrad <jesrad@gmail.com> wrote:

In the context of interoperability of grids, we must treat each grid
itself as a node of a relatively small P2P network. There is no
"supergrid" nor any central "interoperability to go" se= rvice for
existing grids to plug into as registered clients, nor will the be in
any foreseeable future. Thus, the interoperability protocol has to be
a decentralized protocol.

(this means it will need decentralized discovery, for one, since we
probably do not want to limit the protocol to hand-coded, static
cross-grid links)


The above deserves underlining in red, because pr= e-interop VW providers (especially large ones) typically think of themselve= s as operating centralized services of the web kind, but this mental model = actually breaks down in the expanded metaverse.

As the interoperating metaverse grows, providers can no longer think of= customers' clients as performing short-lived accesses to their servers= and then going away to access someone else's servers.=A0 Instead, N pr= oviders may be supplying continual object state updates for the items owned= by an agent who is not registered with any of them.

What's more, those updates will often need to continue even when (i= ) the avatar is currently offline, and when (ii) the items are dispersed ac= ross many other worlds, and when (iii) the avatar is currently in a world w= ith which they do not have direct interop.

The last point is particularly revealing:=A0 provider A may have an exp= licit agreement to interoperate with provider B, and provider B may have an= agreement with provider C, without A and C having any direct agreement wha= tsoever.=A0 Yet, an avatar registered on B and wearing an unencumbered obje= ct from A will naturally be visiting world C, and the worn object must cont= inue to fulfil its normal purpose or interop has failed.

The pattern of activity seen by VW providers is clearly going to be ver= y different to that seen in centralized web scenarios where consumers and c= ommunication endpoints have a 1:1 mapping.=A0 Instead it will be much close= r to the random mesh of connectivity typical of P2P networks.
=A0


(this fully justifies the decision to split Agent and Region domains,
so that forms of interaction based on presence don't get mixed up with<= br> interaction forms based on social ties: each kind follows a different
routing model. So far I see no other domains than these two, but then
maybe Delivery could be one if MMOX also defines the exchange or
push-through of content, identity and money between grids - that would
make HyperGrid the first example of a Delivery Domain service)



I see several other domains that should opera= te independently to free metaverse inhabitants from the tyranny of tied choices.=A0 Starting with the first two for completeness, my minimum list would be:

  1. Agent Domain (entry point for some agent-oriented services)
  2. Region Domain (stateless world simulation services)
  3. Comm= unication Domain (groups, IM, PM, various transports)
  4. Object Domain= (storage of interoperable objects and avatars)
  5. Execution Domain (delivery of power to OD objects)
  6. Geogr= aphical Domain (terrain and topology services)
  7. Fiscal Domain (every= thing to do with VW currencies)

Decoupling the various services in this way means that all parties involved= can pick and choose the best providers in each category, instead of having= to live with the misery of (say) failing IM or non-scalable regions that a= nother party could do better.=A0 This is as much a benefit for VW providers= as for VW inhabitants, because subcontracting a service to a specialist ca= n very often be more cost effective than reinventing the wheel in-house and= poorly.
=A0

Morgaine.

=A0
=A0


On Thu, Feb 26, 2009 at 3:34 PM, Jesrad <jesrad@gmail.com> wrote:
As an answer to Catherine's call for more top-down views of the MMOX project to complement the bottom-up approach, here is a collection of
thoughts on MMOX as viewed from afar:

What exactly, deep down to the bottom line, is the function that a VW execu= tes ?

=3D> it establishes data links (or at the very least signals links to be=
established) between virtual entities residing on a vast number of
networked machines so they can interact.

At the core, a VW is a ROUTER. A number of these special routers also
include their own "network endpoints" supporting entities specifi= c to
the VW (like a combat stats database, an inventory server, etc.), for
specific forms of interaction, but as far as interoperability goes
these are particular cases of a more general layout (for example SL
residents may set up their own combat stats databases for other SL
residents to use, the case which will interest us later is whether
access to a VW combat stats server should be uniform across all
interoperable grids).

In the context of interoperability of grids, we must treat each grid
itself as a node of a relatively small P2P network. There is no
"supergrid" nor any central "interoperability to go" se= rvice for
existing grids to plug into as registered clients, nor will the be in
any foreseeable future. Thus, the interoperability protocol has to be
a decentralized protocol.

(this means it will need decentralized discovery, for one, since we
probably do not want to limit the protocol to hand-coded, static
cross-grid links)

The routing mechanism of this protocol is dictated by the inner
routing that the VWs realize on their own inner network. In many cases
a Virtual World mimicks functions of the real world in the way it
opens and destroys links between entities, for example entities each
have a location in the virtual world, and if two entities have
locations that are close enough then a link of "mutual presence" = is
opened between them (whether this "presence routing" is done cent= rally
or is distributed has no impact at the interoperability level, since
centralized VWs will use a central gateway while P2P VWs will
implement it in the nodes - only the MMOX endpoints change here). This
is the minimal interaction which is universal to all "worldy"
entities. There are other forms of interaction that not all entities
are capable of, like collision, chat, left-mouse click, edition
request or Fire Magic attack, and the set differs between VWs.

(because it extends this mechanism, the interoperability protocol has
to transport the universal, common interaction "routing" services= like
this "mutual presence": it must provide the necessary signalling = for
opening and closing down relevant links between the entities across
grids - and though that sounds a very pedantic way of stating the
obvious it still goes better with actually saying it)

VWs also have non-realistic mechanism of establishing routes/links
between entities: entire kinds of interaction are disconnected from
the consideration of world "physical" presence. Instant messaging= and
other forms of real-time, synchronous or asynchronous communication
(be it IM, monetary transfer or VoIP streams) between entities are
social-based instead of geography-based.

(this fully justifies the decision to split Agent and Region domains,
so that forms of interaction based on presence don't get mixed up with<= br> interaction forms based on social ties: each kind follows a different
routing model. So far I see no other domains than these two, but then
maybe Delivery could be one if MMOX also defines the exchange or
push-through of content, identity and money between grids - that would
make HyperGrid the first example of a Delivery Domain service)

Of course, there needs to be some way to distinguish between the
entities that constitute a VW in order to address them at the MMOX
level and authenticate/accept their transmissions. For those entities
that represent people (us invaders from meat space) this implies a
general identity authentication system. That one was a given already,
but it's worth mentioning here because it fits as a particular case of<= br> a wider mechanism that also identifies all the other (non-meat space)
entities of the VW: this consideration should remain in our minds when
we discuss OpenID, OAuth and other schemes - servers/objects/Scripts
may want to chat/transfer inventory/animate objects cross-grid, too !

To sum up so far, if I'm not mistaken:
- MMOX is a decentralized P2P routing protocol with automatic
discovery and at least two different routing schemes for Agent/social
and Region/geo domains of interaction, and possibly a third for
Delivery/Exchange,
- the routes established by the MMOX protocol will tunnel the VW's
services encapsulated in MMOX datagrams through the grids' limits
(whatever the centralization/distribution of those services inside
each grid, which only changes the endpoints)
- MMOX datagrams address specific entities of specific grids in a
uniform way (with auth) so significant work is needed to come up with
a good common denominator of an addressing scheme, that works well
with the discovery service(s) retained
- PDUs of Region/geo services are transported to all the relevant
entities that are mutually present (hence the seperate routing
scheme), while PDUs of Agent/social services are routed according to
specific social info (groups, etc.) and PDUs of other domains
(Delivery ?) are treated in yet another way.

Question: do each domain (Agent, Region, Delivery) requires its own
distinct discovery service ? I tend to think yes, but I'm unsure and confused.
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--001636c5a2b19e58a60463d5be21-- From infinity@lindenlab.com Thu Feb 26 10:37:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CC053A67D7 for ; Thu, 26 Feb 2009 10:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH2Z1tTprWa2 for ; Thu, 26 Feb 2009 10:37:02 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 601423A67B0 for ; Thu, 26 Feb 2009 10:37:02 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id E96141414004 for ; Thu, 26 Feb 2009 10:37:23 -0800 (PST) Message-Id: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> From: Meadhbh Hamrick (Infinity) To: mmox@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 10:37:23 -0800 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] what does it mean to be interoperable? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 18:37:03 -0000 so it seems clear we all have different ideas of what it means to be interoperable. i thought i might try to define a couple of the definitions i think i've seen people use: 1. interoperability means all virtual worlds, wherever they are, may be accessed via a single unified client. 2. interoperability means all virtual worlds, wherever they are, use precisely the same protocol(s) and all virtual worlds represent data in formats understandable by all other virtual worlds, with a universal client. 3. interoperability means some virtual worlds may be accessed via a single unified client. 4. interoperability means some virtual worlds use precisely the same protocol(s) and all virtual worlds represent data in formats understandable by all other virtual worlds, without a universal client. 5. interoperability means some virtual worlds use some of the same protocols, without a universal client 6. interoperability means the "model" is the same, but with different protocols that may be bridged with protocol gateways. it seems to me that many of us are using different descriptions for the word "interoperable" and it's causing mild discord and at least a couple instances of us talking past each other. personally.. i'm kind of interested in option 5. it has the benefit of producing a protocol that is identifiable by routers, network management software, etc. it also provides a "slowly moving target" for open source developers (as opposed to the "fast moving target" of linden's existing protocol(s)). by making it public, VW operators can choose whether or not they wish to implement it. it also doesn't require VW operators to implement it (as if we could anyway) and it allows VW operators to avoid having to test interoperability with every other virtual world. but it's not without drawbacks... this model can lead to a "MOSS-like" environment. (for those of you who don't remember MOSS or MIME Object(?) Security Services... it was a response to the drawbacks of PEM (privacy enhanced mail) which had a relative paucity of encryption options. but IMHO, MOSS introduced so many options that it was VERY easy for two implementations to adhere to the spec, but not actually be interoperable.) so... i recommend that if we (as a group) wanted to pursue option-5.. we also explicitly define what goes in an "interoperability profile." that way you could get the benefit of having a relatively stable protocol that could be targeted by open source developers which could be used by VW operators to help make client / server apps. VW operators could publish their "interoperability profile" to tell people who wanted to build tools, extra services, or interoperable worlds what options would be available and how they would work. -cheers -m From jwatte@gmail.com Thu Feb 26 10:44:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5B328C1DB for ; Thu, 26 Feb 2009 10:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObmwtMomQBz8 for ; Thu, 26 Feb 2009 10:44:50 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 6F05728C190 for ; Thu, 26 Feb 2009 10:44:50 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so859236ywh.49 for ; Thu, 26 Feb 2009 10:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rIz/iFxCWSsKFDLhU33DxvgEpbH/sQJnV3UgPzwbmZE=; b=FU4/7Htuag6nLrsIGrXnq/cqb+AopWJ7fx/1vE04IFyq2CuMX3e6XFgBNTyjK6bNlc /Y+vdetsUHmdU2oiYuDPrK3khsOmBwTuZ9d1I2hXouDVfbjqSXU2m7NOCErKEO+7KXeE sGU/wXNwlWAMbOeeWXgCC+foxf2vg4BMcqsAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vMgUXKaIZlIZryTZt8ri6qxgGYnX5DInHf4C531nCyPWF/DhOQT/U0t38bU7bS2JaF Q/mNCnSxpR4p8Wyo+Bdxp6CRDwJUyFd6jPMYDpnG9VZ6aIVn49fLSNyamg00F8P1j2Wf R24OAVhkoFFICrc49k5hkiFQgxq6Yi5WkF6Rg= Received: by 10.100.42.4 with SMTP id p4mr621065anp.40.1235673911507; Thu, 26 Feb 2009 10:45:11 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c37sm4120076ana.42.2009.02.26.10.45.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 10:45:10 -0800 (PST) Message-ID: <49A6E335.1080009@gmail.com> Date: Thu, 26 Feb 2009 10:45:09 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Christian Scholz References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> In-Reply-To: <49A65D92.3060606@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 18:44:51 -0000 Christian Scholz wrote: > I think requiring having some data in the client will not scale. Why > not give it an URL as well and just tell the client to cache it long > enough? Should be easy with a REST approach. For SL it might be trees > for a game it might in fact be everything if no I agree. In interop terms, it will say "the visual presentation of this object uses mesh http://www.whatever.com/some-url-here" and you can cache that just like you cache other web data. > A specialized game client could even be so clever as to download it in > advance and have some proprietary way of checking whether it's still > uptodate or not. HTTP already has a versioning mechanism. However, for a game with 50,000 assets, doing 50,000 "HEAD" or "if-modified-since" requests might not scale so well ;-) Sincerely, jw From jwatte@gmail.com Thu Feb 26 10:47:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CE203A6BEA for ; Thu, 26 Feb 2009 10:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGButshDn7XY for ; Thu, 26 Feb 2009 10:47:11 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id 6965C3A6B13 for ; Thu, 26 Feb 2009 10:47:11 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so633637ana.4 for ; Thu, 26 Feb 2009 10:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Jgnm2rlDnhq5obUFmJXbDKa91UtnypuBxN3UcUBUrZs=; b=fnWqfTQso33lceMjhX7u3IGHN8w1mkjRaR8MckL/2cz00PitvMXiZ6zZ9DN2iP6EJU O8iJ7VFpDT9JsjKU4kwiBPhNr3f+Tr8sksmyyPQH3hzFsdK42aW4pJ4pCQ4UdWC7k84G A5wlAf+AJU+3VQdoozKFSaFCC4MGCI0O89Yk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ASrT5ZhNqgqlQBxfWA/NbdxeuZY9I4iC3T6DgLZAWSl4DRHD+ys4Aggb6TAjoJ+hmr MsngK5QZ6K/oYWHkHJsmpRVOXH7QaxZx/Z31NTq6HI01cE/w1Zbimio+cQqxKzyZIH9E 7PSM8bQdNtmfaXTCxwiZ+B+Y3Cr9Lh/dP5c0c= Received: by 10.100.14.10 with SMTP id 10mr1844265ann.119.1235674052284; Thu, 26 Feb 2009 10:47:32 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d21sm345021and.6.2009.02.26.10.47.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 10:47:31 -0800 (PST) Message-ID: <49A6E3C1.3000702@gmail.com> Date: Thu, 26 Feb 2009 10:47:29 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> <49A666ED.6040508@cox.net> In-Reply-To: <49A666ED.6040508@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 18:47:12 -0000 Lawson English wrote: > Seems to me that some default content might be distributable as > libraries/plugins. So, if I'm running FreeBSD on a MIPS processor, where do I get the appropriate plug-in? What if I'm using Java on a Blackberry? Or C++ on Win64? I think that transporting any kind of behavior isn't really feasible, unless you want to specify a common language, runtime and execution environment. There are two of those that could be used: Java JRE or Microsoft .NET. I think you'll have trouble getting everyone in the world to agree on any one of those. Sincerely, jw From jwatte@gmail.com Thu Feb 26 10:52:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378B73A67A7 for ; Thu, 26 Feb 2009 10:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oWMhD8ZePzC for ; Thu, 26 Feb 2009 10:52:50 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 6FCFD3A677C for ; Thu, 26 Feb 2009 10:52:50 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so863064ywh.49 for ; Thu, 26 Feb 2009 10:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=RZRT7wRuU4E1vcTUf2UGgVfg2cNVBaKmzZLLSmWPTkc=; b=Man4H+MGZdgSSr3Koh8eqayPtPP7Ay6iLgBHNWPnFkLntZB+cbqef5Gqaz8H3qVTfl YdpXrFM18ziNLaiJPt6XcT7VyW17CWHuxRt7LbOqZYBoBOLiZQXrBSqmdfyxdLilVYhB GY4ath3y5FmTgRYmr1X3t7Ep+zWOJ4NdWbgRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZM7RO10vNwRtJKLMIykiR7EQXzc/d0ZLCm6OO6GOsRvm4M6SvAPUsI/JVFZQLdamib ZvI+RerP2arhtkuL4KZF9iW+vxR8PuLLQz+Szoe9/P6SJvi3fTkRbf2ekCCCj/CntPEW oEskYlqSCDQZ6KViQlffxy72MYyPQPdxorUv8= Received: by 10.100.93.17 with SMTP id q17mr1872902anb.93.1235674391852; Thu, 26 Feb 2009 10:53:11 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c37sm4134446ana.42.2009.02.26.10.53.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 10:53:11 -0800 (PST) Message-ID: <49A6E515.6010107@gmail.com> Date: Thu, 26 Feb 2009 10:53:09 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Automatic generation of the schema X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 18:52:51 -0000 Catherine Pfeffer wrote: > Of course, all these efforts make sense only if there is a real need > for XML stuff. I believe that for non-real-time, transaction-type requests, XML is the right choice. If I need to "get a description of the upcoming event X" then that's a very good mapping to existing web 2.0 standards, which want XML or JSON for the response. Whether the request is an XML encoded entity (a la XML-RPC and SOAP), or a url-encoded query string, may still be under debate. Personally, I'd prefer XML-RPC. Similarly, for durable storage, I would prefer XML to binary, because it is much more likely to survive for longer, be more robust, and you can use standard tools when processing it off-line. Sincerely, jw From jwatte@gmail.com Thu Feb 26 10:58:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 082A83A6818 for ; Thu, 26 Feb 2009 10:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYo+GpEaOSMl for ; Thu, 26 Feb 2009 10:58:36 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 016C63A68D2 for ; Thu, 26 Feb 2009 10:58:35 -0800 (PST) Received: by gxk22 with SMTP id 22so1645324gxk.13 for ; Thu, 26 Feb 2009 10:58:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=nRaAC27gylq0Y+An1623N1kEdDtoI3zFICjkVZayCu4=; b=NGe8thB4+62nu12cBMgDMsaTPbWkz5Rz9/objm4N3EPeH5jo/mVlZU1p047rb8Qlws EIPK+/Ed9Te5PGT94jgWjdMJe9jVDX4GwNBIEWQPtmY3h5zmU8VBLciK3p7S3Un2RzXd MVypEom/gIxqlqDzfC4ORe3AfchdRtZqwwa6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=O9MuVV9DU3N3d0WFf8PwxROeWwh8jcCd8VEM7eb35+aMcFq1oYv5J4/F8a5HhjT+5Z YRbR2bu9YVsIEDK0cDMkMlJ2jrYBBguvuAMW3lgCgcskjkkiKcFHEO1rNUX03mtndhPt MiB9ZI3kXdDIfmsiRVfCW1lMgovKb0a/YTRyY= Received: by 10.100.205.15 with SMTP id c15mr1827699ang.132.1235674737401; Thu, 26 Feb 2009 10:58:57 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c1sm3631188ana.20.2009.02.26.10.58.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 10:58:56 -0800 (PST) Message-ID: <49A6E66E.8090506@gmail.com> Date: Thu, 26 Feb 2009 10:58:54 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Field names as numbers? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 18:58:37 -0000 Catherine Pfeffer wrote: > I am not sure I like this idea of replacing keys like > "Nose_Orientation" with numbers like 443: > - a protocol dump would be harder to debug (you'd need a table to > know what each field means). Agreed. Another example is MPEG video, or JPEG images: you can't see the color of the individual pixels inside Wireshark. > - it would be less simple in a program because you would need to look > up in a table to solve the indirections I don't think that's intellectually honest. Usually, doing a look-up from integer to "something" is a lot faster than doing a look-up from string to "something." If you are saying that you'd need to do a look-up from integer to string, and then from string to something, then I suggest that perhaps your internal structure could be improved :-) > - it is error prone (it is easier to mix field 443 with field 442 > than to mix field "Nose_Orientation" with field "Associated_Sound") Who would do this mixing? The code? The code works, or it doesn't. To code, the values 17 and 443 are as different as 442 and 443. > - if you have been unable to transmit the packet containing the > table, you can't do anything anymore If I can't send data, I can't send data, that's right! If I can't send data, why am I trying to do a live, real-time streaming application anyway? Note that I am not proposing using schema-driven binary interchange for transactional or durable applications. I believe we need at least two separate systems: a very efficient transmission format for streaming live, high-bandwidth data (such as a stream of entity property updates during simulation), and a very robust exchange format for transactional, batch or offline processing (such as "properly structured" XML). Sincerely, jw From lenglish5@cox.net Thu Feb 26 11:04:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E7A63A6818 for ; Thu, 26 Feb 2009 11:04:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-m46tCso-JV for ; Thu, 26 Feb 2009 11:04:20 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 731003A6359 for ; Thu, 26 Feb 2009 11:04:20 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090226190443.QGEE10385.fed1rmmtao107.cox.net@fed1rmimpo03.cox.net>; Thu, 26 Feb 2009 14:04:43 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id Lj4h1b00H4N6T0Q04j4hrL; Thu, 26 Feb 2009 14:04:42 -0500 X-Authority-Analysis: v=1.0 c=1 a=AfYVl4n-8fwA:10 a=5qzUSljf7S4A:10 a=Wajolswj7cQA:10 a=YyGIARRjOSoVBpJZYTUA:9 a=zQ9cNLb8Ux2mvLNWzcHy5gOizJoA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <49A6E7C9.8040703@cox.net> Date: Thu, 26 Feb 2009 12:04:41 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> <49A666ED.6040508@cox.net> <49A6E3C1.3000702@gmail.com> In-Reply-To: <49A6E3C1.3000702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 19:04:21 -0000 Jon Watte wrote: > Lawson English wrote: >> Seems to me that some default content might be distributable as >> libraries/plugins. > > So, if I'm running FreeBSD on a MIPS processor, where do I get the > appropriate plug-in? > What if I'm using Java on a Blackberry? > Or C++ on Win64? > > I think that transporting any kind of behavior isn't really feasible, > unless you want to specify a common language, runtime and execution > environment. There are two of those that could be used: Java JRE or > Microsoft .NET. I think you'll have trouble getting everyone in the > world to agree on any one of those. > > Sincerely, > > jw > > How many languages will we be using? There's only a handful of graphics engines to worry about, regardless of language. Seems to me that SL uses OpenGL while others use DirecctX. I'm not advocating OpenGL and DirectX compatibility, so we're left with describing things in terms of one graphics engine. Are you suggesting that Linden Lab standard trees are too complex to bother with implementing algorithms for in your favorite language + OpenGL? Lawson From jwatte@gmail.com Thu Feb 26 11:07:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C5D3A6359 for ; Thu, 26 Feb 2009 11:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1epSW52ldff for ; Thu, 26 Feb 2009 11:07:06 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id B31563A6902 for ; Thu, 26 Feb 2009 11:07:06 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so871244yxm.49 for ; Thu, 26 Feb 2009 11:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=4uAI6/NFMrTSooLiV/ohSadHUsEK/bAYgS92MKbY+Vo=; b=Fs5JzGyP5sMG73bRBul8CAmdKikh7D6HwTvXqnLMo+r7iufrOjBjY3cNZwQZOoitLy LZfAJPhRNjKpQDsOSjSRitqqI7oC+Xr7bgPrYWOFsjUkBqyKivNK6Y0J/0z0/1UABA/L xElbVR/jk57v6dH8/QpNJswCJ3CnYFCJnfjzA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TJ+U43zVae1F62GJqGG1d1b2smH2UDjQHPRTpHob6Ff/WOKJOg9k9m/hLD4BA8fQTJ +g/oUIy+gQe1K6Eabuj7rt8jcpLDm/t7vKDCHMnhTRM9hHU3YKZ6N3QElZpB1TA6DBFK wSPvofvMhkNlClYF87Nk9uUR6zo4hrFxNRCOM= Received: by 10.100.214.15 with SMTP id m15mr1921270ang.44.1235675248027; Thu, 26 Feb 2009 11:07:28 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b32sm1628444ana.35.2009.02.26.11.07.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 11:07:27 -0800 (PST) Message-ID: <49A6E86D.9040906@gmail.com> Date: Thu, 26 Feb 2009 11:07:25 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <53cd6c2e0902260734t7336df2dp2a97bd93b5db792b@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] A tentative top-down analysis X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 19:07:07 -0000 Morgaine wrote: > As the interoperating metaverse grows, providers can no longer think > of customers' clients as performing short-lived accesses to their > servers and then going away to access someone else's servers. > Instead, N providers may be supplying continual object state updates > for the items owned by an agent who is not registered with any of them. That's right! Incidentally, this matches almost exactly the "connected server peers" model that I've been proposing. However, the objects themselves are owned by one of those N providers (or else why is the provider supplying authoritative state for it?) > > What's more, those updates will often need to continue even when (i) > the avatar is currently offline, and when (ii) the items are dispersed > across many other worlds, and when (iii) the avatar is currently in a > world with which they do not have direct interop. > Saying that the object update persists in the simulation when you don't have interop with the viewer is like saying that you can browse the YouTube video library when you have disconnected your Internet connection. I don't think that would be realistic. > The last point is particularly revealing: provider A may have an > explicit agreement to interoperate with provider B, and provider B may > have an agreement with provider C, without A and C having any direct > agreement whatsoever. Yet, an avatar registered on B and wearing an > unencumbered object from A will naturally be visiting world C, and the > worn object must continue to fulfil its normal purpose or interop has > failed. > Agreed! > > I see several other domains that should operate independently to free > metaverse inhabitants from the tyranny of tied choices. Starting with > the first two for completeness, my minimum list would be: > > 1. Agent Domain (entry point for some agent-oriented services) > 2. Region Domain (stateless world simulation services) > 3. Communication Domain (groups, IM, PM, various transports) > 4. Object Domain (storage of interoperable objects and avatars) > 5. Execution Domain (delivery of power to OD objects) > 6. Geographical Domain (terrain and topology services) > 7. Fiscal Domain (everything to do with VW currencies) > I think this grouping is as good as any I've seen on this list so far. Thank you for putting it in reasonably clear terms, which I feel I have not managed to do myself! Sincerely, jw From jwatte@gmail.com Thu Feb 26 11:52:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F1A28C2C0 for ; Thu, 26 Feb 2009 11:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eihcY1C7MNfF for ; Thu, 26 Feb 2009 11:52:49 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 4C7E928C123 for ; Thu, 26 Feb 2009 11:52:47 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so892997yxm.49 for ; Thu, 26 Feb 2009 11:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yMNCcYqNigfuFCH/i3uYoNggNeuuj/7HWjUe6ORYdwI=; b=xXaFYC8sVHuCuY7aTBa0V/rNTJnRVMlLbh6h+n7nnn3jAlnxFNCYDvzjnjiNvh8+c8 NZp0VgSk0JUYkky3V/CMEBrP6bzp32guiJtbg6bbbAZxo5JEumCqzuYKnRITf+Ijp4mk O++y8uRrgsDYF42zIxjnv6sSwa7DyDCj4hhCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=al2/uM/XDxKR5pieSB6wQcNr3HkF1YPw2Zydp9GGTN8gZfvVy/RJqwksIE7tBltFU2 /vU4g9bUj6b591n4wnjavDsGXUaxpZVX6YidAFPoL+4dERBwVDH1eaKtjTlijCnmAzt9 luo48k3VnR8VFvipiCmC1pmOiGdwY/SftqrKU= Received: by 10.100.153.6 with SMTP id a6mr1932269ane.76.1235677988839; Thu, 26 Feb 2009 11:53:08 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d29sm2178394and.54.2009.02.26.11.53.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 11:53:08 -0800 (PST) Message-ID: <49A6F322.5020305@gmail.com> Date: Thu, 26 Feb 2009 11:53:06 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> In-Reply-To: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] what does it mean to be interoperable? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 19:52:50 -0000 Meadhbh Hamrick (Infinity) wrote: > 4. interoperability means some virtual worlds use precisely the same > protocol(s) and all virtual worlds represent data in formats > understandable by all other virtual worlds, without a universal client. > I would add option 4.5: 4.5: interoperability means all virtual worlds understand a precise set of protocols and all virtual worlds understand data represented in a common set of formats, without a universal client. That may be what you meant, but the way you wrote it, it sounds like it dictates implementation details, which I think we should stay away from. > > so... i recommend that if we (as a group) wanted to pursue option-5.. > we also explicitly define what goes in an "interoperability profile." > that way you could get the benefit of having a relatively stable > protocol that could be targeted by open source developers which could > be used by VW operators to help make client / server apps. I think we need to pursue 4.5, for exactly the reason you're suggesting: we want to avoid what you call "MOSS-like" behavior: two systems that claim to be interoperable, can't actually interoperate. Sincerely, jw From jwatte@gmail.com Thu Feb 26 11:56:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C448F28C2C4 for ; Thu, 26 Feb 2009 11:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAQf9iKbQudC for ; Thu, 26 Feb 2009 11:56:35 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by core3.amsl.com (Postfix) with ESMTP id 6A9CC28C2C9 for ; Thu, 26 Feb 2009 11:56:35 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so658178ana.4 for ; Thu, 26 Feb 2009 11:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Pr4mYYgLA9bhUneY6socG2P9rUo/I4lcN5S6uRjn/rY=; b=VZfXROV1/8mRVqn/IN0RlMZLkOfZLLJNdr+0tLcH+t5JjtdGQgkiJCt1jT0IyFnGPw EDAJrxMOI7SX/8JzBq7wbVJuf6XD5WofcUmY7BVD69xXLYRmZD0Q+cdglHIWJhe5nOmN k85ps5XXogQFWWlv8ZMROvzPEUaG+S9GLCwoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Dnoi2l+C3SjZ24eisKV9dBbxZ/yn21qtsoMnKgqDyngRlmVRKfHMwn84trByGYg0/Y 5wYcOQv1w9t42YCqyDjDr1zWLsyfVH6xTe+iuf4uY2+YuRT6sJv1q9NHX8SJCva5hNe5 1p7AM5gQv6NmMtWgFHV1aGcrBYB6EK3BPEzlc= Received: by 10.100.96.10 with SMTP id t10mr1977330anb.32.1235678216602; Thu, 26 Feb 2009 11:56:56 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c40sm3372362anc.48.2009.02.26.11.56.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 11:56:55 -0800 (PST) Message-ID: <49A6F405.7000207@gmail.com> Date: Thu, 26 Feb 2009 11:56:53 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> <49A666ED.6040508@cox.net> <49A6E3C1.3000702@gmail.com> <49A6E7C9.8040703@cox.net> In-Reply-To: <49A6E7C9.8040703@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 19:56:36 -0000 Lawson English wrote: > How many languages will we be using? There's only a handful of > graphics engines to worry about, regardless of language. Seems to me > that SL uses OpenGL while others use DirecctX. I'm not advocating > OpenGL and DirectX compatibility, so we're left with describing things > in terms of one graphics engine. Are you suggesting that Linden Lab > standard trees are too complex to bother with implementing algorithms > for in your favorite language + OpenGL? I am suggesting that the problem is a lot wider than just trees. There.com describes terrain as a guided fractal system. Are you saying everyone should implement that system to be able to display There.com terrain? OLIVE describes objects in the form of composition of baser types using XML schema. Are you saying everyone should implement that system to be able to display OLIVE objects? Or are trees somehow special, when all other kinds of geometry or objects (buildings, water, ships, humans, weapons, telephones, cars, ...) are somehow less special? Who decides what kinds of geometry are special, and what the "canonical form" of those kinds of geometry are? I believe that trying to go that line of reasoning will end up in very much effort, and very much bickering, for very little actual benefit. It's much easier to say "entity at point 3,4,5 uses mesh http://www.second-life.com/models/tree-oak2.dae." Sincerely, jw From lenglish5@cox.net Thu Feb 26 12:05:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B7728C293 for ; Thu, 26 Feb 2009 12:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=1.057, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkuxR6XW2NGL for ; Thu, 26 Feb 2009 12:05:36 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 7147C28C286 for ; Thu, 26 Feb 2009 12:05:36 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090226200558.TJQW10385.fed1rmmtao107.cox.net@fed1rmimpo01.cox.net>; Thu, 26 Feb 2009 15:05:58 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id Lk5x1b00C4N6T0Q03k5xyd; Thu, 26 Feb 2009 15:05:58 -0500 X-Authority-Analysis: v=1.0 c=1 a=AfYVl4n-8fwA:10 a=5qzUSljf7S4A:10 a=Wajolswj7cQA:10 a=qOn9Db7XAAAA:8 a=SAzZ_xlkAAAA:8 a=iIUeSSis6Uf0wygXh6QA:9 a=JHnm1a8jubnMpx0Fnr4A:7 a=1-rvwRog6NNgm6jG5ThF9HC7rlkA:4 a=zUBsD6tbDSsA:10 a=Sf9ypl_c-8UA:10 X-CM-Score: 0.00 Message-ID: <49A6F625.5050005@cox.net> Date: Thu, 26 Feb 2009 13:05:57 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> <49A666ED.6040508@cox.net> <49A6E3C1.3000702@gmail.com> <49A6E7C9.8040703@cox.net> <49A6F405.7000207@gmail.com> In-Reply-To: <49A6F405.7000207@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 20:05:37 -0000 Jon Watte wrote: > Lawson English wrote: >> How many languages will we be using? There's only a handful of >> graphics engines to worry about, regardless of language. Seems to me >> that SL uses OpenGL while others use DirecctX. I'm not advocating >> OpenGL and DirectX compatibility, so we're left with describing >> things in terms of one graphics engine. Are you suggesting that >> Linden Lab standard trees are too complex to bother with implementing >> algorithms for in your favorite language + OpenGL? > > I am suggesting that the problem is a lot wider than just trees. > There.com describes terrain as a guided fractal system. Are you saying > everyone should implement that system to be able to display There.com > terrain? > OLIVE describes objects in the form of composition of baser types > using XML schema. Are you saying everyone should implement that system > to be able to display OLIVE objects? > > Or are trees somehow special, when all other kinds of geometry or > objects (buildings, water, ships, humans, weapons, telephones, cars, > ...) are somehow less special? Who decides what kinds of geometry are > special, and what the "canonical form" of those kinds of geometry are? > I believe that trying to go that line of reasoning will end up in very > much effort, and very much bickering, for very little actual benefit. > It's much easier to say "entity at point 3,4,5 uses mesh > http://www.second-life.com/models/tree-oak2.dae." > Ah, OK, though, it seems to me that SOME things should be built into the client in some ways, while others can be downloadable as separate meshes... perhaps some way of compromising... a profile might say "uses SL trees, available as this plugin and connection or from server xyz as generic meshes and OLIVE objects, available via this plugin and connection or from server uvw as generic meshes" etc. L From tme@multicasttech.com Thu Feb 26 13:00:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEECA3A69A8 for ; Thu, 26 Feb 2009 13:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.559 X-Spam-Level: X-Spam-Status: No, score=-103.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wK1FqejtCv4u for ; Thu, 26 Feb 2009 13:00:10 -0800 (PST) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by core3.amsl.com (Postfix) with ESMTP id CAEAB3A69A2 for ; Thu, 26 Feb 2009 13:00:09 -0800 (PST) Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 14792991; Thu, 26 Feb 2009 16:00:25 -0500 Message-Id: <63B7B0AE-3C37-42A2-A23A-753CF6413535@multicasttech.com> From: Marshall Eubanks To: Jon Watte In-Reply-To: <49A6F405.7000207@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 16:00:29 -0500 References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> <49A666ED.6040508@cox.net> <49A6E3C1.3000702@gmail.com> <49A6E7C9.8040703@cox.net> <49A6F405.7000207@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: lenglish5@cox.net, "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 21:00:11 -0000 This may be a simplistic (i.e., dumb) question, but I work in Telepresence, and can certainly see mixed Virtual World / Real World telepresence sessions (and, even, Telepresence between incompatible virtual worlds as a means of connecting the unconnectable). Are there any special issues with this, or is this just a subset of the multiple virtual worlds connection problem. Regards Marshall On Feb 26, 2009, at 2:56 PM, Jon Watte wrote: > Lawson English wrote: >> How many languages will we be using? There's only a handful of >> graphics engines to worry about, regardless of language. Seems to >> me that SL uses OpenGL while others use DirecctX. I'm not >> advocating OpenGL and DirectX compatibility, so we're left with >> describing things in terms of one graphics engine. Are you >> suggesting that Linden Lab standard trees are too complex to bother >> with implementing algorithms for in your favorite language + OpenGL? > > I am suggesting that the problem is a lot wider than just trees. > There.com describes terrain as a guided fractal system. Are you > saying everyone should implement that system to be able to display > There.com terrain? > OLIVE describes objects in the form of composition of baser types > using XML schema. Are you saying everyone should implement that > system to be able to display OLIVE objects? > > Or are trees somehow special, when all other kinds of geometry or > objects (buildings, water, ships, humans, weapons, telephones, > cars, ...) are somehow less special? Who decides what kinds of > geometry are special, and what the "canonical form" of those kinds > of geometry are? > I believe that trying to go that line of reasoning will end up in > very much effort, and very much bickering, for very little actual > benefit. It's much easier to say "entity at point 3,4,5 uses mesh http://www.second-life.com/models/tree-oak2.dae > ." > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From gareth@litesim.com Thu Feb 26 13:11:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECDF43A6892 for ; Thu, 26 Feb 2009 13:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_53=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGxyLveCD96r for ; Thu, 26 Feb 2009 13:11:43 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id C14A73A680E for ; Thu, 26 Feb 2009 13:11:43 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so651412rvb.49 for ; Thu, 26 Feb 2009 13:12:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.180.16 with SMTP id h16mr824249rvp.68.1235682725423; Thu, 26 Feb 2009 13:12:05 -0800 (PST) In-Reply-To: <49A6E335.1080009@gmail.com> References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> <49A6E335.1080009@gmail.com> Date: Thu, 26 Feb 2009 21:12:05 +0000 Message-ID: <61dbdd7d0902261312r162810c2l2df063b47ebbea25@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 21:11:45 -0000 The solution here is for the clients that want to use standard content to use content packs. Look at something like the modern iD software FPS games for example. Each game has the engine (under the GPL) and lots of .pak files which contain the levels, models, sounds, scripts etc. If each .pak has a URL from which the latest version can be fetched, then if-modified-since requests make more sense for auto-updates on those particular clients that need it. I could imagine something being sent to the client such as "Get the #7 tree model from http://secondlife.com/content/trees.pak" and the client caching trees.pak. On Thu, Feb 26, 2009 at 6:45 PM, Jon Watte wrote: > Christian Scholz wrote: >> >> I think requiring having some data in the client will not scale. Why not >> give it an URL as well and just tell the client to cache it long enough? >> Should be easy with a REST approach. For SL it might be trees for a game it >> might in fact be everything if no > > I agree. In interop terms, it will say "the visual presentation of this > object uses mesh http://www.whatever.com/some-url-here" and you can cache > that just like you cache other web data. > >> A specialized game client could even be so clever as to download it in >> advance and have some proprietary way of checking whether it's still >> uptodate or not. > > HTTP already has a versioning mechanism. However, for a game with 50,000 > assets, doing 50,000 "HEAD" or "if-modified-since" requests might not scale > so well ;-) > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From gareth@litesim.com Thu Feb 26 13:35:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4093A6807; Thu, 26 Feb 2009 13:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q13gVmRTQE8G; Thu, 26 Feb 2009 13:35:10 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 429A03A6C0A; Thu, 26 Feb 2009 13:35:10 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so659714rvb.49 for ; Thu, 26 Feb 2009 13:35:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.157.5 with SMTP id f5mr831452rve.122.1235684131912; Thu, 26 Feb 2009 13:35:31 -0800 (PST) In-Reply-To: References: Date: Thu, 26 Feb 2009 21:35:31 +0000 Message-ID: <61dbdd7d0902261335q608ee9ferc083fdffa87071ed@mail.gmail.com> From: Gareth Nelson To: David W Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 21:35:11 -0000 Well, I promised i'd give my thoughts on the list, so here they are: > I am attaching the input as a .txt and a (sigh) Microsoft =A0word documen= t. I > am also posting it in line as plan text. (tho ugly, I'll work on that for > future versions) A word document about a proposal for discussions of open standards. That's priceless > Specifications do not advance in the IETF in the absence of > demonstrated interoperability based on running code. This is a good thing(tm), and we should also discuss what languages any code should be produced in. My vote is for python and C. > I take MMOX as Massively MultiParty Online eXperiences (Since Meadbh didn= 't > define > X, we all get a shot at it) Lets take this one bit at a time. Massively, = as > in experiences > intended to be shared by tens, hundreds, thousands, and over time, a > significant fraction > of the interne community. Online, focusing our attention on the concurren= t > shared portion > of the experiences and eXperience as a shorthand for (Games, Applications > and shared > experiences.) One thing I would immediately point out is that though I can see how games are relevant (after all, MMORPGs for example are just huge virtual worlds with game rules thrown in), I fail to see how networked applications of a generic type are relevant. For example, if I use multiuser GNU screen, are we going to discuss interop so I can teleport from my screen session to SL? This is obviously quite nonsensical, and is an extreme case, but I must ask "where is the line drawn?" Practically everything people do online is "multiuser", and lots of things are "massively multiuser" - look at any big site such as wikipedia for example. > The group's name and remit is intentionally broad, focused on a general s= et > of Games and > Applications, not any single game, application or experience. =A0The grou= p's > roots, and > interests are largely, but not exclusively shaped by Virtual Worlds, > including MMO > games, Virtual worlds, Collaboration and Simulation Environments and shar= ed > online > streaming environments. Examples of these platforms include, but are not > limited to > World Of Warcaft, ProtonSphere, Eve Online, Forterra's =A0OLIVE platform,= Club > Penguin, =A0Linden Lab's Second Life, =A0IMVU, There.com, Croquet, > OpenSimulator.org, > Weblins. Tiny nitpicking point - did you mean webkins, the virtual world for kids with the cute little pets and serial codes from toys? As for "shared online streaming environments", I presume this means any kind of interaction where people are streaming "something" such as video, audio or 3D stuff? If so, would this not also include stuff such as IRC? See where i'm going, we don't want "one working group to rule them all". > The common thread across all of these environments is a concurrent shared > experience, > often, but not exclusively rendered in a three dimensional space. =A0Here= 's > one attempt to > scope what these environment share: > > 1. =A0 =A0 =A0 =A0One or more virtual spaces > 2. =A0 =A0 =A0 =A0A set of users > 3. =A0 =A0 =A0 =A0A representation of the users projected into the space > 4. =A0 =A0 =A0 =A0A shared experience of the events in the space projecte= d back to > all the users > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0currently in the space. (Text, Voice, and = the results of > actions) This mailing list could be considered a virtual space, as could a forum or an IRC channel. > Many of these environments will also include one or more of: > > 5. =A0 =A0 =A0 =A0Objects which can be dynamically created and modified t= o form part > of the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0space's setting > 6. =A0 =A0 =A0 =A0Persistent state in the virtual space(s) > 7. =A0 =A0 =A0 =A0Mechanisms to associate external streams of media with = portions of > the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0immersive space > 8. =A0 =A0 =A0 =A0Mechanisms to run scripted behaviors in the space > 9. =A0 =A0 =A0 =A0Simulated physics and behavior of objects and projected= users in > the spaace > 10. =A0 =A0 =A0 =A0Mechanisms for users to =A0move from one virtual space= to another > (by hand off > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0between regions implicitly, or by explicit= user request > (teleport) > 11. =A0 =A0 =A0 =A0Libraries of material the users can add to the space > 12. =A0 =A0 =A0 =A0Mechanisms for users which are not in a common virtual= space to > interact with > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0each other in some form (be aware of each = other's locations > and online status, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0message each other, etc) Shameless self-plug, have I talked to you about GMMP? Each channel in GMMP has a set of "channel objects" which contain persistent state. It's meant as an abstraction of any virtual world or any other internet protocol in such a way that you could visualise any arbitary protocol as a virtual world. It's a project i've been working on-and-off on for the past 1.5 years and I have some draft specs about 30% done. > Note I've very carefully avoided using most of the common words for the > shared > experience. We often speak of Simulators, Avatars, Regions, Assets and so > forth, for the > moment, I'm going to keep those terms off the table to think about the > problem in its > more general form. Sensible idea :) Though longterm we do need to agree on terminology. I suggest "location", "space" or "scene" instead of "region", with "avatar" and "assets" still being very neutral. > Note that I'm also very consciously taking a minimal base with optional > features > approach to describing the space. This allows us to focus on the core > overlapping > features, and then a set of services which add to this core. Think about = how > these goals > and solutions could be applied to collaborative spaces such as Wikis, Mic= ro > blogging > streams and collaborative desktop and application environments. I'm repeating myself, but I think it's a bad idea to go into any multiuser collaborative environments with this group. We can't reasonably hold a remit that large. Ironically in limiting your specifications of the problem space, you're making it HUGE. > Interoperability is not about defining the one true system which satisfie= s > these goals. > Interoperability is about making multiple existing implementation > interoperate by the use > of standards we define. Agreed - I think everyone on this list will agree with that one I'll continue commenting in another post From morgaine.dinova@googlemail.com Thu Feb 26 13:58:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20CB328C210 for ; Thu, 26 Feb 2009 13:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho5wBaid8+Qd for ; Thu, 26 Feb 2009 13:58:10 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 73C583A6C15 for ; Thu, 26 Feb 2009 13:57:52 -0800 (PST) Received: by bwz26 with SMTP id 26so739343bwz.37 for ; Thu, 26 Feb 2009 13:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=L++LQ56NMk0nzWJzSCMC/owGsn3lAimBUvdUyDyLxzc=; b=UgosJxxZgrnlfsQp+zoyJGFNQXVxrRIevSXloAnF5KfFF7giGjvukTcKEJxR1T8Mdz BiK7BYByS3PzBLfbgOHVKjstNtCj1KesV1uyzSfB8FeQgoEnxjPtwEBYJaH3Z//mXgst eNdTowo/jilbV4vXf/4ee9pP3soqLJhmaSXeM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Bo9QuvyzH9n3aoV2Wo0/ma3JINBiJqV/XY6eAoBKraejOnpT2MmyGOb6vOSzvJM0X+ oJDYW5F3GbhxmB9HKZnbHQwNdQGtHV6ukqoozqV8cFp3o6e1c9lYrvOVjaOFROAH7p6V IWCepuBiLkfsCZTTNIKStQSEKnIYzlqjkEcwY= MIME-Version: 1.0 Received: by 10.181.216.12 with SMTP id t12mr604143bkq.122.1235685493212; Thu, 26 Feb 2009 13:58:13 -0800 (PST) In-Reply-To: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> References: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> Date: Thu, 26 Feb 2009 21:58:13 +0000 Message-ID: From: Morgaine To: Infinity Meadhbh Hamrick Content-Type: multipart/alternative; boundary=001636c59860e0883f0463d972b2 Cc: mmox@ietf.org Subject: Re: [mmox] what does it mean to be interoperable? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 21:58:18 -0000 --001636c59860e0883f0463d972b2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick < infinity@lindenlab.com> wrote: > > 5. interoperability means some virtual worlds use some of the same > protocols, without a universal client > ... > personally.. i'm kind of interested in option 5. Options 5 is a perfectly good option for a workgroup formed around the common goal of implementing some specific protocols in a similarly-focused group. As you pointed out in your paragraph that I quoted concerning "taxonomy of topics", the protocols which you intend to use are those based on the OGP model. This sounds like an excellent thing to tackle, in an OGP workgroup. I would look forward to that work, as it would undoubtedly help advance interop between SL-like worlds. Furthermore, the workgroup name and charter would honestly reflect the intent, allowing participants interested in such a goal to work productively with helpful consensus. In contrast, as pointed out by our co-chair under "Charter, Scope, Activities"and in even more detail under "Strawman scope/goals/approach", the goals and intent of MMOX are very different to the above, and the name of the group reinforces that. The narrow scope of Option 5 and the specific focus on LL technologies doesn't come anwhere near the catchment area that MMOX participants have been discussing. I think that both of the above are worthy goals to be handled under the aegis of the IETF. But work on OGP is hampered by the very clear fact that MMOX discussions and requirements are far broader and can't be forced into an a priori straightjacket. By the same token, work on MMOX is likewise being hampered by a narrow focus on near-term Linden goals. This is why I am trying to find an approach that will allow both groups of interests to be successful and productive. Currently there is little commonality owing to the gulf between the actual narrow intent stated in your "taxonomy of topics" and the very much broader goals of MMOX. Morgaine. On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick < infinity@lindenlab.com> wrote: > so it seems clear we all have different ideas of what it means to be > interoperable. > > i thought i might try to define a couple of the definitions i think i've > seen people use: > > 1. interoperability means all virtual worlds, wherever they are, may be > accessed via a single unified client. > > 2. interoperability means all virtual worlds, wherever they are, use > precisely the same protocol(s) and all virtual worlds represent data in > formats understandable by all other virtual worlds, with a universal client. > > 3. interoperability means some virtual worlds may be accessed via a single > unified client. > > 4. interoperability means some virtual worlds use precisely the same > protocol(s) and all virtual worlds represent data in formats understandable > by all other virtual worlds, without a universal client. > > 5. interoperability means some virtual worlds use some of the same > protocols, without a universal client > > 6. interoperability means the "model" is the same, but with different > protocols that may be bridged with protocol gateways. > > it seems to me that many of us are using different descriptions for the > word "interoperable" and it's causing mild discord and at least a couple > instances of us talking past each other. > > personally.. i'm kind of interested in option 5. it has the benefit of > producing a protocol that is identifiable by routers, network management > software, etc. it also provides a "slowly moving target" for open source > developers (as opposed to the "fast moving target" of linden's existing > protocol(s)). by making it public, VW operators can choose whether or not > they wish to implement it. it also doesn't require VW operators to implement > it (as if we could anyway) and it allows VW operators to avoid having to > test interoperability with every other virtual world. > > but it's not without drawbacks... this model can lead to a "MOSS-like" > environment. (for those of you who don't remember MOSS or MIME Object(?) > Security Services... it was a response to the drawbacks of PEM (privacy > enhanced mail) which had a relative paucity of encryption options. but IMHO, > MOSS introduced so many options that it was VERY easy for two > implementations to adhere to the spec, but not actually be interoperable.) > > so... i recommend that if we (as a group) wanted to pursue option-5.. we > also explicitly define what goes in an "interoperability profile." that way > you could get the benefit of having a relatively stable protocol that could > be targeted by open source developers which could be used by VW operators to > help make client / server apps. > > VW operators could publish their "interoperability profile" to tell people > who wanted to build tools, extra services, or interoperable worlds what > options would be available and how they would work. > > -cheers > -m > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --001636c59860e0883f0463d972b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhb= h Hamrick <i= nfinity@lindenlab.com> wrote:

5. interoperability means some virtual worlds use some of the same protocol= s, without a universal client
...
personally.. i'm kind of interested in option 5.

<= br>Options 5 is a perfectly good option for a workgroup formed around the c= ommon goal of implementing some specific protocols in a similarly-focused g= roup.=A0 As you pointed out in your paragraph that I quoted concerning &qu= ot;taxonomy of topics", the protocols which you intend to use are = those based on the OGP model.=A0 This sounds like an excellent thing to tac= kle, in an OGP workgroup.=A0 I would look forward to that work, as it would= undoubtedly help advance interop between SL-like worlds.=A0 Furthermore, t= he workgroup name and charter would honestly reflect the intent, allowing p= articipants interested in such a goal to work productively with helpful con= sensus.

In contrast, as pointed out by our co-chair under "Charter, Scope= , Activities" and in even more detail under "Strawman scope/= goals/approach", the goals and intent of MMOX are very different t= o the above, and the name of the group= reinforces that.=A0 The narrow scope of Option 5 and the specific focus on= LL technologies doesn't come anwhere near the catchment area that MMOX= participants have been discussing.

I think that both of the above are worthy goals to b= e handled under the aegis of the IETF.=A0 But work on OGP is hampered by th= e very clear fact that MMOX discussions and requirements are far broader an= d can't be forced into an a priori straightjacket.=A0 By the same token= , work on MMOX is likewise being hampered by a narrow focus on near-term Li= nden goals.

This is why I am trying to find an approach that will allow both groups= of interests to be successful and productive.=A0 Currently there is little= commonality owing to the gulf between the actual narrow intent stated in y= our "taxonomy of topics" and the very much broader goals of MMOX.=


Morgaine.







On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick <infinity@lindenlab.com&= gt; wrote:
so it seems clear= we all have different ideas of what it means to be interoperable.

i thought i might try to define a couple of the definitions i think i'v= e seen people use:

1. interoperability means all virtual worlds, wherever they are, may be acc= essed via a single unified client.

2. interoperability means all virtual worlds, wherever they are, use precis= ely the same protocol(s) and all virtual worlds represent data in formats u= nderstandable by all other virtual worlds, with a universal client.

3. interoperability means some virtual worlds may be accessed via a single = unified client.

4. interoperability means some virtual worlds use precisely the same protoc= ol(s) and all virtual worlds represent data in formats understandable by al= l other virtual worlds, without a universal client.

5. interoperability means some virtual worlds use some of the same protocol= s, without a universal client

6. interoperability means the "model" is the same, but with diffe= rent protocols that may be bridged with protocol gateways.

it seems to me that many of us are using different descriptions for the wor= d "interoperable" and it's causing mild discord and at least = a couple instances of us talking past each other.

personally.. i'm kind of interested in option 5. it has the benefit of = producing a protocol that is identifiable by routers, network management so= ftware, etc. it also provides a "slowly moving target" for open s= ource developers (as opposed to the "fast moving target" of linde= n's existing protocol(s)). by making it public, VW operators can choose= whether or not they wish to implement it. it also doesn't require VW o= perators to implement it (as if we could anyway) and it allows VW operators= to avoid having to test interoperability with every other virtual world.
but it's not without drawbacks... this model can lead to a "MOSS-l= ike" environment. (for those of you who don't remember MOSS or MIM= E Object(?) Security Services... it was a response to the drawbacks of PEM = (privacy enhanced mail) which had a relative paucity of encryption options.= but IMHO, MOSS introduced so many options that it was VERY easy for two im= plementations to adhere to the spec, but not actually be interoperable.)
so... i recommend that if we (as a group) wanted to pursue option-5.. we al= so explicitly define what goes in an "interoperability profile." = that way you could get the benefit of having a relatively stable protocol t= hat could be targeted by open source developers which could be used by VW o= perators to help make client / server apps.

VW operators could publish their "interoperability profile" to te= ll people who wanted to build tools, extra services, or interoperable world= s what options would be available and how they would work.

-cheers
-m
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--001636c59860e0883f0463d972b2-- From infinity@lindenlab.com Thu Feb 26 14:26:00 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A61B528C32E for ; Thu, 26 Feb 2009 14:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6TqELgVUxN9 for ; Thu, 26 Feb 2009 14:25:59 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 15B6B28C215 for ; Thu, 26 Feb 2009 14:25:58 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id B2AE21414002; Thu, 26 Feb 2009 14:26:20 -0800 (PST) Message-Id: <7D208FA9-3C91-422F-B24F-F1B0B85908B9@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Morgaine In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-2--318057564 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 14:26:20 -0800 References: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] what does it mean to be interoperable? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 22:26:00 -0000 --Apple-Mail-2--318057564 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit why would MMOX be limited to pursuing only OGP if we want to define OGP in a standards body? POP3 and IMAP are both defined in RFCs, after all. ( though i believe they did come out of different working groups ) maybe we _should_ re-charter with a more OGP-centric view and pursue interoperability option 5, but this would effectively move any OLIVE standardization effort into a different WG, and with two different VW "regimes," interop options 1 and 2 would be impossible. JW spoke in support of option 4.5 (which yes, has the same intent as what i was going for with option 4.) i don't know if linden could ever support an option-4, because of our desire to have interoperability drive "user innovation." in other words, we'll always be interested in a situation where developers could extend the protocol to support value-added services. we're not terribly frightened of option-5 because our view of the world has VW operators deploying client software unique to their solution to handle these value-added services. in short, we expect OGP to never be a complete specification of a virtual world protocol, but rather a protocol framework that together with an interoperability profile sufficiently specifies client and server behavior to achieve some measure of interoperability. On Feb 26, 2009, at 1:58 PM, Morgaine wrote: > On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick > wrote: > > 5. interoperability means some virtual worlds use some of the same > protocols, without a universal client > ... > personally.. i'm kind of interested in option 5. > > > Options 5 is a perfectly good option for a workgroup formed around > the common goal of implementing some specific protocols in a > similarly-focused group. As you pointed out in your paragraph that > I quoted concerning "taxonomy of topics", the protocols which you > intend to use are those based on the OGP model. This sounds like an > excellent thing to tackle, in an OGP workgroup. I would look > forward to that work, as it would undoubtedly help advance interop > between SL-like worlds. Furthermore, the workgroup name and charter > would honestly reflect the intent, allowing participants interested > in such a goal to work productively with helpful consensus. > > In contrast, as pointed out by our co-chair under "Charter, Scope, > Activities" and in even more detail under "Strawman scope/goals/ > approach", the goals and intent of MMOX are very different to the > above, and the name of the group reinforces that. The narrow scope > of Option 5 and the specific focus on LL technologies doesn't come > anwhere near the catchment area that MMOX participants have been > discussing. > > I think that both of the above are worthy goals to be handled under > the aegis of the IETF. But work on OGP is hampered by the very > clear fact that MMOX discussions and requirements are far broader > and can't be forced into an a priori straightjacket. By the same > token, work on MMOX is likewise being hampered by a narrow focus on > near-term Linden goals. > > This is why I am trying to find an approach that will allow both > groups of interests to be successful and productive. Currently > there is little commonality owing to the gulf between the actual > narrow intent stated in your "taxonomy of topics" and the very much > broader goals of MMOX. > > > Morgaine. > > > > > > > > On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick > wrote: > so it seems clear we all have different ideas of what it means to be > interoperable. > > i thought i might try to define a couple of the definitions i think > i've seen people use: > > 1. interoperability means all virtual worlds, wherever they are, may > be accessed via a single unified client. > > 2. interoperability means all virtual worlds, wherever they are, use > precisely the same protocol(s) and all virtual worlds represent data > in formats understandable by all other virtual worlds, with a > universal client. > > 3. interoperability means some virtual worlds may be accessed via a > single unified client. > > 4. interoperability means some virtual worlds use precisely the same > protocol(s) and all virtual worlds represent data in formats > understandable by all other virtual worlds, without a universal > client. > > 5. interoperability means some virtual worlds use some of the same > protocols, without a universal client > > 6. interoperability means the "model" is the same, but with > different protocols that may be bridged with protocol gateways. > > it seems to me that many of us are using different descriptions for > the word "interoperable" and it's causing mild discord and at least > a couple instances of us talking past each other. > > personally.. i'm kind of interested in option 5. it has the benefit > of producing a protocol that is identifiable by routers, network > management software, etc. it also provides a "slowly moving target" > for open source developers (as opposed to the "fast moving target" > of linden's existing protocol(s)). by making it public, VW operators > can choose whether or not they wish to implement it. it also doesn't > require VW operators to implement it (as if we could anyway) and it > allows VW operators to avoid having to test interoperability with > every other virtual world. > > but it's not without drawbacks... this model can lead to a "MOSS- > like" environment. (for those of you who don't remember MOSS or MIME > Object(?) Security Services... it was a response to the drawbacks of > PEM (privacy enhanced mail) which had a relative paucity of > encryption options. but IMHO, MOSS introduced so many options that > it was VERY easy for two implementations to adhere to the spec, but > not actually be interoperable.) > > so... i recommend that if we (as a group) wanted to pursue > option-5.. we also explicitly define what goes in an > "interoperability profile." that way you could get the benefit of > having a relatively stable protocol that could be targeted by open > source developers which could be used by VW operators to help make > client / server apps. > > VW operators could publish their "interoperability profile" to tell > people who wanted to build tools, extra services, or interoperable > worlds what options would be available and how they would work. > > -cheers > -m > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --Apple-Mail-2--318057564 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable why would MMOX be limited to = pursuing only OGP if we want to define OGP in a standards = body?

POP3 and IMAP are both defined in RFCs, after = all. ( though i believe they did come out of different working groups = )

maybe we _should_ re-charter with a more = OGP-centric view and pursue interoperability option 5, but this would = effectively move any OLIVE standardization effort into a different WG, = and with two different VW "regimes," interop options 1 and 2 would be = impossible. JW spoke in support of option 4.5 (which yes, has the same = intent as what i was going for with option = 4.)

i don't know if linden could ever support = an option-4, because of our desire to have interoperability drive "user = innovation." in other words, we'll always be interested in a situation = where developers could extend the protocol to support value-added = services. we're not terribly frightened of option-5 because our view of = the world has VW operators deploying client software unique to their = solution to handle these value-added = services.

in short, we expect OGP to never be a = complete specification of a virtual world protocol, but rather a = protocol framework that together with an interoperability profile = sufficiently specifies client and server behavior to achieve some = measure of interoperability.

On Feb = 26, 2009, at 1:58 PM, Morgaine wrote:

On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh = Hamrick <infinity@lindenlab.com> = wrote:

5. interoperability means some virtual worlds use some of = the same protocols, without a universal client
...
personally.. = i'm kind of interested in option 5.


Options 5 = is a perfectly good option for a workgroup formed around the common goal = of implementing some specific protocols in a similarly-focused = group.  As you pointed out in your paragraph t= hat I quoted concerning "taxonomy of topics", the protocols which = you intend to use are those based on the OGP model.  This sounds = like an excellent thing to tackle, in an OGP workgroup.  I would = look forward to that work, as it would undoubtedly help advance interop = between SL-like worlds.  Furthermore, the workgroup name and = charter would honestly reflect the intent, allowing participants = interested in such a goal to work productively with helpful = consensus.

In contrast, as pointed out by our co-chair under "= Charter, Scope, Activities" and in even more detail under "= Strawman scope/goals/approach", the goals and intent of MMOX are = very different to the above, and = the name of the group reinforces that.  The narrow scope of Option = 5 and the specific focus on LL technologies doesn't come anwhere near = the catchment area that MMOX participants have been discussing.
=

I think that both of the above are worthy goals = to be handled under the aegis of the IETF.  But work on OGP is = hampered by the very clear fact that MMOX discussions and requirements = are far broader and can't be forced into an a priori = straightjacket.  By the same token, work on MMOX is likewise being = hampered by a narrow focus on near-term Linden goals.

This is = why I am trying to find an approach that will allow both groups of = interests to be successful and productive.  Currently there is = little commonality owing to the gulf between the actual narrow intent = stated in your "taxonomy of topics" and the very much broader goals of = MMOX.


Morgaine.







On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh = Hamrick <infinity@lindenlab.com> = wrote:
so it seems clear we all have different ideas of what it means to = be interoperable.

i thought i might try to define a couple of = the definitions i think i've seen people use:

1. = interoperability means all virtual worlds, wherever they are, may be = accessed via a single unified client.

2. interoperability means = all virtual worlds, wherever they are, use precisely the same = protocol(s) and all virtual worlds represent data in formats = understandable by all other virtual worlds, with a universal client.
=
3. interoperability means some virtual worlds may be accessed via a = single unified client.

4. interoperability means some virtual = worlds use precisely the same protocol(s) and all virtual worlds = represent data in formats understandable by all other virtual worlds, = without a universal client.

5. interoperability means some = virtual worlds use some of the same protocols, without a universal = client

6. interoperability means the "model" is the same, but = with different protocols that may be bridged with protocol gateways.
=
it seems to me that many of us are using different descriptions for = the word "interoperable" and it's causing mild discord and at least a = couple instances of us talking past each other.

personally.. = i'm kind of interested in option 5. it has the benefit of producing a = protocol that is identifiable by routers, network management software, = etc. it also provides a "slowly moving target" for open source = developers (as opposed to the "fast moving target" of linden's existing = protocol(s)). by making it public, VW operators can choose whether or = not they wish to implement it. it also doesn't require VW operators to = implement it (as if we could anyway) and it allows VW operators to avoid = having to test interoperability with every other virtual world.

= but it's not without drawbacks... this model can lead to a "MOSS-like" = environment. (for those of you who don't remember MOSS or MIME Object(?) = Security Services... it was a response to the drawbacks of PEM (privacy = enhanced mail) which had a relative paucity of encryption options. but = IMHO, MOSS introduced so many options that it was VERY easy for two = implementations to adhere to the spec, but not actually be = interoperable.)

so... i recommend that if we (as a group) = wanted to pursue option-5.. we also explicitly define what goes in an = "interoperability profile." that way you could get the benefit of having = a relatively stable protocol that could be targeted by open source = developers which could be used by VW operators to help make client / = server apps.

VW operators could publish their "interoperability = profile" to tell people who wanted to build tools, extra services, or = interoperable worlds what options would be available and how they would = work.

-cheers
-m
= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
=


= --Apple-Mail-2--318057564-- From jwatte@gmail.com Thu Feb 26 14:31:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9CD28C32B; Thu, 26 Feb 2009 14:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X55f9slUHSh; Thu, 26 Feb 2009 14:31:23 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 3FAAC28C10E; Thu, 26 Feb 2009 14:31:23 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so971020ywh.49 for ; Thu, 26 Feb 2009 14:31:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=FdkgFLL8EEm2mNjX/WsQJa17MsUsXPmVNra3K8B1tdM=; b=gyZA9lHQcPbTRvG2gHTPnFrHVybKny09BiXgvlAKjSDsb1cyCtL9CGf8/0Nz5wMevX akUnL9JGxdyQcBU1c/gksbt68Vnyok9YJQkuMQXnzSggW1WjXWaBQdlOJUkQ7D5aLV5n dPLowZeo24e3PwA3R+l+Vcf2sOdJ5kqg2R1r0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=aRJZ5zS7ep5GEsm1QN7qDYjIplgiouZah/TdF4jJlk6VuC1g7RYhu4ZbaoLI8fIHsU 71uInsh9/pdd7QQxYR+FGsIo8A5m7+414euhoddm87DracObQj4F9DhDQtZSSMwT+jV/ aziHcLrM1S25cbdal/ZUcjfb7Jl6KyqtrERq0= Received: by 10.100.254.15 with SMTP id b15mr1994440ani.155.1235687504572; Thu, 26 Feb 2009 14:31:44 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c28sm1143162anc.25.2009.02.26.14.31.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 14:31:43 -0800 (PST) Message-ID: <49A7184D.3050602@gmail.com> Date: Thu, 26 Feb 2009 14:31:41 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Gareth Nelson References: <61dbdd7d0902261335q608ee9ferc083fdffa87071ed@mail.gmail.com> In-Reply-To: <61dbdd7d0902261335q608ee9ferc083fdffa87071ed@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 22:31:24 -0000 Gareth Nelson wrote: > any code should be produced in. My vote is for python and C. > Let me vote for Lua and C++, and then the OpenSim people can vote for C# and Java and we have all the bases covered :-) > games are relevant (after all, MMORPGs for example are just huge > virtual worlds with game rules thrown in), I fail to see how networked > I think that's a common mis-conception. Most (almost all) MMOGs do not have much in the way of persistency, other than character possessions and stats. They also have a very static world, that generally does not allow users to move things around or place new things into the world. Finally, they do not support any form of UGC, which I think is more or less a requirement for a "real" virtual world. Lacking all three means that the technical job of implementing and running the MMORPG is much easier, but it also puts them on a lower rung of the expressiveness. A VW could express a MMORPG (with significant overhead compared to the MMORPG itself), but a MMORPG couldn't express a VW. > Practically everything people do online is "multiuser", and lots of > things are "massively multiuser" - look at any big site such as > wikipedia for example. > > "What is virtual worlds" has been a general question for a long time, but I believe the "rough consensus" answer is that it's at least: Interactive Persistent Identity Based Collaborative Supports UGC (controversial) Based on a 3D Simulation But, if we believe that we all need to agree on exactly what a virtual world is before we can make progress, experience shows we won't be able to make progress at all. Sincerely, jw From dyerbrookme@juno.com Thu Feb 26 14:35:42 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC633A6A50 for ; Thu, 26 Feb 2009 14:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qh3pq3z6I6uE for ; Thu, 26 Feb 2009 14:35:41 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 878673A6810 for ; Thu, 26 Feb 2009 14:35:41 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail02.vgs.untd.com [10.181.12.142]) by smtpout01.vgs.untd.com with SMTP id AABE4QGKHA3RNJE2 for (sender ); Thu, 26 Feb 2009 14:35:19 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNwJ0khBKTi5GlwElD0sjntA== Received: (from dyerbrookme@juno.com) by webmail02.vgs.untd.com (jqueuemail) id PAC2PE8A; Thu, 26 Feb 2009 14:35:04 PST Received: from [68.161.198.3] by webmail02.vgs.untd.com with HTTP: Thu, 26 Feb 2009 22:33:51 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Thu, 26 Feb 2009 22:33:51 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090226.173351.29210.0@webmail02.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:3:605327715 X-UNTD-Peer-Info: 10.181.12.142|webmail02.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 22:35:42 -0000 David Levin says: "We often speak of Simulators, Avatars, Regions, Assets and so forth, for the moment, I'm going to keep those terms off the table to th= ink about the problem in its more general form." *notes the moment at which the concept of private property and individua= l rights begins to erode due to "expediency" and the ostensible needs to= "shift the language" to "cooperation"* Avatars as expressions of human beings with rights, regions as expressio= ns of natural geographical contiguity appreciated by those humans, and a= ssets as expressions of property owned by humans with intellectual and p= rivate property rights -- these are all good things. There's nothing wro= ng with the terms or their associations. Once you change this to "Experience Space for Logged-on Entities in Pers= istent Viewing Zones with Transmissable Data" you are well on the way to= -- well, some sort of ism or another, perhaps communism, perhaps Extrop= ianism. Prokofy Neva ____________________________________________________________ Click for an affordable Health Insurance plan that fits your needs. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIn7LHtxI3qUgaNEf5BUJ2= j8BHnz3DhQkYPUwY1JZYysiU68M7u7W/ From belxjander@gmail.com Thu Feb 26 14:57:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88BA728C32B for ; Thu, 26 Feb 2009 14:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK4dDLKF3Kjt for ; Thu, 26 Feb 2009 14:57:03 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id B33C928C22E for ; Thu, 26 Feb 2009 14:57:03 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so688901rvb.49 for ; Thu, 26 Feb 2009 14:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=1Yi2jvRKXg93DzNxNU5A1wM3Dk9k7haGi/FjAGm/l/U=; b=X/LZHxX7xFAQ7wJnXMT7eBxIBmr9Vw0ALI/1ZQLwCpm73IxQSmcbAh90VMrSXlHxz2 IumBMP8eq6zgnzwvXL2zHFkuuuqXW824gxOJh2SoZUduMYThNpdDPB8h3YqZRpYpM9xh CHIZONv5lQp05T+ZIHuirjrbQ9u0pKFnaZcwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=ip1/W/Vw2zesL5JAZzSGuXRnQwjpUoQu2Q6mhBeC/Kf0Bbm7L4xYF2cIMibJME49Nc jmuLBTDFydV0sXg9cNhLHcsSw68tbGyg1uQB159qvtiWQmqVlalyOMpTAM7S2HkPcd0s fMEeI2xKY2x/u9o1na6S/6NTbaIRRB5CjiOfQ= Received: by 10.141.36.10 with SMTP id o10mr855453rvj.152.1235689045653; Thu, 26 Feb 2009 14:57:25 -0800 (PST) Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g31sm6651857rvb.7.2009.02.26.14.57.24 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 14:57:25 -0800 (PST) From: Kajikawa Jeremy To: "mmox@ietf.org" In-Reply-To: <7D208FA9-3C91-422F-B24F-F1B0B85908B9@lindenlab.com> References: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> <7D208FA9-3C91-422F-B24F-F1B0B85908B9@lindenlab.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-plikhTkfVabR6LgvqjIy" Date: Fri, 27 Feb 2009 07:51:48 +0900 Message-Id: <1235688708.4026.47.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Subject: Re: [mmox] Open Grid Protocol -- Maybe need a redifinition for MMOX scope ? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 22:57:04 -0000 --=-plikhTkfVabR6LgvqjIy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable If the Open Grid Protocol needs redefining ... Here is a proposal for consideration... In which case the OGP itself becomes a defined framework with modules and each module has a preset function... being the root access of the Open Grid Protocol /Session -- Module for maintaining "Client" connection to the VW, *all* additional modules use "handle" for the session module in-use. The OGP library only define a standard access library for code modules, where individual clients may provide an "own session" module for protocol There is two "global" methods used for accessing modules of the OGP library OpenModule() Load and call an Init Function for the Module named CloseModule() call an Exit() function also allowing the module to be free'd The "Session" module is defined with the following functionality, Login - Creating an Active Connection and Identifying to a User Account Logout - Ending an Active Connection =20 Send() - Extension Modules call this to send anything, Recv() - Extension Modules call this to read anything within a set time, ErrorString() - *Optional* provision of error code strings for user messages ::OpenModule(name) returns "handle" for module reference ::CloseModule(handle) /Session::Login(server,user,pass) returns token /Session::Logout(token) -> return always success /Session::Send() /Session::Recv() /Session::ErrorString() The above lacks any reference or allowance for incoming messages to trigger events, and I am assuming everyone here is capable of setting up a mechanism for read() calls to trigger as required or occur at extremely frequent timing intervals. Im allowing for the protocol itself to have multiple versions installed and current code to be used side-by-side with new code... if this is feasible... or am I missing something about the way python works different from C ? Jeremy --=-plikhTkfVabR6LgvqjIy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJpx0EAAoJECHrKutFYVwTe6MP/iFQ4k4jLH/zH1l/ZpiSGe15 3GYBfrZPhrCNkuumUbgguVWwWUxb+spjm+/v/pw8jd22LGb7KIVonXBEZGhz1Slp z/BxInObuVBddB2Zk/rRHCmgrboq9/GMQennhoMiij0CRvNQzH9GXE4bj6ZCuiRN zYKBy/s0eTgHSn/h3Nlfpa3+K9bsA9jJzgKNM0Sugzry0B4G8e2NGzsT6QqYUtiv HwKd6aRn19N8oMaZL6FtcAVZaZ9MXKVz7DWnawNs6nLwLqKMIL3qCsQvlNbpOo5l A5HDp6TicY9XUFyrxKoE4CN81g9J5SQofRgLC5glWP8S9jEiRHMQd6SIdgMQ01eA 3LiVDTTKBlH1Dz977SmlmBNFc5jXjfuwMHoDjKpiSpe66wdkFMnI+DBQFmAGG9ow BPXw6H9aStAIvP5/cV9BIflclWzJpF+iCC6z9OkERTyw0b2erZQYrTMpjtBaDoB9 byaA6K7Yw0MIH6BPer+l5Loz4QMpmhMgm3a3MeekEWzzZqqDaFrEEkVCFPuKhuOr z5QpaMXH5KbBAPPsLwS1Y2FijakI50+zQHcpRURkesmLYQMBNQYSlxr23Af3G9fD 4ydjfHmzKwzaZRftWn5r68+SJzhIA3u6gYO8TNNEqmSlSjYWih9GKZxPw39ZNtWl psKnv+tqSxYB4A7QSNzV =MXwH -----END PGP SIGNATURE----- --=-plikhTkfVabR6LgvqjIy-- From cs@comlounge.net Thu Feb 26 15:15:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3CCE3A6A75 for ; Thu, 26 Feb 2009 15:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJgnEP8mT8h0 for ; Thu, 26 Feb 2009 15:15:07 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 306073A68CD for ; Thu, 26 Feb 2009 15:15:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 77F811CE03D5; Fri, 27 Feb 2009 00:15:28 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf2abtSueNEZ; Fri, 27 Feb 2009 00:15:27 +0100 (CET) Received: from [192.168.2.101] (pD9EBC236.dip.t-dialin.net [217.235.194.54]) by post.comlounge.net (Postfix) with ESMTP id 534EA1CE0001; Fri, 27 Feb 2009 00:15:27 +0100 (CET) Message-ID: <49A7228F.1070902@comlounge.net> Date: Fri, 27 Feb 2009 00:15:27 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> In-Reply-To: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] what does it mean to be interoperable? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 23:15:11 -0000 I just wonder if you not first need to define what a virtual world is as it seems to me a conglomeration of lots of concepts. E.g. there is the whole social space which seems very similar in what's going on on the web and has many aspects to it already. There is also the 3D area which is about objects and how to transfer and display them, there are avatars, there are actual worlds and so on. And I think some areas here might be easier to tackle (e.g. mostly 2D space) because there might be more common understanding already about this (and it's mostly HTML/HTTP based which is used by everybody and thus makes things easier). On the 3D part the question is how to partition further. I think for different sub-protocols we might choose different variants of the choices below. But one is maybe for sure and that is that 1) and 2) are out for not only VWs but for basically everything. But if you exchange "virtual worlds" by some sub-area then there might actually be a unified client for these (again most likely in the social space where it can be a web browser). For the full stack it's most likely no unified client because I doubt that we all can find one solution which fits us all (in all eternity). So it probably will come down to 5. Maybe some stuff is bridgable with not too much effort, then this might be an option for 6 but I have too little understanding of all things to really be able to speculate about that. -- Christian Meadhbh Hamrick (Infinity) schrieb: > so it seems clear we all have different ideas of what it means to be > interoperable. > > i thought i might try to define a couple of the definitions i think i've > seen people use: > > 1. interoperability means all virtual worlds, wherever they are, may be > accessed via a single unified client. > > 2. interoperability means all virtual worlds, wherever they are, use > precisely the same protocol(s) and all virtual worlds represent data in > formats understandable by all other virtual worlds, with a universal > client. > > 3. interoperability means some virtual worlds may be accessed via a > single unified client. > > 4. interoperability means some virtual worlds use precisely the same > protocol(s) and all virtual worlds represent data in formats > understandable by all other virtual worlds, without a universal client. > > 5. interoperability means some virtual worlds use some of the same > protocols, without a universal client > > 6. interoperability means the "model" is the same, but with different > protocols that may be bridged with protocol gateways. > > it seems to me that many of us are using different descriptions for the > word "interoperable" and it's causing mild discord and at least a couple > instances of us talking past each other. > > personally.. i'm kind of interested in option 5. it has the benefit of > producing a protocol that is identifiable by routers, network management > software, etc. it also provides a "slowly moving target" for open source > developers (as opposed to the "fast moving target" of linden's existing > protocol(s)). by making it public, VW operators can choose whether or > not they wish to implement it. it also doesn't require VW operators to > implement it (as if we could anyway) and it allows VW operators to avoid > having to test interoperability with every other virtual world. > > but it's not without drawbacks... this model can lead to a "MOSS-like" > environment. (for those of you who don't remember MOSS or MIME Object(?) > Security Services... it was a response to the drawbacks of PEM (privacy > enhanced mail) which had a relative paucity of encryption options. but > IMHO, MOSS introduced so many options that it was VERY easy for two > implementations to adhere to the spec, but not actually be interoperable.) > > so... i recommend that if we (as a group) wanted to pursue option-5.. we > also explicitly define what goes in an "interoperability profile." that > way you could get the benefit of having a relatively stable protocol > that could be targeted by open source developers which could be used by > VW operators to help make client / server apps. > > VW operators could publish their "interoperability profile" to tell > people who wanted to build tools, extra services, or interoperable > worlds what options would be available and how they would work. > > -cheers > -m > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From jwatte@gmail.com Thu Feb 26 15:20:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E67FC3A6767 for ; Thu, 26 Feb 2009 15:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQkZ-NTnL3sU for ; Thu, 26 Feb 2009 15:20:20 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id ABAD43A68F4 for ; Thu, 26 Feb 2009 15:20:20 -0800 (PST) Received: by gxk22 with SMTP id 22so1905289gxk.13 for ; Thu, 26 Feb 2009 15:20:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=WR1JbT4/ApC6Y6iIi3k3T7aL+A60BZ292AS4hy0PIMc=; b=cvVM3YOouPG9+eelX9OFbmiEIGJF2SC6mWMaqAFLpl5lyyQcnLuY+ovjVlL8ILH7hn jTYbD9A/25lxp9/P13+ms8u2/ZXl9WF0DHG41qbO5X2ja3I2IroQ8R7cCUwP8iQAiDnk iuuE6mMkQL5LnEM0xdKXV0cspfCaXtG6zNP2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=UCXQt8TEU78JA4KlDqroQv5YmwmQskzQJkxh9Z5Na7J9hSB865wGHEA+EI0UnqDBMP IE+oxMFttnOD37qsABNK7BpqQTOLKdXh2UCLw76r8wjUtPIgPvVsDD159x+91fz1ZgdA VQi+Bu3MfhsZygab2iiE8RqLyIJIKSXvmRAlQ= Received: by 10.100.3.13 with SMTP id 13mr2131417anc.31.1235690442043; Thu, 26 Feb 2009 15:20:42 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d21sm6005714and.26.2009.02.26.15.20.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 15:20:41 -0800 (PST) Message-ID: <49A723C7.4030904@gmail.com> Date: Thu, 26 Feb 2009 15:20:39 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> <7D208FA9-3C91-422F-B24F-F1B0B85908B9@lindenlab.com> In-Reply-To: <7D208FA9-3C91-422F-B24F-F1B0B85908B9@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] what does it mean to be interoperable? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 23:20:22 -0000 Meadhbh Hamrick (Infinity) wrote: > i don't know if linden could ever support an option-4, because of our > desire to have interoperability drive "user innovation." in other > words, we'll always be interested in a situation where developers > could extend the protocol to support value-added services. we're not > terribly frightened of option-5 because our view of the world has VW > operators deploying client software unique to their solution to handle > these value-added services. > I believe in that model (4), too. Now there are two things that I think are important: 1) An option-4 solution (there are protocols and formats that everyone recognizes), it's easy enough to add extensibility, on the level of "while we recognize the basic set, we can also recognize these additional things." In fact, not doing that would be almost criminally shortsighted. 2) An option-4 solution provides the model for interoperability, but for innovation or platform-specific features, you simply don't interoperate those bits. They are, after all, platform specific. For example, when interoperating, the network usage for an OLIVE client will go up, because the svelte network usage of OLIVE requires OLIVE-proprietary technology. > in short, we expect OGP to never be a complete specification of a > virtual world protocol, but rather a protocol framework that together > with an interoperability profile sufficiently specifies client and > server behavior to achieve some measure of interoperability. So, in effect, it will probably lead to the MOSS outcome, except for certain small cliques (There.com clusters talking to other There.com clusters; OpenSim talking to Second Life, Croquet talking to Qwaq, etc). That is not partucularly exciting to me, because I don't believe it will lead to the kinds of interoperability that our customers (and the world in general) deserves and demands. I asked the question before, but didn't get an answer: What would you opinion be of doing the OGP/SL/OSim work in a forum like the AWG, and doing the option-4 work in the MMOX group? Would you lose anything if that's the approach? Sincerely, jw From cs@comlounge.net Thu Feb 26 15:21:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914BF3A68F4 for ; Thu, 26 Feb 2009 15:21:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DArfTmFjYd37 for ; Thu, 26 Feb 2009 15:21:40 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 1AB1A3A6767 for ; Thu, 26 Feb 2009 15:21:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 9A7481CE029D; Fri, 27 Feb 2009 00:22:01 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1RasznWcLOz; Fri, 27 Feb 2009 00:22:01 +0100 (CET) Received: from [192.168.2.101] (pD9EBC236.dip.t-dialin.net [217.235.194.54]) by post.comlounge.net (Postfix) with ESMTP id 085C21CE0001; Fri, 27 Feb 2009 00:22:01 +0100 (CET) Message-ID: <49A72419.70904@comlounge.net> Date: Fri, 27 Feb 2009 00:22:01 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jon Watte References: <53cd6c2e0902260734t7336df2dp2a97bd93b5db792b@mail.gmail.com> <49A6E86D.9040906@gmail.com> In-Reply-To: <49A6E86D.9040906@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] A tentative top-down analysis X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 23:21:41 -0000 Jon Watte schrieb: > That's right! Incidentally, this matches almost exactly the "connected > server peers" model that I've been proposing. > > However, the objects themselves are owned by one of those N providers > (or else why is the provider supplying authoritative state for it?) But I want to own my data :-) I might give you a license though to host it for me. But actually I should also be able to host my own inventory and simply give you the URL to it (which in fact might be a simple web server). So there could even be simple hosting servers which are dumb regarding the whole VW thing and simply host objects without ever doing any simulation. And I can simply put those URLs into my users's service catalogue to be discovered by some simulator. >> What's more, those updates will often need to continue even when (i) >> the avatar is currently offline, and when (ii) the items are dispersed >> across many other worlds, and when (iii) the avatar is currently in a >> world with which they do not have direct interop. >> > > Saying that the object update persists in the simulation when you don't > have interop with the viewer is like saying that you can browse the > YouTube video library when you have disconnected your Internet > connection. I don't think that would be realistic. Well, I can browse my podcast collection. It's just a question of how you define caching. > >> The last point is particularly revealing: provider A may have an >> explicit agreement to interoperate with provider B, and provider B may >> have an agreement with provider C, without A and C having any direct >> agreement whatsoever. Yet, an avatar registered on B and wearing an >> unencumbered object from A will naturally be visiting world C, and the >> worn object must continue to fulfil its normal purpose or interop has >> failed. >> > > Agreed! Well, we thought a bit about this chaining of trust (if it comes to the creator's will) and it might be problematic depending on what choices you want to give the user and the creator. As a creator you then can never be sure where that object goes. But it's maybe mainly a question if you allow it to leave the originating VW or not. If you choose not to you are more safe apparently than if you choose to allow it (but might make more sales). But of course from a technical perspective I agree. It should potentially work in C. -- Christian -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From jwatte@gmail.com Thu Feb 26 15:28:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB143A6ACD for ; Thu, 26 Feb 2009 15:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXfbeQeJSMBe for ; Thu, 26 Feb 2009 15:28:44 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 690EE3A6AB9 for ; Thu, 26 Feb 2009 15:28:44 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1002434yxm.49 for ; Thu, 26 Feb 2009 15:29:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=O7b3V0N1X/nhOdoMdmtMLpF7ei1sGjhUWx+CUdUfcfg=; b=d5pB7fWa6GLDLgf2zNkietELCDcsc6cwb+ASYj4PjYrn1gSN4MnZOdHuEfirGd7d3r w2MEP4K/NXLZAaXCEsQtsd8OGSGr7D6c4915n/WnlqZg6qs4tjDUgdCHBiue+VTuhYP5 ClUIySwZNhmso660Ew1I5szMloZ3QRZ9oNN5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BiaxWKj+z1saNPLHyyS3Sl1C44TEXvQQNCSa4o4ree0iXz5szdtVWqdwQYfndfOoS9 6G2owKuhmBac7dQr0GacjX1g3iOYYmBNyRnjazRjptpn29NKoPUjQCIhCU0jlwpBiRUI 8sj+o4IAYg5XiNC41Xrwj6gFMydJaoKE2daAg= Received: by 10.100.166.10 with SMTP id o10mr897832ane.96.1235690946053; Thu, 26 Feb 2009 15:29:06 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d35sm7062923and.38.2009.02.26.15.29.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 15:29:05 -0800 (PST) Message-ID: <49A725BF.3040103@gmail.com> Date: Thu, 26 Feb 2009 15:29:03 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Kajikawa Jeremy References: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> <7D208FA9-3C91-422F-B24F-F1B0B85908B9@lindenlab.com> <1235688708.4026.47.camel@localhost> In-Reply-To: <1235688708.4026.47.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Open Grid Protocol -- Maybe need a redifinition for MMOX scope ? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 23:28:45 -0000 Kajikawa Jeremy wrote: > There is two "global" methods used for accessing modules of the OGP > library > > OpenModule() Load and call an Init Function for the Module named > CloseModule() call an Exit() function also allowing the module to be > free'd > > A protocol and a library are two totally different things. The charter of this group is to define a wire protocol, not an API or a library. Do you think you can re-phrase your suggestion as a change in protocol, rather than change in API? Sincerely, jw From jwatte@gmail.com Thu Feb 26 15:33:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883D53A6954 for ; Thu, 26 Feb 2009 15:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gju9TZAbzBUB for ; Thu, 26 Feb 2009 15:33:19 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 8F3DE3A68CD for ; Thu, 26 Feb 2009 15:33:19 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so737953ana.4 for ; Thu, 26 Feb 2009 15:33:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0ndjgUXorPzYPCi5RClQ+qp4n4/wBZk09lz6OK1Vc9Y=; b=VZzSn5JOnhr8ryppgodHX7XBU0M4yZLnk6fB+lK5PgyHPRufB05JbUMJYYopnYUrD1 r5VcC3nGELsyK1Q8LtpnGOzmvDEweEwiIjKjpWEkOGagOzsALWAsDwmb7QRVIxFk+zv4 YRwMX/8z9WAQk3Y6YvKsJ0YXaq+cJx74A0M9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MCzXQJfXJsT9KOD4gg7lySDISjvm2Lmg9SeTnHv2BgVXiKEm8iUmsjl3H1WjGEoibN RQAIp6P1MCESkMRhBDRtdjzt32BmODWNUjKUsq8P1QJ3A0S3M3775VUz39W+P26PTSv2 zBfkmkh1ZQ3vMe56nbXfYtjXgur8dKv52Y/z4= Received: by 10.100.107.17 with SMTP id f17mr2137701anc.51.1235691221074; Thu, 26 Feb 2009 15:33:41 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c28sm1277704anc.25.2009.02.26.15.33.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 15:33:40 -0800 (PST) Message-ID: <49A726D1.4000404@gmail.com> Date: Thu, 26 Feb 2009 15:33:37 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Christian Scholz References: <53cd6c2e0902260734t7336df2dp2a97bd93b5db792b@mail.gmail.com> <49A6E86D.9040906@gmail.com> <49A72419.70904@comlounge.net> In-Reply-To: <49A72419.70904@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] A tentative top-down analysis X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 23:33:20 -0000 Christian Scholz wrote: > Jon Watte schrieb: > >> That's right! Incidentally, this matches almost exactly the >> "connected server peers" model that I've been proposing. >> >> However, the objects themselves are owned by one of those N providers >> (or else why is the provider supplying authoritative state for it?) > > But I want to own my data :-) Sorry, I'm confusing the terminology here. The server "owns" the object in the sense that it is the authoritative source of property values for that object. I did not mean to imply any ownership in the IP sense, because that discussion does not apply to the particular technical details we're talking about; it's handled at a different layer. > So there could even be simple hosting servers which are dumb regarding > the whole VW thing and simply host objects without ever doing any > simulation. > And I can simply put those URLs into my users's service catalogue to > be discovered by some simulator. > Unfortunately, simulators use different scripting languages, execution environments, APIs and architectures. Thus, you may be able to have a dumb server (like a web server), but it could only serve an object to, say, a Second Life-compatible server, or a Metaverse-compatible server, unless the behavior of the object was re-developed for each simulation platform. Sincerely, jw From cs@comlounge.net Thu Feb 26 15:37:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31393A68CD for ; Thu, 26 Feb 2009 15:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzXiV5u7Temw for ; Thu, 26 Feb 2009 15:37:14 -0800 (PST) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 756263A68F4 for ; Thu, 26 Feb 2009 15:37:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 03D7C1CE03D5; Fri, 27 Feb 2009 00:37:36 +0100 (CET) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LF0twM3rzBN; Fri, 27 Feb 2009 00:37:35 +0100 (CET) Received: from [192.168.2.101] (pD9EBC236.dip.t-dialin.net [217.235.194.54]) by post.comlounge.net (Postfix) with ESMTP id 305701CE0001; Fri, 27 Feb 2009 00:37:35 +0100 (CET) Message-ID: <49A727C0.8010002@comlounge.net> Date: Fri, 27 Feb 2009 00:37:36 +0100 From: Christian Scholz User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jon Watte References: <53cd6c2e0902260734t7336df2dp2a97bd93b5db792b@mail.gmail.com> <49A6E86D.9040906@gmail.com> <49A72419.70904@comlounge.net> <49A726D1.4000404@gmail.com> In-Reply-To: <49A726D1.4000404@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] A tentative top-down analysis X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2009 23:37:15 -0000 Jon Watte schrieb: > Christian Scholz wrote: >> Jon Watte schrieb: >> >>> That's right! Incidentally, this matches almost exactly the >>> "connected server peers" model that I've been proposing. >>> >>> However, the objects themselves are owned by one of those N providers >>> (or else why is the provider supplying authoritative state for it?) >> >> But I want to own my data :-) > > Sorry, I'm confusing the terminology here. The server "owns" the object > in the sense that it is the authoritative source of property values for > that object. I did not mean to imply any ownership in the IP sense, > because that discussion does not apply to the particular technical > details we're talking about; it's handled at a different layer. Ok, we should define some terminology at some point anyway. >> So there could even be simple hosting servers which are dumb regarding >> the whole VW thing and simply host objects without ever doing any >> simulation. >> And I can simply put those URLs into my users's service catalogue to >> be discovered by some simulator. >> > > Unfortunately, simulators use different scripting languages, execution > environments, APIs and architectures. Thus, you may be able to have a > dumb server (like a web server), but it could only serve an object to, > say, a Second Life-compatible server, or a Metaverse-compatible server, > unless the behavior of the object was re-developed for each simulation > platform. Or it could provide different versions. Sort of like content negotiation. -- Christian -- Christian Scholz Blog: http://mrtopf.de/blog Company: http://comlounge.net Podcasts: http://datawithoutborders.net, http://openweb-podcast.de From lenglish5@cox.net Thu Feb 26 16:01:26 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755B13A6847 for ; Thu, 26 Feb 2009 16:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.859 X-Spam-Level: X-Spam-Status: No, score=0.859 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl32742cE-5T for ; Thu, 26 Feb 2009 16:01:25 -0800 (PST) Received: from fed1rmmtao105.cox.net (fed1rmmtao105.cox.net [68.230.241.41]) by core3.amsl.com (Postfix) with ESMTP id 9F89F3A67D7 for ; Thu, 26 Feb 2009 16:01:25 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090227000146.RHFC15318.fed1rmmtao105.cox.net@fed1rmimpo03.cox.net>; Thu, 26 Feb 2009 19:01:46 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id Lo1n1b0054N6T0Q04o1nPd; Thu, 26 Feb 2009 19:01:47 -0500 X-Authority-Analysis: v=1.0 c=1 a=AfYVl4n-8fwA:10 a=5qzUSljf7S4A:10 a=Wajolswj7cQA:10 a=cfHPFXhNAAAA:8 a=aVDVc83y6H6l9JL9qP8A:9 a=uLjKY98DJby9m3bJRIr_iQiyYF8A:4 a=vNGxQsTWjH8A:10 X-CM-Score: 0.00 Message-ID: <49A72D6B.6020003@cox.net> Date: Thu, 26 Feb 2009 17:01:47 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Marshall Eubanks References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> <49A666ED.6040508@cox.net> <49A6E3C1.3000702@gmail.com> <49A6E7C9.8040703@cox.net> <49A6F405.7000207@gmail.com> <63B7B0AE-3C37-42A2-A23A-753CF6413535@multicasttech.com> In-Reply-To: <63B7B0AE-3C37-42A2-A23A-753CF6413535@multicasttech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 00:01:26 -0000 Marshall Eubanks wrote: > This may be a simplistic (i.e., dumb) question, but I work in > Telepresence, and can certainly > see mixed Virtual World / Real World telepresence sessions (and, even, > Telepresence between > incompatible virtual worlds as a means of connecting the unconnectable). > > Are there any special issues with this, or is this just a subset of > the multiple virtual worlds connection problem. > Actually its hopefully a soon-to-be a [partially] solved subset. We had a meeting in-world (in Second LIfe) last Friday to try to explore the relevant issues for a jointly shared virtual telepresence at the BOF meeting in march. The transcript is found here: http://wiki.secondlife.com/wiki/MMOX/Chat_Logs/2009-2-19 Lawson From lenglish5@cox.net Thu Feb 26 16:06:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4A13A6847; Thu, 26 Feb 2009 16:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.866 X-Spam-Level: X-Spam-Status: No, score=0.866 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFE3l9Fvw1l1; Thu, 26 Feb 2009 16:06:36 -0800 (PST) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id 655DD3A67D7; Thu, 26 Feb 2009 16:06:36 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090227000659.PQMM12540.fed1rmmtao106.cox.net@fed1rmimpo02.cox.net>; Thu, 26 Feb 2009 19:06:59 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id Lo6x1b00J4N6T0Q04o6yRS; Thu, 26 Feb 2009 19:06:58 -0500 X-Authority-Analysis: v=1.0 c=1 a=wlkkbP_B7z8A:10 a=zhokSRyW8nYA:10 a=Wajolswj7cQA:10 a=PTAdm1Mqj4mX_OtZ5usA:9 a=rrp657sTa4ELriCldiWtO6ifeyIA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <49A72EA1.8090801@cox.net> Date: Thu, 26 Feb 2009 17:06:57 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <61dbdd7d0902261335q608ee9ferc083fdffa87071ed@mail.gmail.com> <49A7184D.3050602@gmail.com> In-Reply-To: <49A7184D.3050602@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 00:06:37 -0000 Jon Watte wrote: > Gareth Nelson wrote: >> any code should be produced in. My vote is for python and C. >> > > Let me vote for Lua and C++, and then the OpenSim people can vote for > C# and Java and we have all the bases covered :-) > Objective C. I need to learn that anyway. Dare I mention Smalltalk? L From jwatte@gmail.com Thu Feb 26 16:26:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2002C3A6833 for ; Thu, 26 Feb 2009 16:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK5PfgflQD9G for ; Thu, 26 Feb 2009 16:26:39 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 9BDBA3A68BF for ; Thu, 26 Feb 2009 16:26:39 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1032161yxm.49 for ; Thu, 26 Feb 2009 16:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=42bnsPgnCVybreR1/5DnJnC+JFrQlknnCjPGj2PxDtc=; b=ASyeR13FsFYqmiLNsYfssKyN5dkZW1QaeFGrFpkyhe9QwZNvi+KDt12SrVzEYVGP8o 6H+JIkzQuu3DEaT70w2odd9jzrxOqVrNOlFVhJO265IuuW6CD5GE1GhO21sRTOX+f/GQ CEUJCmq1ldW0zSgFgNbWDU+IknsDDNfJCwZ0k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=FIdtYuqZpAIraazeJZ6W86pVE3MzN/WG2c/rZ4AUDllUmCPADOXqTXsPLN0z5e+U8b HfNRreltnu0/eIxoCr8QoSP/leZF5VNXXq53zOOZZJqdke++duJbuqmDo4eiOGOtjXAA BP+vyE6VB6CPnVdVZ2wEjWTOwjKHZMGcH/DLY= Received: by 10.100.96.9 with SMTP id t9mr2117615anb.109.1235694420312; Thu, 26 Feb 2009 16:27:00 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d22sm2826917and.47.2009.02.26.16.26.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 16:26:59 -0800 (PST) Message-ID: <49A73351.5030006@gmail.com> Date: Thu, 26 Feb 2009 16:26:57 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <20090225.182222.10290.1@webmail10.vgs.untd.com> <62BFE5680C037E4DA0B0A08946C0933D502DF61E@rrsmsx506.amr.corp.intel.com> <49A65D92.3060606@comlounge.net> <49A666ED.6040508@cox.net> <49A6E3C1.3000702@gmail.com> <49A6E7C9.8040703@cox.net> <49A6F405.7000207@gmail.com> <63B7B0AE-3C37-42A2-A23A-753CF6413535@multicasttech.com> <49A72D6B.6020003@cox.net> In-Reply-To: <49A72D6B.6020003@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] RealExtend Teleporting Between Worlds X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 00:26:41 -0000 Lawson English wrote: > Actually its hopefully a soon-to-be a [partially] solved subset. We > had a meeting in-world (in Second LIfe) last Friday to try to explore > the relevant issues for a jointly shared virtual telepresence at the > BOF meeting in march. The transcript is found here: Does anyone have the actual details for that BOF meeting? Time, place, registration details? Sincerely, jw From jwatte@gmail.com Thu Feb 26 16:40:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9D193A6A26 for ; Thu, 26 Feb 2009 16:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBpj8kvRYTh0 for ; Thu, 26 Feb 2009 16:40:57 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id F086E3A69B1 for ; Thu, 26 Feb 2009 16:40:56 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1039333yxm.49 for ; Thu, 26 Feb 2009 16:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=D2bPja8HhpFrJ1845VkhZBhPsECkSZpzYwjETHInDfk=; b=t0Bubnyx+V2H4QRAZLqureqjDsDsZ0xIq669ofkljuXbQnlI4clKKaoKPuFJIx9Opl /pCKkU35HZsO15HdUlOpewVuS0Fbbrnk+bxKoVp+hmTvs0eN3+kql0/bEiIfutOyeN1W 8bY0F8IjawXWNA3sRA+gZL+Dv202MIFGnQeYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=wEGK6FkkPlO5ixKzoGGr5IHrvHXVAoyYWXzcOG5fNVhzqcTC25wY2LtQKtZ7XDYms/ t16yFjn7e1Bg1MJn5SgH6g0gEskgmExv3fRB54Sg9ausxTxRLowRHQleLx6cJi7cWFhT 1JXrmg6Psw+nKm6QnOIf9ow01A0PEwicjvGVs= Received: by 10.100.240.17 with SMTP id n17mr972702anh.48.1235695277495; Thu, 26 Feb 2009 16:41:17 -0800 (PST) Received: from ?192.168.168.114? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b7sm6195392ana.59.2009.02.26.16.41.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 16:41:16 -0800 (PST) Message-ID: <49A736AA.2020205@gmail.com> Date: Thu, 26 Feb 2009 16:41:14 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] Use cases? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 00:40:58 -0000 I posted five use cases that I think cover a fair range of virtual world interoperability. I've gotten several nice replies in the mail, but on the list they seem to have soared like a lead balloon, as opposed to all talk about XML vs binary vs IP property rights. Surely, agreeing on requirements (such as use cases) is actually more important than discussing implementation details that we don't even know will apply yet? Any opinions, for or against, regarding these use cases? Silent assent? http://www.interopworld.org/mmox-use-cases Sincerely, jw From infinity@lindenlab.com Thu Feb 26 17:16:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C2B33A6A31 for ; Thu, 26 Feb 2009 17:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UfGflnqh5CFS for ; Thu, 26 Feb 2009 17:16:30 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 6F9243A67B4 for ; Thu, 26 Feb 2009 17:16:30 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 781561414002; Thu, 26 Feb 2009 17:16:52 -0800 (PST) Message-Id: <4EC4C999-59E9-49BF-99C0-82ED4BBD9A64@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49A736AA.2020205@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 17:16:52 -0800 References: <49A736AA.2020205@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] Use cases? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:16:31 -0000 well... yes and no... use cases are important. but to prevent feature creep having a charter + a concrete proposal is always convenient. our charter is under discussion and is therefore at least "plastic" if not "fluid." but yes. if i had it to do over, i would have published as much of OGP as we currently have defined along with LLSD as it's the application level that ultimately will be more interesting. -cheers -meadhbh On Feb 26, 2009, at 4:41 PM, Jon Watte wrote: > I posted five use cases that I think cover a fair range of virtual > world interoperability. I've gotten several nice replies in the > mail, but on the list they seem to have soared like a lead balloon, > as opposed to all talk about XML vs binary vs IP property rights. > Surely, agreeing on requirements (such as use cases) is actually > more important than discussing implementation details that we don't > even know will apply yet? > > Any opinions, for or against, regarding these use cases? Silent > assent? > > http://www.interopworld.org/mmox-use-cases > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From wolf.heiner@googlemail.com Wed Feb 25 13:09:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBCFA3A68C6 for ; Wed, 25 Feb 2009 13:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVQ-BZaZCB0N for ; Wed, 25 Feb 2009 13:09:21 -0800 (PST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.188]) by core3.amsl.com (Postfix) with ESMTP id 8281428C178 for ; Wed, 25 Feb 2009 13:09:20 -0800 (PST) Received: by nf-out-0910.google.com with SMTP id d3so101261nfc.39 for ; Wed, 25 Feb 2009 13:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=6WphqiX7AkjNl7YktzmFx+ZkRbJSrx22LTRbq5Mevr4=; b=mTVbwJa4sRodnOMyJ5UoUCqIk03WRVT6uGOPM1Ut4BUnfLUHdVD9wjXFKiFT4CMSIJ V0pjZ84wMd+xp3t7EuFQvN5qrNCRERdO7hQkV8DeXJRzQC89elHzq3CXWh3k9NosKQOI Nlja7b0YFSuzCzf5xSwBs6ZWINuC376qbMMZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Bgy4++MgQYJFvlFtbZS7FYUkYoMwODBUlhz+ROi3oUkFEWFonfR1MOpZMxFVsh+xXf y3oO4DgjWLA1t/V12EsDYJWsuBzGEISclDryU6acGMHl9qCkreMQXI8aWgagvOQGG0YH UG78MW3atok7KL5E1ryjtNrvfPZOmZfdtFaOE= MIME-Version: 1.0 Received: by 10.210.36.8 with SMTP id j8mr383001ebj.83.1235596180423; Wed, 25 Feb 2009 13:09:40 -0800 (PST) Date: Wed, 25 Feb 2009 22:09:40 +0100 Message-ID: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> From: Heiner Wolf To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 26 Feb 2009 17:24:00 -0800 Subject: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 21:11:23 -0000 Hi, I understand that the original intention was to make OGP public and get comments. But if that's the purpose you probably should call the WG OGP. We had a similar situation in the Instant Message and Presence WG, where several vendors tried to talk about "their" protocol. Lisa probably remembers. The situation was solved by chartering the IMPP WG to create only requirements, then 2 new WGs worked on "their" protocol (SIMPLE, XMPP). I bet we get a similar discussion. Maybe MMOX should define requirements and an OGP WG may then work on the OGP way later. This gives time for other developers to speak up and add learnings from "their" worlds and protocols. Do we have people from Everquest, WoW, There, EVE Online, Runescape, Google Earth here? We need them for something thats called MMOX. We should give them time to speak up. BTW: we are building a virtual world based on XMPP chat rooms. There are more, like IMVU, which use chat protocols for their virtual worlds. The chat room is what you would call a region domain. This is quite a different angle, but an interesting one, because the transport protocol is very simple and has few extensions.The extensions carry the 3D stuff. An interesting feature of worlds which are based on chat protocols is, that there is low in-band traffic. The reason is, that off the shelf chat servers are not build for heavy traffic. So, only notifications are transferrred in the chat protocol. Assets use a separate data access protocol, usually HTTP. This simplistic view of people who use chat protocols for virtual worlds could be useful in identifying "what you really need" for a VW interop protocol. hw -- Dr. Heiner Wolf wolf.heiner@gmail.com www.wolfspelz.de www.virtual-presence.org From infinity@lindenlab.com Thu Feb 26 17:26:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC513A6AC3 for ; Thu, 26 Feb 2009 17:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aI71IKZzy2+q for ; Thu, 26 Feb 2009 17:26:37 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id BA6533A6832 for ; Thu, 26 Feb 2009 17:26:37 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id EA74B1414005; Thu, 26 Feb 2009 17:26:59 -0800 (PST) Message-Id: <9A542216-8DD4-4FB0-9961-8AC73EC3A7E2@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Heiner Wolf In-Reply-To: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 17:26:59 -0800 References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:26:38 -0000 excellent insight, heiner! i would not be surprised if this is the direction we take. On Feb 25, 2009, at 1:09 PM, Heiner Wolf wrote: > Hi, > > I understand that the original intention was to make OGP public and > get comments. But if that's the purpose you probably should call the > WG OGP. > > We had a similar situation in the Instant Message and Presence WG, > where several vendors tried to talk about "their" protocol. Lisa > probably remembers. The situation was solved by chartering the IMPP WG > to create only requirements, then 2 new WGs worked on "their" protocol > (SIMPLE, XMPP). I bet we get a similar discussion. Maybe MMOX should > define requirements and an OGP WG may then work on the OGP way later. > This gives time for other developers to speak up and add learnings > from "their" worlds and protocols. Do we have people from Everquest, > WoW, There, EVE Online, Runescape, Google Earth here? We need them for > something thats called MMOX. We should give them time to speak up. > > BTW: we are building a virtual world based on XMPP chat rooms. There > are more, like IMVU, which use chat protocols for their virtual > worlds. The chat room is what you would call a region domain. > > This is quite a different angle, but an interesting one, because the > transport protocol is very simple and has few extensions.The > extensions carry the 3D stuff. An interesting feature of worlds which > are based on chat protocols is, that there is low in-band traffic. The > reason is, that off the shelf chat servers are not build for heavy > traffic. So, only notifications are transferrred in the chat protocol. > Assets use a separate data access protocol, usually HTTP. > > This simplistic view of people who use chat protocols for virtual > worlds could be useful in identifying "what you really need" for a VW > interop protocol. > > hw > -- > Dr. Heiner Wolf > wolf.heiner@gmail.com > www.wolfspelz.de > www.virtual-presence.org > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From gareth@litesim.com Thu Feb 26 17:29:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483CE3A6ABE for ; Thu, 26 Feb 2009 17:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRxJNCz2kX4J for ; Thu, 26 Feb 2009 17:29:50 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 49FF83A6A79 for ; Thu, 26 Feb 2009 17:29:50 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so743723rvb.49 for ; Thu, 26 Feb 2009 17:30:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.100.15 with SMTP id c15mr922344rvm.52.1235698212171; Thu, 26 Feb 2009 17:30:12 -0800 (PST) In-Reply-To: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> Date: Fri, 27 Feb 2009 01:30:12 +0000 Message-ID: <61dbdd7d0902261730u2113798fl95f2f1c49113ffca@mail.gmail.com> From: Gareth Nelson To: Heiner Wolf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:29:51 -0000 I once built an IMVU-like hack on top of IRC (used a specially formatted topic, rather messy), it works beautifully well for IMVU-like systems but breaks down fast once you need physics, there needs to be more than mere message passing and what Zha constantly likes to remind us of: state melding. On Wed, Feb 25, 2009 at 9:09 PM, Heiner Wolf wrote: > Hi, > > I understand that the original intention was to make OGP public and > get comments. But if that's the purpose you probably should call the > WG OGP. > > We had a similar situation in the Instant Message and Presence WG, > where several vendors tried to talk about "their" protocol. Lisa > probably remembers. The situation was solved by chartering the IMPP WG > to create only requirements, then 2 new WGs worked on "their" protocol > (SIMPLE, XMPP). I bet we get a similar discussion. Maybe MMOX should > define requirements and an OGP WG may then work on the OGP way later. > This gives time for other developers to speak up and add learnings > from "their" worlds and protocols. Do we have people from Everquest, > WoW, There, EVE Online, Runescape, Google Earth here? We need them for > something thats called MMOX. We should give them time to speak up. > > BTW: we are building a virtual world based on XMPP chat rooms. There > are more, like IMVU, which use chat protocols for their virtual > worlds. The chat room is what you would call a region domain. > > This is quite a different angle, but an interesting one, because the > transport protocol is very simple and has few extensions.The > extensions carry the 3D stuff. An interesting feature of worlds which > are based on chat protocols is, that there is low in-band traffic. The > reason is, that off the shelf chat servers are not build for heavy > traffic. So, only notifications are transferrred in the chat protocol. > Assets use a separate data access protocol, usually HTTP. > > This simplistic view of people who use chat protocols for virtual > worlds could be useful in identifying "what you really need" for a VW > interop protocol. > > hw > -- > Dr. Heiner Wolf > wolf.heiner@gmail.com > www.wolfspelz.de > www.virtual-presence.org > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From infinity@lindenlab.com Thu Feb 26 17:31:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F393A6ABE; Thu, 26 Feb 2009 17:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2q8AsUPf-Hwt; Thu, 26 Feb 2009 17:31:48 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 001603A6A79; Thu, 26 Feb 2009 17:31:47 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 30BC61414004; Thu, 26 Feb 2009 17:32:10 -0800 (PST) Message-Id: <6CE24396-7167-4B37-A9AC-B1AA3CF7E7AF@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49A7184D.3050602@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 17:32:09 -0800 References: <61dbdd7d0902261335q608ee9ferc083fdffa87071ed@mail.gmail .com> <49A7184D.3050602@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox-bounces@ietf.org, mmox@ietf.org Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:31:49 -0000 i don't think we get to mandate what code people implement the protocol in, but i would certainly add lisp, smalltalk and occam to the list. seriously thought... remember... we're talking about a wire-protocol, not a library that implements the protocol. On Feb 26, 2009, at 2:31 PM, Jon Watte wrote: > Gareth Nelson wrote: >> any code should be produced in. My vote is for python and C. >> > > Let me vote for Lua and C++, and then the OpenSim people can vote > for C# and Java and we have all the bases covered :-) > > >> games are relevant (after all, MMORPGs for example are just huge >> virtual worlds with game rules thrown in), I fail to see how >> networked >> > > I think that's a common mis-conception. Most (almost all) MMOGs do > not have much in the way of persistency, other than character > possessions and stats. They also have a very static world, that > generally does not allow users to move things around or place new > things into the world. Finally, they do not support any form of UGC, > which I think is more or less a requirement for a "real" virtual > world. Lacking all three means that the technical job of > implementing and running the MMORPG is much easier, but it also puts > them on a lower rung of the expressiveness. A VW could express a > MMORPG (with significant overhead compared to the MMORPG itself), > but a MMORPG couldn't express a VW. > >> Practically everything people do online is "multiuser", and lots of >> things are "massively multiuser" - look at any big site such as >> wikipedia for example. >> >> > > "What is virtual worlds" has been a general question for a long > time, but I believe the "rough consensus" answer is that it's at > least: > > Interactive > Persistent > Identity Based > Collaborative > Supports UGC > (controversial) Based on a 3D Simulation > > But, if we believe that we all need to agree on exactly what a > virtual world is before we can make progress, experience shows we > won't be able to make progress at all. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From gareth@litesim.com Thu Feb 26 17:36:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1583A67B4; Thu, 26 Feb 2009 17:36:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-oKHDwPxARF; Thu, 26 Feb 2009 17:36:06 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id 9A7A43A6B13; Thu, 26 Feb 2009 17:36:06 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so745998rvb.49 for ; Thu, 26 Feb 2009 17:36:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.141.4.20 with SMTP id g20mr911225rvi.221.1235698588652; Thu, 26 Feb 2009 17:36:28 -0800 (PST) In-Reply-To: <6CE24396-7167-4B37-A9AC-B1AA3CF7E7AF@lindenlab.com> References: <49A7184D.3050602@gmail.com> <6CE24396-7167-4B37-A9AC-B1AA3CF7E7AF@lindenlab.com> Date: Fri, 27 Feb 2009 01:36:28 +0000 Message-ID: <61dbdd7d0902261736o556ba122p3521581417bb95cf@mail.gmail.com> From: Gareth Nelson To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox-bounces@ietf.org, mmox@ietf.org, Jon Watte Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:36:07 -0000 A reference implementation is always a handy thing to have :) On Fri, Feb 27, 2009 at 1:32 AM, Meadhbh Hamrick (Infinity) wrote: > i don't think we get to mandate what code people implement the protocol in, > but i would certainly add lisp, smalltalk and occam to the list. > > seriously thought... remember... we're talking about a wire-protocol, not a > library that implements the protocol. > > On Feb 26, 2009, at 2:31 PM, Jon Watte wrote: > >> Gareth Nelson wrote: >>> >>> any code should be produced in. My vote is for python and C. >>> >> >> Let me vote for Lua and C++, and then the OpenSim people can vote for C# >> and Java and we have all the bases covered :-) >> >> >>> games are relevant (after all, MMORPGs for example are just huge >>> virtual worlds with game rules thrown in), I fail to see how networked >>> >> >> I think that's a common mis-conception. Most (almost all) MMOGs do not >> have much in the way of persistency, other than character possessions and >> stats. They also have a very static world, that generally does not allow >> users to move things around or place new things into the world. Finally, >> they do not support any form of UGC, which I think is more or less a >> requirement for a "real" virtual world. Lacking all three means that the >> technical job of implementing and running the MMORPG is much easier, but it >> also puts them on a lower rung of the expressiveness. A VW could express a >> MMORPG (with significant overhead compared to the MMORPG itself), but a >> MMORPG couldn't express a VW. >> >>> Practically everything people do online is "multiuser", and lots of >>> things are "massively multiuser" - look at any big site such as >>> wikipedia for example. >>> >>> >> >> "What is virtual worlds" has been a general question for a long time, but >> I believe the "rough consensus" answer is that it's at least: >> >> Interactive >> Persistent >> Identity Based >> Collaborative >> Supports UGC >> (controversial) Based on a 3D Simulation >> >> But, if we believe that we all need to agree on exactly what a virtual >> world is before we can make progress, experience shows we won't be able to >> make progress at all. >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > From infinity@lindenlab.com Thu Feb 26 18:04:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342D93A6BD2; Thu, 26 Feb 2009 18:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBc6diwi+CPE; Thu, 26 Feb 2009 18:04:24 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 650053A6BAA; Thu, 26 Feb 2009 18:04:24 -0800 (PST) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 464403DBC446; Thu, 26 Feb 2009 18:04:46 -0800 (PST) Message-Id: <13BD2212-5FC0-4F89-8DB9-53AA07F5FA4F@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Gareth Nelson In-Reply-To: <61dbdd7d0902261736o556ba122p3521581417bb95cf@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 26 Feb 2009 18:04:45 -0800 References: <49A7184D.3050602@gmail.com> <6CE24396-7167-4B37-A9AC-B1AA3CF7E7AF@lindenlab.com> <61dbdd7d0902261736o556ba122p3521581417bb95cf@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox-bounces@ietf.org, mmox@ietf.org, Jon Watte Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 02:04:25 -0000 yes, but a reference implementation is not a work item on the group's charter. and personally... ugh.. i've seen waaay too many times when specific implementation decisions for reference implementations were mistaken for protocol requirements and pain ensued. i even prefer the term "example code" instead of "reference implementation" for this reason. -cheers -meadhbh On Feb 26, 2009, at 5:36 PM, Gareth Nelson wrote: > A reference implementation is always a handy thing to have :) > > On Fri, Feb 27, 2009 at 1:32 AM, Meadhbh Hamrick (Infinity) > wrote: >> i don't think we get to mandate what code people implement the >> protocol in, >> but i would certainly add lisp, smalltalk and occam to the list. >> >> seriously thought... remember... we're talking about a wire- >> protocol, not a >> library that implements the protocol. >> >> On Feb 26, 2009, at 2:31 PM, Jon Watte wrote: >> >>> Gareth Nelson wrote: >>>> >>>> any code should be produced in. My vote is for python and C. >>>> >>> >>> Let me vote for Lua and C++, and then the OpenSim people can vote >>> for C# >>> and Java and we have all the bases covered :-) >>> >>> >>>> games are relevant (after all, MMORPGs for example are just huge >>>> virtual worlds with game rules thrown in), I fail to see how >>>> networked >>>> >>> >>> I think that's a common mis-conception. Most (almost all) MMOGs do >>> not >>> have much in the way of persistency, other than character >>> possessions and >>> stats. They also have a very static world, that generally does not >>> allow >>> users to move things around or place new things into the world. >>> Finally, >>> they do not support any form of UGC, which I think is more or less a >>> requirement for a "real" virtual world. Lacking all three means >>> that the >>> technical job of implementing and running the MMORPG is much >>> easier, but it >>> also puts them on a lower rung of the expressiveness. A VW could >>> express a >>> MMORPG (with significant overhead compared to the MMORPG itself), >>> but a >>> MMORPG couldn't express a VW. >>> >>>> Practically everything people do online is "multiuser", and lots of >>>> things are "massively multiuser" - look at any big site such as >>>> wikipedia for example. >>>> >>>> >>> >>> "What is virtual worlds" has been a general question for a long >>> time, but >>> I believe the "rough consensus" answer is that it's at least: >>> >>> Interactive >>> Persistent >>> Identity Based >>> Collaborative >>> Supports UGC >>> (controversial) Based on a 3D Simulation >>> >>> But, if we believe that we all need to agree on exactly what a >>> virtual >>> world is before we can make progress, experience shows we won't be >>> able to >>> make progress at all. >>> >>> Sincerely, >>> >>> jw >>> >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >> >> From dwl@us.ibm.com Thu Feb 26 18:43:13 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5CE28C225; Thu, 26 Feb 2009 18:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.061 X-Spam-Level: X-Spam-Status: No, score=-4.061 tagged_above=-999 required=5 tests=[AWL=-1.463, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9TBKhJ+RekY; Thu, 26 Feb 2009 18:43:12 -0800 (PST) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by core3.amsl.com (Postfix) with ESMTP id CA3873A68CD; Thu, 26 Feb 2009 18:43:11 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n1R2ZV4F006372; Thu, 26 Feb 2009 21:35:31 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n1R2hW7a181048; Thu, 26 Feb 2009 21:43:32 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n1R2hWEG026558; Thu, 26 Feb 2009 21:43:32 -0500 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n1R2hWkd026555; Thu, 26 Feb 2009 21:43:32 -0500 In-Reply-To: <13BD2212-5FC0-4F89-8DB9-53AA07F5FA4F@lindenlab.com> To: "Meadhbh Hamrick (Infinity)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David W Levine Date: Thu, 26 Feb 2009 21:43:33 -0500 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 02/26/2009 21:43:32, Serialize complete at 02/26/2009 21:43:32 Content-Type: multipart/alternative; boundary="=_alternative 000EF8C98525756A_=" Cc: mmox-bounces@ietf.org, mmox@ietf.org, Jon Watte Subject: Re: [mmox] MMOX: Strawman scope/goals/approach X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 02:43:13 -0000 This is a multipart message in MIME format. --=_alternative 000EF8C98525756A_= Content-Type: text/plain; charset="US-ASCII" The ITEF really doesn't do reference implementations. The bakeoff approach is sort of antithetical to a singular reference implementation. The bakeoff approach says "You need several to prove interoperability" and you validate the spec, based on how well they interoperate, collectively, not singurally. Now, of course, you sort out which ones don't meet the spec, and thus fail to interoperate, but.. you also look at the set of interoperating implementatoins, ont a singular one. mmox-bounces@ietf.org wrote on 02/26/2009 09:04:45 PM: > yes, but a reference implementation is not a work item on the group's > charter. > > and personally... ugh.. i've seen waaay too many times when specific > implementation decisions for reference implementations were mistaken > for protocol requirements and pain ensued. > > i even prefer the term "example code" instead of "reference > implementation" for this reason. > > -cheers > -meadhbh > > On Feb 26, 2009, at 5:36 PM, Gareth Nelson wrote: > > > A reference implementation is always a handy thing to have :) > > > > On Fri, Feb 27, 2009 at 1:32 AM, Meadhbh Hamrick (Infinity) > > wrote: > >> i don't think we get to mandate what code people implement the > >> protocol in, > >> but i would certainly add lisp, smalltalk and occam to the list. > >> > >> seriously thought... remember... we're talking about a wire- > >> protocol, not a > >> library that implements the protocol. > >> > >> On Feb 26, 2009, at 2:31 PM, Jon Watte wrote: > >> > >>> Gareth Nelson wrote: > >>>> > >>>> any code should be produced in. My vote is for python and C. > >>>> > >>> > >>> Let me vote for Lua and C++, and then the OpenSim people can vote > >>> for C# > >>> and Java and we have all the bases covered :-) > >>> > >>> > >>>> games are relevant (after all, MMORPGs for example are just huge > >>>> virtual worlds with game rules thrown in), I fail to see how > >>>> networked > >>>> > >>> > >>> I think that's a common mis-conception. Most (almost all) MMOGs do > >>> not > >>> have much in the way of persistency, other than character > >>> possessions and > >>> stats. They also have a very static world, that generally does not > >>> allow > >>> users to move things around or place new things into the world. > >>> Finally, > >>> they do not support any form of UGC, which I think is more or less a > >>> requirement for a "real" virtual world. Lacking all three means > >>> that the > >>> technical job of implementing and running the MMORPG is much > >>> easier, but it > >>> also puts them on a lower rung of the expressiveness. A VW could > >>> express a > >>> MMORPG (with significant overhead compared to the MMORPG itself), > >>> but a > >>> MMORPG couldn't express a VW. > >>> > >>>> Practically everything people do online is "multiuser", and lots of > >>>> things are "massively multiuser" - look at any big site such as > >>>> wikipedia for example. > >>>> > >>>> > >>> > >>> "What is virtual worlds" has been a general question for a long > >>> time, but > >>> I believe the "rough consensus" answer is that it's at least: > >>> > >>> Interactive > >>> Persistent > >>> Identity Based > >>> Collaborative > >>> Supports UGC > >>> (controversial) Based on a 3D Simulation > >>> > >>> But, if we believe that we all need to agree on exactly what a > >>> virtual > >>> world is before we can make progress, experience shows we won't be > >>> able to > >>> make progress at all. > >>> > >>> Sincerely, > >>> > >>> jw > >>> > >>> _______________________________________________ > >>> mmox mailing list > >>> mmox@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmox > >> > >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=_alternative 000EF8C98525756A_= Content-Type: text/html; charset="US-ASCII"
The ITEF really doesn't do reference implementations. The bakeoff approach is sort of antithetical to
a singular reference implementation. The bakeoff approach says "You need several to prove
interoperability" and you validate the spec, based on how well they interoperate, collectively, not
singurally. Now, of course, you sort out which ones don't meet the spec, and thus fail to interoperate,
but.. you also look at the set of interoperating implementatoins, ont a singular one.

mmox-bounces@ietf.org wrote on 02/26/2009 09:04:45 PM:

> yes, but a reference implementation is not a work item on the group's  
> charter.
>
> and personally... ugh.. i've seen waaay too many times when specific  
> implementation decisions for reference implementations were mistaken  
> for protocol requirements and pain ensued.
>
> i even prefer the term "example code" instead of "reference  
> implementation" for this reason.
>
> -cheers
> -meadhbh
>
> On Feb 26, 2009, at 5:36 PM, Gareth Nelson wrote:
>
> > A reference implementation is always a handy thing to have :)
> >
> > On Fri, Feb 27, 2009 at 1:32 AM, Meadhbh Hamrick (Infinity)
> > <infinity@lindenlab.com> wrote:
> >> i don't think we get to mandate what code people implement the  
> >> protocol in,
> >> but i would certainly add lisp, smalltalk and occam to the list.
> >>
> >> seriously thought... remember... we're talking about a wire-
> >> protocol, not a
> >> library that implements the protocol.
> >>
> >> On Feb 26, 2009, at 2:31 PM, Jon Watte wrote:
> >>
> >>> Gareth Nelson wrote:
> >>>>
> >>>> any code should be produced in. My vote is for python and C.
> >>>>
> >>>
> >>> Let me vote for Lua and C++, and then the OpenSim people can vote  
> >>> for C#
> >>> and Java and we have all the bases covered :-)
> >>>
> >>>
> >>>> games are relevant (after all, MMORPGs for example are just huge
> >>>> virtual worlds with game rules thrown in), I fail to see how  
> >>>> networked
> >>>>
> >>>
> >>> I think that's a common mis-conception. Most (almost all) MMOGs do  
> >>> not
> >>> have much in the way of persistency, other than character  
> >>> possessions and
> >>> stats. They also have a very static world, that generally does not  
> >>> allow
> >>> users to move things around or place new things into the world.  
> >>> Finally,
> >>> they do not support any form of UGC, which I think is more or less a
> >>> requirement for a "real" virtual world. Lacking all three means  
> >>> that the
> >>> technical job of implementing and running the MMORPG is much  
> >>> easier, but it
> >>> also puts them on a lower rung of the expressiveness. A VW could  
> >>> express a
> >>> MMORPG (with significant overhead compared to the MMORPG itself),  
> >>> but a
> >>> MMORPG couldn't express a VW.
> >>>
> >>>> Practically everything people do online is "multiuser", and lots of
> >>>> things are "massively multiuser" - look at any big site such as
> >>>> wikipedia for example.
> >>>>
> >>>>
> >>>
> >>> "What is virtual worlds" has been a general question for a long  
> >>> time, but
> >>> I believe the "rough consensus" answer is that it's at least:
> >>>
> >>> Interactive
> >>> Persistent
> >>> Identity Based
> >>> Collaborative
> >>> Supports UGC
> >>> (controversial) Based on a 3D Simulation
> >>>
> >>> But, if we believe that we all need to agree on exactly what a  
> >>> virtual
> >>> world is before we can make progress, experience shows we won't be  
> >>> able to
> >>> make progress at all.
> >>>
> >>> Sincerely,
> >>>
> >>> jw
> >>>
> >>> _______________________________________________
> >>> mmox mailing list
> >>> mmox@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/mmox
> >>
> >>
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
 --=_alternative 000EF8C98525756A_=-- From MysticalDemina@xrgrid.com Thu Feb 26 18:49:57 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3E828C1F3 for ; Thu, 26 Feb 2009 18:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PR2Yz5Fur+II for ; Thu, 26 Feb 2009 18:49:56 -0800 (PST) Received: from k2smtpout05-01.prod.mesa1.secureserver.net (k2smtpout05-01.prod.mesa1.secureserver.net [64.202.189.56]) by core3.amsl.com (Postfix) with SMTP id 044A028C25C for ; Thu, 26 Feb 2009 18:49:55 -0800 (PST) Received: (qmail 26772 invoked from network); 27 Feb 2009 02:50:17 -0000 Received: from unknown (HELO TWEEDY001.kevin-tweedy.com) (68.178.225.179) by k2smtpout05-01.prod.mesa1.secureserver.net (64.202.189.56) with ESMTP; 27 Feb 2009 02:50:17 -0000 Received: from KEVINPC ([173.49.10.182]) by kevin-tweedy.com with MailEnable ESMTP; Thu, 26 Feb 2009 19:50:26 -0700 From: "Mystical Demina" To: References: <49A736AA.2020205@gmail.com> <4EC4C999-59E9-49BF-99C0-82ED4BBD9A64@lindenlab.com> In-Reply-To: <4EC4C999-59E9-49BF-99C0-82ED4BBD9A64@lindenlab.com> Date: Thu, 26 Feb 2009 21:50:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmYeRlR4HF4AjvhTS6qFdfH9HK+nQAAVVfw X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Subject: Re: [mmox] Use cases? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 02:49:57 -0000 I think there are a lot of people that would like to contribute to these discussions but don't understand the methodology that is being used so we don't know when to submit comments into the process. What I would expect is something like Unified Process where this is a Strategic Plan Phase, a Tactical Plan Phase, an Implementation Phase and a Transition Phase. How could that apply to this initiative is maybe something like this. 1. Strategic Plan Phase Define the over all charter. But I would suggest keeping it high level in the direction of something like "creating protocols and standards that let dispersed clients and servers integrated across a supply chain of various industries". Define the stake holders and layout the high level business processes that are in this domain. Identify limitations of the current 3D environments, the big wish list from all the different stakeholders. I also think a lot of input we need to get will not come from virtual world providers but from industry leaders related to situations that this technology could help. Everything from improved schooling of 3rd world countries to designing a city, or building a ship or planning the next space station on mars. These are the problems that the virtual world technology needs to address if we are going to be more than a form of entertainment but instead the next generation internet platform for doing business. 2. Tactical Plan Phase The tactical phases needs to takes this wish list of features and capabilities and group them, segment them, organize them into use cases, domain model basically identifying all the nouns and verbs related to providing this supply chain. It then needs to drill down these use cases in enough details that really defines the problems we need to solve, the order that they needs to be solved in. 3. Implementation Phase For each of these use cases have a period for of request for comments where people that wish to submit ideas and designs, existing standards. I can see this phase being a big deal and take some time. All of these submittals need to be against specific problems. Then these need to be taken and ranked by some kind of sub committees to create something that can be voted on or how ever the standard comes to final stages. 4. Transition Phase In this phase each of the use cases are matched against the designs, final drafts are made and published. People make final edits. Voting is done and a final draft of a standard is produced. Really seems a wiki setup with with reviewers may be a good way to do this. So this is a quit presentation to get an idea across. So to be honest I don't understand these commits below. I don't know of any system, standards or plans that don't on a large scale that are ever accomplished with out first understanding the process that is going to be used to accomplish the goals. So what I am afraid of is that the problem for this initiative is bigger than the charter and is more in grained in what is the methodology that will be used to accomplish the goals of the group. I really salute Jon on starting a set of uses cases and hope that he doesn't give up on them. If we aren't going to follow some kind of methodology then I think for me I probably will drop the group and not spend the time reading these emails. I guess there are others that feel this way too. If there is a defined methodology for this group please send me the link I would like to read it and understand how participation is suppose to work. Meanwhile let me share a few a use case as food for thought. I spent several years during the first internet boom working in the maritime transportation supply chain, basically the interaction between oil traders, charters, vessel owners, port agents, terminal operations, various services at the port, supplies, financing, insurance, all these players that are part of the supply chain to move oil from point A to point B. Took 6 weeks just to document the supply chain and to make a list of opportunities on how the internet could help them work together better. So now we have virtual worlds and as I look into this problem space and say how virtual worlds could help them do their business better. I see lots of opportunities. First there are tons of difference kinds of vessels and to learn them all takes time. I can see opportunities for these vessels to be created in 3D spaces where people can get a real life look at them and when talking about them can understand the details and location on the ship. Ports have lots of various layouts, risk and issues. I see an opportunity for mirrored virtual worlds of ports. Terminals have lots of different configurations and issues. There are tug boats, fueling vessels, loading vessels. So let's say we could render all of this up into 3D. It would be lots of different companies need to share objects, link together real time data like locations of vessels. Staff from different locations would need to be able to teleport into different locations to look at stuff. There would have to be integration with legacy systems in bound and out bound. I could call them tomorrow and talk to them about this but I don't think I could sell it because there isn't a standard yet that they could invest in for al the parts to talk together. They can't call up one of their partners and say if you implement this we will do it too. I know someone will say we need a protocol for these to talk together, so let's define a protocol. If so I would say we don't have the right leadership in this group and it will fail. I think starting with a wire protocol to solving how a supply chain works together is doomed process. These are the kind of problems I would like to solve. I hope they are what the group would like to solve too. I would like to participate in a constructive manner to solve this kind of problem. I hope the group can let me know how I can do that. Kevin Tweedy SL: Mystical Demina http://www.XRGrid.com -----Original Message----- From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of Meadhbh Hamrick (Infinity) Sent: Thursday, February 26, 2009 8:17 PM To: Jon Watte Cc: mmox@ietf.org Subject: Re: [mmox] Use cases? well... yes and no... use cases are important. but to prevent feature creep having a charter + a concrete proposal is always convenient. our charter is under discussion and is therefore at least "plastic" if not "fluid." but yes. if i had it to do over, i would have published as much of OGP as we currently have defined along with LLSD as it's the application level that ultimately will be more interesting. -cheers -meadhbh On Feb 26, 2009, at 4:41 PM, Jon Watte wrote: > I posted five use cases that I think cover a fair range of virtual > world interoperability. I've gotten several nice replies in the > mail, but on the list they seem to have soared like a lead balloon, > as opposed to all talk about XML vs binary vs IP property rights. > Surely, agreeing on requirements (such as use cases) is actually > more important than discussing implementation details that we don't > even know will apply yet? > > Any opinions, for or against, regarding these use cases? Silent > assent? > > http://www.interopworld.org/mmox-use-cases > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox From belxjander@gmail.com Thu Feb 26 20:29:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284173A6BF6 for ; Thu, 26 Feb 2009 20:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep4etPtvPomA for ; Thu, 26 Feb 2009 20:29:22 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id 2ED3F3A6B45 for ; Thu, 26 Feb 2009 20:29:21 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so838899ana.4 for ; Thu, 26 Feb 2009 20:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=yDsttmLeiAxUf558ZlgVRm+/SRB3fFAcfNXHTROusSc=; b=cXmyqt0H4VAPbrP/aVPvr0/DYigi7q6syku/xsahUZdSCLoR9pQg0VK5yON2ZBkes7 d3MMXAXPqaxMnIXJlRp3uKNfUFDEwY4dW0dGo0+ZB3QQcWVmkLiftvap/cgfT+C7QMaV z7KpFcJMSzphPpMV5jXwQ6qfyKQjKL2BY3SXw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=PfRkd2sMH3df6JXXHm2jzjmSmEwOZ3f89rPfdeLAVCEj/cEvt8Dx3Xmeb4wstycE7D OIRitRVu2TOwBoETfpv29Th+EinIdY8ZJ6UoQMoRtrra8hxzSmvdWE0dUAL8+dcSJZHt qx07OQ2lMrEWMepqwfdR1rSR9Z/UpJv/RUeI8= Received: by 10.142.58.20 with SMTP id g20mr1061926wfa.1.1235708983178; Thu, 26 Feb 2009 20:29:43 -0800 (PST) Received: from ?10.2.1.3? (p3159-ipbfp201tottori.tottori.ocn.ne.jp [122.21.102.159]) by mx.google.com with ESMTPS id 32sm7260251wfa.20.2009.02.26.20.29.41 (version=SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 20:29:42 -0800 (PST) From: Kajikawa Jeremy To: Heiner Wolf In-Reply-To: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9wpCNPgohaG+atZH63eO" Date: Fri, 27 Feb 2009 13:24:19 +0900 Message-Id: <1235708659.6595.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: "mmox@ietf.org" Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 04:29:23 -0000 --=-9wpCNPgohaG+atZH63eO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable this is the type of material I am considering in my own plans... and I am considering Object Vector updates being applicable as well as how to divorce an object being represented from the active scripting enabling extended functionality. Ive already got something in mind towards a LOT of this material but getting beyond documenting it in my own scrawled notes is the part where I am slow Jeremy On Wed, 2009-02-25 at 22:09 +0100, Heiner Wolf wrote: > Hi, >=20 > I understand that the original intention was to make OGP public and > get comments. But if that's the purpose you probably should call the > WG OGP. >=20 > We had a similar situation in the Instant Message and Presence WG, > where several vendors tried to talk about "their" protocol. Lisa > probably remembers. The situation was solved by chartering the IMPP WG > to create only requirements, then 2 new WGs worked on "their" protocol > (SIMPLE, XMPP). I bet we get a similar discussion. Maybe MMOX should > define requirements and an OGP WG may then work on the OGP way later. > This gives time for other developers to speak up and add learnings > from "their" worlds and protocols. Do we have people from Everquest, > WoW, There, EVE Online, Runescape, Google Earth here? We need them for > something thats called MMOX. We should give them time to speak up. >=20 > BTW: we are building a virtual world based on XMPP chat rooms. There > are more, like IMVU, which use chat protocols for their virtual > worlds. The chat room is what you would call a region domain. >=20 > This is quite a different angle, but an interesting one, because the > transport protocol is very simple and has few extensions.The > extensions carry the 3D stuff. An interesting feature of worlds which > are based on chat protocols is, that there is low in-band traffic. The > reason is, that off the shelf chat servers are not build for heavy > traffic. So, only notifications are transferrred in the chat protocol. > Assets use a separate data access protocol, usually HTTP. >=20 > This simplistic view of people who use chat protocols for virtual > worlds could be useful in identifying "what you really need" for a VW > interop protocol. >=20 > hw --=-9wpCNPgohaG+atZH63eO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJp2rzAAoJECHrKutFYVwTw7cQAMU5sqRAvYayxgCR2rd54U2W x/mv3Nd6QirNE5mLxZRWeRa8+wYEVUajHjBkZ54XXET69jU2G5cIzpODErMIbQsB meIV10IPlgTPg9lel1PsclNZoGm815ljO85E/KW+PMVRMEgh5+d9+Me9VozCTEle qrtncyLYulBU0oPFMfBMcY2L1tmKqaNcMiWFv4h+CqU5yUM+VKi8ZEtF3l4tXxE6 4Vg0EHAggoHngzY4Gmz4uHyWR56oRLU5kd/828hnzSl+21BI9F+YldfqGWB/IUAH SbXyJizXv2mbe2ug6vR6mzoSA3wDf19yJO7qwwrs1JSkY68do+g8+gSCTGsxAv7P Pw/qy3yFJr+yReDZ268B8uVunhgZ3ig0W+rTNs81gPYRyZj3dEBQJazhSSKgsii7 Jy/Abex97ENqLFo8vl6kRlggdrYdZ03NDsrTQB3P/ba8o/L0H18HuCi35gI+XLFa uCKGlVYClxj3xwJZXc0M446fdSwSxGddiR9Bqf1KkLuYgtq2o9T/NraBbXV07W3K bBgs831ug4MEiVnXfqustaGCOPlq9W+UAjpUsSxrg2xA9ToN+FJm+aNmlAAiZTmc 0TR2ArNDyBedenjDY5CSc0UtLPoYtNsfCuLNWZ01IRZnkmHrnwaksKo24ykhgSwO 2uvbKdO8U+aYTxFp9CFc =NTr/ -----END PGP SIGNATURE----- --=-9wpCNPgohaG+atZH63eO-- From jwatte@gmail.com Thu Feb 26 21:29:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E3C28C35F for ; Thu, 26 Feb 2009 21:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhL6NQMv7JMI for ; Thu, 26 Feb 2009 21:29:43 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.236]) by core3.amsl.com (Postfix) with ESMTP id 615DD28C35D for ; Thu, 26 Feb 2009 21:29:43 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id g9so3942784rvb.5 for ; Thu, 26 Feb 2009 21:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=M+I13bIQNOdX2dTB/hZJAdxJjOXVYwif3q1z65cKp1Q=; b=HCQmK1KF2Myjx3gKNu6Z6vP+ulnGd1EZYUtu52BT9Pp7ruvYYukVeD6MCm+gMlYQws NdB26Aw+WrFmlxWr5ecCtwj4JMFr++58bSKixZVzMHXd7+8WrOL3en5jJpBx+/jXf3rF qmyxxPO62Cy6liDEKf3kEAx9nesVPqGdjTacc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=H5VpZmBXRWnHGjVvaAT3NsmcltJxxeA8JuDY+zPHDkALsZosD2qm9vKwyv27WT++2H xQ1i9SNG82a5P6yyuhoCiZ7kqpIgLQPGmXnCeNtvXxEV7MjPsjYK1Wt4BDss3969MA5p NItXcC+2ImKUsyca5boOPBpIBX6hs379ov58I= Received: by 10.141.36.10 with SMTP id o10mr1007817rvj.237.1235712605439; Thu, 26 Feb 2009 21:30:05 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b39sm2958993rvf.9.2009.02.26.21.30.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 26 Feb 2009 21:30:05 -0800 (PST) Message-ID: <49A77A5B.7090009@gmail.com> Date: Thu, 26 Feb 2009 21:30:03 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Mystical Demina References: <49A736AA.2020205@gmail.com> <4EC4C999-59E9-49BF-99C0-82ED4BBD9A64@lindenlab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Use cases? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 05:29:44 -0000 Mystical Demina wrote: > internet could help them work together better. So now we have virtual > worlds and as I look into this problem space and say how virtual worlds > could help them do their business better. I see lots of opportunities. > First there are tons of difference kinds of vessels and to learn them all > takes time. I can see opportunities for these vessels to be created in 3D > spaces where people can get a real life look at them and when talking about > them can understand the details and location on the ship. Ports have lots > of various layouts, risk and issues. I see an opportunity for mirrored > virtual worlds of ports. Terminals have lots of different configurations > and issues. There are tug boats, fueling vessels, loading vessels. So > So far, what you are describing a specific application (not unlike some pitches that we've heard at Forterra, btw -- I guess the business you're in really might benefit from virtual worlds technology). Specific applications might be good as example input into a standardization process, but should not be the single driving factor behind such a process. > let's say we could render all of this up into 3D. It would be lots of > different companies need to share objects, link together real time data like > locations of vessels. Staff from different locations would need to be able > to teleport into different locations to look at stuff. There would have to > be integration with legacy systems in bound and out bound. I could call > I think it would be really valuable if you could re-work that into some concrete use cases, from which requirements can be gathered. Do you think that would be possible? > I know someone will say we need a protocol for these to talk together, so > let's define a protocol. If so I would say we don't have the right > leadership in this group and it will fail. I think starting with a wire > protocol to solving how a supply chain works together is doomed process. > I think the reason we're saying that a protocol is needed is because we do know that a protocol must be needed. These are computers. They talk over a network. That happens through protocols. Once there is some form of standard protocol, a business built on standardization can take off, but the business can't come first, because there would be no "there" there. Consider the work you did where you made the different pieces work together through the Internet. You couldn't have done that, had there not already been an Internet. The Internet runs on IP, and TCP, and BGP, and DNS, and a large number of other protocols. Had those not already been there, your Internet-based business process improvement could not have happened. That being said, I believe that business process input into the requirements is both valuable and necessary. Personally, I have already seen that kind of input from several customers and partners that I work with in daily life, and that's why I'm here -- I have, internally, synthesized the requirements I hear from parts of Federal Government, Enterprise IT, Healthcare, Web Collaboration, Education, Non-profits and other organizations, and even the Entertainment space in the form of our PG-13, white-label partners at Makena. I have, internally, worked that up into use cases (some of the most illustrative of which I've posted in the previous thread). I have then, internally, knowing of the technology of a large number of systems (not just "mine"), come up with an approach that I believe delivers the most "bang" for the least "buck" in terms of solving actual customer requirements. Of course, that's all internal to me, and not only can't you read my mind, you have no particular reason to trust my particular judgement. If we can collect a bigger set of requirements and inputs from the users who will benefit, that would be just great! Sincerely, jw From MysticalDemina@xrgrid.com Thu Feb 26 22:50:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4B53A6908 for ; Thu, 26 Feb 2009 22:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWfMvR3KmKmq for ; Thu, 26 Feb 2009 22:50:07 -0800 (PST) Received: from k2smtpout03-01.prod.mesa1.secureserver.net (k2smtpout03-01.prod.mesa1.secureserver.net [64.202.189.171]) by core3.amsl.com (Postfix) with SMTP id 12CE83A63D3 for ; Thu, 26 Feb 2009 22:50:07 -0800 (PST) Received: (qmail 9817 invoked from network); 27 Feb 2009 06:50:28 -0000 Received: from unknown (HELO TWEEDY001.kevin-tweedy.com) (68.178.225.179) by k2smtpout03-01.prod.mesa1.secureserver.net (64.202.189.171) with ESMTP; 27 Feb 2009 06:50:28 -0000 Received: from KEVINPC ([173.49.10.182]) by kevin-tweedy.com with MailEnable ESMTP; Thu, 26 Feb 2009 23:50:37 -0700 From: "Mystical Demina" To: "'Jon Watte'" References: <49A736AA.2020205@gmail.com> <4EC4C999-59E9-49BF-99C0-82ED4BBD9A64@lindenlab.com> <49A77A5B.7090009@gmail.com> In-Reply-To: <49A77A5B.7090009@gmail.com> Date: Fri, 27 Feb 2009 01:50:11 -0500 Message-ID: <5EDB00341A5544F896EECB6D12AC21D5@KEVINPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Thread-Index: AcmYnHh0x3GI7tUoSFqmJkO38x4k9gACtTAA Cc: mmox@ietf.org Subject: Re: [mmox] Use cases? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 06:50:12 -0000 It take a few days, will try to have something early next week. >-----Original Message----- >From: Jon Watte [mailto:jwatte@gmail.com] >Sent: Friday, February 27, 2009 12:30 AM >To: Mystical Demina >Cc: mmox@ietf.org >Subject: Re: [mmox] Use cases? > > >> let's say we could render all of this up into 3D. It would be lots of >> different companies need to share objects, link together real time data >like >> locations of vessels. Staff from different locations would need to be >able >> to teleport into different locations to look at stuff. There would have >to >> be integration with legacy systems in bound and out bound. I could call >> >Jon Watte wrote: >I think it would be really valuable if you could re-work that into some >concrete use cases, from which requirements can be gathered. Do you >think that would be possible? From Chris.Down@alcor.co.uk Fri Feb 27 01:34:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEDF13A6AC3 for ; Fri, 27 Feb 2009 01:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hO2chps5VgZ for ; Fri, 27 Feb 2009 01:34:31 -0800 (PST) Received: from merak.alcor.co.uk (merak.alcor.co.uk [217.155.59.205]) by core3.amsl.com (Postfix) with ESMTP id CA74B3A6980 for ; Fri, 27 Feb 2009 01:34:30 -0800 (PST) Received: from sirius.alcor.co.uk ([192.168.1.2]) by merak.alcor.co.uk with esmtp (Exim 4.69) (envelope-from ) id 1Lcz7K-0000Pa-1i for mmox@ietf.org; Fri, 27 Feb 2009 09:34:50 +0000 Message-ID: <49A7B3E3.8050703@alcor.co.uk> Date: Fri, 27 Feb 2009 09:35:31 +0000 From: Chris Down User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090226 Lightning/1.0pre Shredder/3.0b3pre MIME-Version: 1.0 To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 09:34:31 -0000 On 26/02/2009 22:33, dyerbrookme@juno.com wrote: > Once you change this to "Experience Space for Logged-on Entities in Persistent Viewing Zones with Transmissable Data" you are well on the way to -- well, some sort of ism or another, perhaps communism, perhaps Extropianism. This list is not a platform for your extreme political views. A lot of emails you send infer that anyone or anything that opposes your views are communist. This sort of rhetoric does nothing to help establish the MMOX standards. It is an annoying distraction and in fact it puts people off getting involved. This is not bait for you to call me a communist, because I assure you I am not. It is a suggestion that you avoid "politicalisms" and put forward your suggestions in a logical manner and thenm people would take notice of them. Regards Chris Down From morgaine.dinova@googlemail.com Fri Feb 27 01:40:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15A933A6B13 for ; Fri, 27 Feb 2009 01:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAcVHAaJdkLd for ; Fri, 27 Feb 2009 01:40:12 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 6D7143A6AEB for ; Fri, 27 Feb 2009 01:40:11 -0800 (PST) Received: by fxm24 with SMTP id 24so950565fxm.37 for ; Fri, 27 Feb 2009 01:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=FbvgdTkmaZ5BJa/2L40p4dVr88qu8/K9N1lRWzU6i/w=; b=ezAcfy0UrdZ1zf3EOGLZMP6s30oj/JWAFlgyFHzyFEZVaMisEpefBM8ItfhosViTkH jsZpd4xsRGgItS1s2IK1kj9ooxUWBeRaogpjbWyTJ2Za/IkuzAdLZeCv9Uuf7TNjvf1s kLycnuJN4ih90BYz3G2GeZPwhqfcC9sOrFaLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=p+Je0kiGGaLEkfYmAIXSCw43pDG7rfdxnvySLq3KIITs4RT7PEN+BC6r1Fy3WK9CXb t2YaIiwB56RLJ7sPXUAi9veO+WWpTd6ynMAbzJiS7djQXuay4T+dr2uvog4OA6Nf0W3X IBLLeFm/lYje1cVg1U0Zq46AilUMlVQlfR1n4= MIME-Version: 1.0 Received: by 10.181.22.15 with SMTP id z15mr807442bki.48.1235727632737; Fri, 27 Feb 2009 01:40:32 -0800 (PST) In-Reply-To: <7D208FA9-3C91-422F-B24F-F1B0B85908B9@lindenlab.com> References: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com> <7D208FA9-3C91-422F-B24F-F1B0B85908B9@lindenlab.com> Date: Fri, 27 Feb 2009 09:40:32 +0000 Message-ID: From: Morgaine To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=001636c5bf4496a70d0463e34248 Cc: mmox@ietf.org Subject: Re: [mmox] what does it mean to be interoperable? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 09:40:14 -0000 --001636c5bf4496a70d0463e34248 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Feb 26, 2009 at 10:26 PM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: why would MMOX be limited to pursuing only OGP if we want to define OGP in a > standards body? > Nobody said "*MMOX [would] be limited to pursuing only OGP if we want to define OGP in a standards body*", so it's not an argument you get to knock down. Quite the opposite is true. MMOX would *NOT* be limited to pursuing only OGP if the "OGP-only" work were being done in an OGP workgroup. The MMOX group would then be free to pursue the broad interop implied in the "MMOX" name and affirmed by many MMOX posts. In contrast, conflating the two goals (both of them very worthy) is causing a lot of conflict, and we could avoid that with some honest workgroup naming. > > > maybe we _should_ re-charter with a more OGP-centric view and pursue > interoperability option 5, but this would effectively move any OLIVE > standardization effort into a different WG, and with two different VW > "regimes," interop options 1 and 2 would be impossible. JW spoke in support > of option 4.5 (which yes, has the same intent as what i was going for with > option 4.) > Re-chartering MMOX to be OGP-only would be a less than upstanding attempt to acquire the generic "MMOX" label for a technology that is clearly not vendor-neutral. It would inherently exclude all participants who have strong interest in MMO interop but no interest at all in the SL model. It would also conflict with the numerous statements made on this list about the broad aspirations of the group. OGP-only work should be labelled "OGP", that would be honest and helpful. > > in short, we expect OGP to never be a complete specification of a virtual > world protocol, but rather a protocol framework that together with an > interoperability profile sufficiently specifies client and server behavior > to achieve some measure of interoperability. > > > Excellent, there is *HUGE* merit in that, which is why I would support such OGP-oriented work directly and avidly. But it should be done in an "OGP" workgroup so that there is clear understanding that the work is devoted to one particular implementation and does not seek to embrace the world diversity (and implementation diversity) of "MMOX". I'm just trying to give everybody the elbow room to be able to work productively. Saying that the goal is broad VW interop while simultaneously requiring the MMOX group to use the SL model is not a recipe for effective group cooperation. Morgaine. On Thu, Feb 26, 2009 at 10:26 PM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > why would MMOX be limited to pursuing only OGP if we want to define OGP in > a standards body? > POP3 and IMAP are both defined in RFCs, after all. ( though i believe they > did come out of different working groups ) > > maybe we _should_ re-charter with a more OGP-centric view and pursue > interoperability option 5, but this would effectively move any OLIVE > standardization effort into a different WG, and with two different VW > "regimes," interop options 1 and 2 would be impossible. JW spoke in support > of option 4.5 (which yes, has the same intent as what i was going for with > option 4.) > > i don't know if linden could ever support an option-4, because of our > desire to have interoperability drive "user innovation." in other words, > we'll always be interested in a situation where developers could extend the > protocol to support value-added services. we're not terribly frightened of > option-5 because our view of the world has VW operators deploying client > software unique to their solution to handle these value-added services. > > in short, we expect OGP to never be a complete specification of a virtual > world protocol, but rather a protocol framework that together with an > interoperability profile sufficiently specifies client and server behavior > to achieve some measure of interoperability. > > On Feb 26, 2009, at 1:58 PM, Morgaine wrote: > > On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick < > infinity@lindenlab.com> wrote: > >> >> 5. interoperability means some virtual worlds use some of the same >> protocols, without a universal client >> ... >> personally.. i'm kind of interested in option 5. > > > > Options 5 is a perfectly good option for a workgroup formed around the > common goal of implementing some specific protocols in a similarly-focused > group. As you pointed out in your paragraph that I quoted concerning > "taxonomy of topics", > the protocols which you intend to use are those based on the OGP model. > This sounds like an excellent thing to tackle, in an OGP workgroup. I would > look forward to that work, as it would undoubtedly help advance interop > between SL-like worlds. Furthermore, the workgroup name and charter would > honestly reflect the intent, allowing participants interested in such a goal > to work productively with helpful consensus. > > In contrast, as pointed out by our co-chair under "Charter, Scope, > Activities"and in even more detail under "Strawman > scope/goals/approach", > the goals and intent of MMOX are very different to the above, and the name > of the group reinforces that. The narrow scope of Option 5 and the specific > focus on LL technologies doesn't come anwhere near the catchment area that > MMOX participants have been discussing. > > I think that both of the above are worthy goals to be handled under the > aegis of the IETF. But work on OGP is hampered by the very clear fact that > MMOX discussions and requirements are far broader and can't be forced into > an a priori straightjacket. By the same token, work on MMOX is likewise > being hampered by a narrow focus on near-term Linden goals. > > This is why I am trying to find an approach that will allow both groups of > interests to be successful and productive. Currently there is little > commonality owing to the gulf between the actual narrow intent stated in > your "taxonomy of topics" and the very much broader goals of MMOX. > > > Morgaine. > > > > > > > > On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick < > infinity@lindenlab.com> wrote: > >> so it seems clear we all have different ideas of what it means to be >> interoperable. >> >> i thought i might try to define a couple of the definitions i think i've >> seen people use: >> >> 1. interoperability means all virtual worlds, wherever they are, may be >> accessed via a single unified client. >> >> 2. interoperability means all virtual worlds, wherever they are, use >> precisely the same protocol(s) and all virtual worlds represent data in >> formats understandable by all other virtual worlds, with a universal client. >> >> 3. interoperability means some virtual worlds may be accessed via a single >> unified client. >> >> 4. interoperability means some virtual worlds use precisely the same >> protocol(s) and all virtual worlds represent data in formats understandable >> by all other virtual worlds, without a universal client. >> >> 5. interoperability means some virtual worlds use some of the same >> protocols, without a universal client >> >> 6. interoperability means the "model" is the same, but with different >> protocols that may be bridged with protocol gateways. >> >> it seems to me that many of us are using different descriptions for the >> word "interoperable" and it's causing mild discord and at least a couple >> instances of us talking past each other. >> >> personally.. i'm kind of interested in option 5. it has the benefit of >> producing a protocol that is identifiable by routers, network management >> software, etc. it also provides a "slowly moving target" for open source >> developers (as opposed to the "fast moving target" of linden's existing >> protocol(s)). by making it public, VW operators can choose whether or not >> they wish to implement it. it also doesn't require VW operators to implement >> it (as if we could anyway) and it allows VW operators to avoid having to >> test interoperability with every other virtual world. >> >> but it's not without drawbacks... this model can lead to a "MOSS-like" >> environment. (for those of you who don't remember MOSS or MIME Object(?) >> Security Services... it was a response to the drawbacks of PEM (privacy >> enhanced mail) which had a relative paucity of encryption options. but IMHO, >> MOSS introduced so many options that it was VERY easy for two >> implementations to adhere to the spec, but not actually be interoperable.) >> >> so... i recommend that if we (as a group) wanted to pursue option-5.. we >> also explicitly define what goes in an "interoperability profile." that way >> you could get the benefit of having a relatively stable protocol that could >> be targeted by open source developers which could be used by VW operators to >> help make client / server apps. >> >> VW operators could publish their "interoperability profile" to tell people >> who wanted to build tools, extra services, or interoperable worlds what >> options would be available and how they would work. >> >> -cheers >> -m >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > > --001636c5bf4496a70d0463e34248 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Feb 26, 2009 at 10:26 PM, Meadhbh Hamric= k (Infinity) <infinity@lindenlab.com> wrote:

why would MMOX be limited to pursuing only OGP if we want t= o define OGP in a standards body?

Nobody said &q= uot;MMOX [would] be limited to pursuing only OGP if we want to define OG= P in a standards body", so it's not an argument you get to kno= ck down.

Quite the opposite is true.=A0 MMOX would NOT be limited to purs= uing only OGP if the "OGP-only" work were being done in an OGP wo= rkgroup.=A0 The MMOX group would then be free to pursue the broad interop i= mplied in the "MMOX" name and affirmed by many MMOX posts.=A0 In = contrast, conflating the two goals (both of them very worthy) is causing a = lot of conflict, and we could avoid that with some honest workgroup naming.=


maybe we _should_ re-charter with a more OGP-centric view and pursue interoperability option 5, but this would effectively move any OLIVE standardization effort into a different WG, and with two different VW "regimes," interop options 1 and 2 would be impossible. JW spoke = in support of option 4.5 (which yes, has the same intent as what i was going for with option 4.)


R= e-chartering MMOX to be OGP-only would be a less than upstanding attempt to= acquire the generic "MMOX" label for a technology that is clearl= y not vendor-neutral.=A0 It would inherently exclude all participants who h= ave strong interest in MMO interop but no interest at all in the SL model.= =A0 It would also conflict with the numerous statements made on this list a= bout the broad aspirations of the group.=A0 OGP-only work should be labelle= d "OGP", that would be honest and helpful.

=A0

in short, we expect OGP to never be a complete specification of a virtual world protocol, but rather a protocol framework that together with an interoperability profile sufficiently specifies client and server behavior to achieve some measure of interoperability.

=A0
Excellent, th= ere is HUGE merit in that, which is why I would support such OGP-ori= ented work directly and avidly.=A0 But it should be done in an "OGP&qu= ot; workgroup so that there is clear understanding that the work is devoted= to one particular implementation and does not seek to embrace the world di= versity (and implementation diversity) of "MMOX".

I'm just trying to give everybody the elbow room to be able to work= productively.=A0 Saying that the goal is broad VW interop while simultaneo= usly requiring the MMOX group to use the SL model is not a recipe for effec= tive group cooperation.


Morgaine.








On Thu, Feb 26, 2009 at 10:26 PM, Meadhbh Hamrick (Infinit= y) <infinity= @lindenlab.com> wrote:
w= hy would MMOX be limited to pursuing only OGP if we want to define OGP in a= standards body?

POP3 and IMAP are both defined in RFCs, after all. ( though = i believe they did come out of different working groups )

maybe we _should_ re-charter with a more OGP-centric view and pursu= e interoperability option 5, but this would effectively move any OLIVE stan= dardization effort into a different WG, and with two different VW "reg= imes," interop options 1 and 2 would be impossible. JW spoke in suppor= t of option 4.5 (which yes, has the same intent as what i was going for wit= h option 4.)

i don't know if linden could ever support an option= -4, because of our desire to have interoperability drive "user innovat= ion." in other words, we'll always be interested in a situation wh= ere developers could extend the protocol to support value-added services. w= e're not terribly frightened of option-5 because our view of the world = has VW operators deploying client software unique to their solution to hand= le these value-added services.

in short, we expect OGP to never be a complete specific= ation of a virtual world protocol, but rather a protocol framework that tog= ether with an interoperability profile sufficiently specifies client and se= rver behavior to achieve some measure of interoperability.

On Feb = 26, 2009, at 1:58 PM, Morgaine wrote:

On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh = Hamrick <infinity@lindenlab.com> wrote:

5. interope= rability means some virtual worlds use some of the same protocols, without = a universal client
...
personally.. i'm kind of interested in option 5.
<= div>

Options 5 is a perfectly good option for a workgroup formed aro= und the common goal of implementing some specific protocols in a similarly-= focused group.=A0 As you pointed out in your paragraph t= hat I quoted concerning "taxonomy of topics", the protocols w= hich you intend to use are those based on the OGP model.=A0 This sounds lik= e an excellent thing to tackle, in an OGP workgroup.=A0 I would look forwar= d to that work, as it would undoubtedly help advance interop between SL-lik= e worlds.=A0 Furthermore, the workgroup name and charter would honestly ref= lect the intent, allowing participants interested in such a goal to work pr= oductively with helpful consensus.

In contrast, as pointed out by our co-chair under &= quot;Charter, Scope, Activities" and in even more detail under "Strawman scope/goals/approach", the goals an= d intent of MMOX are very different to the above, and the name of the group reinforces that.=A0 The narrow scope = of Option 5 and the specific focus on LL technologies doesn't come anwh= ere near the catchment area that MMOX participants have been discussing.

I think that both of the above are worthy goals to = be handled under the aegis of the IETF.=A0 But work on OGP is hampered by t= he very clear fact that MMOX discussions and requirements are far broader a= nd can't be forced into an a priori straightjacket.=A0 By the same toke= n, work on MMOX is likewise being hampered by a narrow focus on near-term L= inden goals.

This is why I am trying to find an approach that will allow both group= s of interests to be successful and productive.=A0 Currently there is littl= e commonality owing to the gulf between the actual narrow intent stated in = your "taxonomy of topics" and the very much broader goals of MMOX= .


Morgaine.







On Thu, Feb 26, 2009 at 6:37 PM, Infinity Meadhbh Hamrick <infinity= @lindenlab.com> wrote:
so it seems clea= r we all have different ideas of what it means to be interoperable.
i thought i might try to define a couple of the definitions i think i'= ve seen people use:

1. interoperability means all virtual worlds, = wherever they are, may be accessed via a single unified client.

2. interoperability means all virtual worlds, wherever they are, use preci= sely the same protocol(s) and all virtual worlds represent data in formats = understandable by all other virtual worlds, with a universal client.

3. interoperability means some virtual worlds may be accessed via a s= ingle unified client.

4. interoperability means some virtual world= s use precisely the same protocol(s) and all virtual worlds represent data = in formats understandable by all other virtual worlds, without a universal = client.

5. interoperability means some virtual worlds use some of the same pr= otocols, without a universal client

6. interoperability means the = "model" is the same, but with different protocols that may be bri= dged with protocol gateways.

it seems to me that many of us are using different descriptions for t= he word "interoperable" and it's causing mild discord and at = least a couple instances of us talking past each other.

personally= .. i'm kind of interested in option 5. it has the benefit of producing = a protocol that is identifiable by routers, network management software, et= c. it also provides a "slowly moving target" for open source deve= lopers (as opposed to the "fast moving target" of linden's ex= isting protocol(s)). by making it public, VW operators can choose whether o= r not they wish to implement it. it also doesn't require VW operators t= o implement it (as if we could anyway) and it allows VW operators to avoid = having to test interoperability with every other virtual world.

but it's not without drawbacks... this model can lead to a "= MOSS-like" environment. (for those of you who don't remember MOSS = or MIME Object(?) Security Services... it was a response to the drawbacks o= f PEM (privacy enhanced mail) which had a relative paucity of encryption op= tions. but IMHO, MOSS introduced so many options that it was VERY easy for = two implementations to adhere to the spec, but not actually be interoperabl= e.)

so... i recommend that if we (as a group) wanted to pursue option-5..= we also explicitly define what goes in an "interoperability profile.&= quot; that way you could get the benefit of having a relatively stable prot= ocol that could be targeted by open source developers which could be used b= y VW operators to help make client / server apps.

VW operators could publish their "interoperability profile"= to tell people who wanted to build tools, extra services, or interoperable= worlds what options would be available and how they would work.

-cheers
-m
_______________________________________________
mmo= x mailing list
mmox@= ietf.org
https://www.ietf.org/mailman/listinfo/mmox



--001636c5bf4496a70d0463e34248-- From morgaine.dinova@googlemail.com Fri Feb 27 01:49:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B863A682C for ; Fri, 27 Feb 2009 01:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVCK1foBVq2S for ; Fri, 27 Feb 2009 01:49:37 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 8AD4F3A68CD for ; Fri, 27 Feb 2009 01:49:36 -0800 (PST) Received: by bwz26 with SMTP id 26so935011bwz.37 for ; Fri, 27 Feb 2009 01:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0nttofPMU9xAtI5lhDEkEQsfglTk0I07qJLcZvAZgno=; b=qZcG/B8l2ubWBu8OXVDtFRTgE2DsN/P0LXcolcVoji6n6kN13qmmijuVklaDAsVWs7 SAPVtIz2eLU3kvV4qbB6BBNsbGX5y3TmnbzR9XrZ0Pj6kNMrLJsQOyQ7cX8GNustsRGZ JUfzaByM1S0Pbj0BsOi3U/9wgZNHSuN50RU54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KOsXsuAPgmYCWHcURYNIZEOJmGRu0ZcYiblPrHt5u5dn2xjSmfhuTZ9h02w9XTtJ4B VGEzAaoDEtWj/PZUz3JacsjuF6/Gsux0Y109hAje/C+vNmybQoZNM8PNpF91xl4ql3CN sebkpB45EMN2XWZeqAuQEdeDpls3EAZ7j+R8Y= MIME-Version: 1.0 Received: by 10.181.134.12 with SMTP id l12mr808665bkn.80.1235728197795; Fri, 27 Feb 2009 01:49:57 -0800 (PST) In-Reply-To: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> Date: Fri, 27 Feb 2009 09:49:57 +0000 Message-ID: From: Morgaine To: Heiner Wolf Content-Type: multipart/alternative; boundary=0016363b992244c0760463e36400 Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 09:49:38 -0000 --0016363b992244c0760463e36400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Well said, Heiner. Conflating the two quite separate interests into just one is not helping progress in either direction at the moment. Morgaine. On Wed, Feb 25, 2009 at 9:09 PM, Heiner Wolf wrote: > Hi, > > I understand that the original intention was to make OGP public and > get comments. But if that's the purpose you probably should call the > WG OGP. > > We had a similar situation in the Instant Message and Presence WG, > where several vendors tried to talk about "their" protocol. Lisa > probably remembers. The situation was solved by chartering the IMPP WG > to create only requirements, then 2 new WGs worked on "their" protocol > (SIMPLE, XMPP). I bet we get a similar discussion. Maybe MMOX should > define requirements and an OGP WG may then work on the OGP way later. > This gives time for other developers to speak up and add learnings > from "their" worlds and protocols. Do we have people from Everquest, > WoW, There, EVE Online, Runescape, Google Earth here? We need them for > something thats called MMOX. We should give them time to speak up. > > BTW: we are building a virtual world based on XMPP chat rooms. There > are more, like IMVU, which use chat protocols for their virtual > worlds. The chat room is what you would call a region domain. > > This is quite a different angle, but an interesting one, because the > transport protocol is very simple and has few extensions.The > extensions carry the 3D stuff. An interesting feature of worlds which > are based on chat protocols is, that there is low in-band traffic. The > reason is, that off the shelf chat servers are not build for heavy > traffic. So, only notifications are transferrred in the chat protocol. > Assets use a separate data access protocol, usually HTTP. > > This simplistic view of people who use chat protocols for virtual > worlds could be useful in identifying "what you really need" for a VW > interop protocol. > > hw > -- > Dr. Heiner Wolf > wolf.heiner@gmail.com > www.wolfspelz.de > www.virtual-presence.org > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --0016363b992244c0760463e36400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well said, Heiner.=A0=A0 Conflating the two quite separate interests into j= ust one is not helping progress in either direction at the moment.

M= orgaine.





On Wed, Feb 25, = 2009 at 9:09 PM, Heiner Wolf <wolf.heiner@googlemail.com> wrote:
Hi,

I understand that the original intention was to make OGP public and
get comments. But if that's the purpose you probably should call the WG OGP.

We had a similar situation in the Instant Message and Presence WG,
where several vendors tried to talk about "their" protocol. Lisa<= br> probably remembers. The situation was solved by chartering the IMPP WG
to create only requirements, then 2 new WGs worked on "their" pro= tocol
(SIMPLE, XMPP). I bet we get a similar discussion. Maybe MMOX should
define requirements and an OGP WG may then work on the OGP way later.
This gives time for other developers to speak up and add learnings
from "their" worlds and protocols. Do we have people from Everque= st,
WoW, There, EVE Online, Runescape, Google Earth here? We need them for
something thats called MMOX. We should give them time to speak up.

BTW: we are building a virtual world based on XMPP chat rooms. There
are more, like IMVU, which use chat protocols for their virtual
worlds. The chat room is what you would call a region domain.

This is quite a different angle, but an interesting one, because the
transport protocol is very simple and has few extensions.The
extensions carry the 3D stuff. An interesting feature of worlds which
are based on chat protocols is, that there is low in-band traffic. The
reason is, that off the shelf chat servers are not build for heavy
traffic. So, only notifications are transferrred in the chat protocol.
Assets use a separate data access protocol, usually HTTP.

This simplistic view of people who use chat protocols for virtual
worlds could be useful in identifying "what you really need" for = a VW
interop protocol.

hw
--
Dr. Heiner Wolf
wolf.heine= r@gmail.com
www.wolfspelz.de<= br> www.virtual-p= resence.org
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--0016363b992244c0760463e36400-- From jesrad@gmail.com Fri Feb 27 03:15:49 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF73128C146 for ; Fri, 27 Feb 2009 03:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vpCzElLdKAS1 for ; Fri, 27 Feb 2009 03:15:48 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id E99483A6AE9 for ; Fri, 27 Feb 2009 03:15:45 -0800 (PST) Received: by bwz26 with SMTP id 26so970705bwz.37 for ; Fri, 27 Feb 2009 03:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Kl1/hQBKrysxWIiX7I5+cO3auOft2VZ3Y9dmsAdD3wU=; b=iB+/Nl8wKKhyQoDauaCp9v4di13BX/VsTXPLmIQ9mEj7BOn+ID+mSQiUooQTpMIiaf eGIchHMgszv/k5uz9WYE1xjR2vUyJVopnKhGdky2+3PTdSfcrJD0TEpXI0lD0e91SALO 8xMAfGE7dja+qRJK5sp/UY0+EkFhtU2v1XxKA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CaND6WhMXMnHOw8akyQ6/D1i3muq3EKmKXCbUIMACz/kSrcVR/R+JlY2A80JbCyn8w ugcUnH/u3cAaOPBPuPy/miD3ed+ar9o3Q6FWwAlsBRwM3RudaXUHHTO1HEP/FGX90mle UyK3bfbzftb9rnNaqSTaHhDrhvB+Ia43Vz/iA= MIME-Version: 1.0 Received: by 10.181.201.18 with SMTP id d18mr834146bkq.72.1235733366645; Fri, 27 Feb 2009 03:16:06 -0800 (PST) In-Reply-To: <4EC4C999-59E9-49BF-99C0-82ED4BBD9A64@lindenlab.com> References: <49A736AA.2020205@gmail.com> <4EC4C999-59E9-49BF-99C0-82ED4BBD9A64@lindenlab.com> Date: Fri, 27 Feb 2009 12:16:06 +0100 Message-ID: <53cd6c2e0902270316j36df5b42qd319d9103fce3976@mail.gmail.com> From: Jesrad To: "Meadhbh Hamrick (Infinity)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "mmox@ietf.org" Subject: Re: [mmox] Use cases? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 11:15:49 -0000 The use cases certainly help focus on the "meat" of the protocol, however they can also easily miss entire domains of application for the protocol, so they won't be the sole source for listing requirements. We could exhaust every cross-grid way to exploit each of the VW features that are to be transported by the MMOX protocol, but then it implies we know which features these are. And some use-cases may extend the scope of interoperability way more than necessary or desireable for the people for whom MMOX is intended. That poses a problem: not all VWs will be interested in sharing all their features cross-grid, nor even all the features they have in common with other VWs, so I think the MMOX protocol needs to define levels of partial compliance, possibly in the form of a dependencies tree. I believe making sure some interoperability is sufficient while not mandating all-inclusive interoperability will appeal more to the "big players" that are still not represented in this group. We've also seen already that some VW services are interdependable (there's little sense in having financial exchange capability without identity and auth, or 3D representation without contiguity and presence simulation) but that many such "bundles" (like the division in Agent and Region domains in OGP, if I'm not mistaken) can operate seperately. We've seen too that it implies some capacity, for MMOX-compliant VWs, to multi-source those bundles of services. So we may well need to fuse all the features that are interdependant together, while avoiding any cross-dependancy among them when they don't.Think of it as "interoperability =E0 la carte", but with only menus of grouped services and not individual ones to pick from and support in each VW. So the partial implementation of MMOX would still mandate that each such bundles (Domains ?) be supported in full, or not at all. So I suggest use-cases only come after we get a good idea of what features' PDUs the protocol will transport, and how they might be grouped together. When we have that information, exploring the functional possibilities and thinking about what interoperability would make possible for the end user will be easier and probably more exhaustive, while avoiding the potential pitfall of requirements that could degrade the "palatability" of the protocol to some big players. On Fri, Feb 27, 2009 at 2:16 AM, Meadhbh Hamrick (Infinity) wrote: > well... yes and no... use cases are important. but to prevent feature cre= ep > having a charter + a concrete proposal is always convenient. our charter = is > under discussion and is therefore at least "plastic" if not "fluid." > > but yes. if i had it to do over, i would have published as much of OGP as= we > currently have defined along with LLSD as it's the application level that > ultimately will be more interesting. > > -cheers > -meadhbh > > On Feb 26, 2009, at 4:41 PM, Jon Watte wrote: > >> I posted five use cases that I think cover a fair range of virtual world >> interoperability. I've gotten several nice replies in the mail, but on t= he >> list they seem to have soared like a lead balloon, as opposed to all tal= k >> about XML vs binary vs IP property rights. Surely, agreeing on requireme= nts >> (such as use cases) is actually more important than discussing >> implementation details that we don't even know will apply yet? >> >> Any opinions, for or against, regarding these use cases? Silent assent? >> >> http://www.interopworld.org/mmox-use-cases >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From jesrad@gmail.com Fri Feb 27 03:23:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A2D628C25B for ; Fri, 27 Feb 2009 03:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pAbaqojBMHj for ; Fri, 27 Feb 2009 03:23:14 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 086A028C200 for ; Fri, 27 Feb 2009 03:23:13 -0800 (PST) Received: by bwz26 with SMTP id 26so973644bwz.37 for ; Fri, 27 Feb 2009 03:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/x4Tov6jnbcqOnOul1edo2enV750M4FB2NU0lmDE/+0=; b=NmXc7sU6HncxDzhQQbTqZUbtF7trJOAaHqDlazolDzqVlWi4c9J+BLJsdaeYC3/K/t BUVvhCQaWWJ5asK40H4mz4vGbgg0MYNj35v4RUNeEdtyMjbHOSfPLDkSeumvpS9AtKhk h44CEJMoOUJzxKPYf/DXL3sfskUWvYbJSkxGc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mDp+0zBt1rSIWrXZvupKEyAizsEBjR6ypea4hr6kqsufJBHsrmFNEaYyTn5jfZx9kW BZLt1JIbkps0LK8rGNtEaMXdDazhbmLNrWUmNFhBiI74Ku718TswQUBJleyq1Jyp6RZ7 VWKaPXEnqIz2+VXKTdL+wpZVV+CM+MRQQlfiA= MIME-Version: 1.0 Received: by 10.181.60.13 with SMTP id n13mr836714bkk.39.1235733815449; Fri, 27 Feb 2009 03:23:35 -0800 (PST) In-Reply-To: References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> Date: Fri, 27 Feb 2009 12:23:35 +0100 Message-ID: <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> From: Jesrad To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 11:23:15 -0000 Heartily seconded, there are lots of divergent interests that would hamper the broad adoption of the protocol if we tried to include too many things, just as well as including too little would severly limit the interest of the whole thing for the end users. Which makes me think we might need to tag some of the features as optional. On Fri, Feb 27, 2009 at 10:49 AM, Morgaine wrote: > Well said, Heiner.=A0=A0 Conflating the two quite separate interests into= just > one is not helping progress in either direction at the moment. > > Morgaine. > > > > > > On Wed, Feb 25, 2009 at 9:09 PM, Heiner Wolf > wrote: >> >> Hi, >> >> I understand that the original intention was to make OGP public and >> get comments. But if that's the purpose you probably should call the >> WG OGP. >> >> We had a similar situation in the Instant Message and Presence WG, >> where several vendors tried to talk about "their" protocol. Lisa >> probably remembers. The situation was solved by chartering the IMPP WG >> to create only requirements, then 2 new WGs worked on "their" protocol >> (SIMPLE, XMPP). I bet we get a similar discussion. Maybe MMOX should >> define requirements and an OGP WG may then work on the OGP way later. >> This gives time for other developers to speak up and add learnings >> from "their" worlds and protocols. Do we have people from Everquest, >> WoW, There, EVE Online, Runescape, Google Earth here? We need them for >> something thats called MMOX. We should give them time to speak up. >> >> BTW: we are building a virtual world based on XMPP chat rooms. There >> are more, like IMVU, which use chat protocols for their virtual >> worlds. The chat room is what you would call a region domain. >> >> This is quite a different angle, but an interesting one, because the >> transport protocol is very simple and has few extensions.The >> extensions carry the 3D stuff. An interesting feature of worlds which >> are based on chat protocols is, that there is low in-band traffic. The >> reason is, that off the shelf chat servers are not build for heavy >> traffic. So, only notifications are transferrred in the chat protocol. >> Assets use a separate data access protocol, usually HTTP. >> >> This simplistic view of people who use chat protocols for virtual >> worlds could be useful in identifying "what you really need" for a VW >> interop protocol. >> >> hw >> -- >> Dr. Heiner Wolf >> wolf.heiner@gmail.com >> www.wolfspelz.de >> www.virtual-presence.org >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From cathypfeffer@gmail.com Fri Feb 27 04:13:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A3533A6969 for ; Fri, 27 Feb 2009 04:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJDbbG7Z16iu for ; Fri, 27 Feb 2009 04:13:21 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id A035C3A682A for ; Fri, 27 Feb 2009 04:13:20 -0800 (PST) Received: by fxm24 with SMTP id 24so1015879fxm.37 for ; Fri, 27 Feb 2009 04:13:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=7L6VKbc+ccnlsWZLgOyZMjp3GetccfU/QK2Ub3BQBYE=; b=lRZjtt1NyMUaCRR4XrCuPi0WG/s03GULWg3XdbpiGA2JxYnPZYb4ayT6uaO8JNwJoW crbfB4K93WfTzubSP01vjM4CwC88wKvUdnUZxAL4uw6HBYlIo+t8Ihh8UXhnKX/PIMbu ZaxWlR5pGAtGrIAAmuZQuRUc/EeqCvrJLld6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uuuykFInZwhRvIwVj3fgJ8NIUz9oE9cEffij36ws+SO4whZzkF0Qdgxpn72jFS454B v8H+Li1EHx0mmOCzAhE/hkeEnG219MbpNGQipBP9Dhroln1MIArTCNCXvIye+AkM2xDm 696JFdAEe6WTuRLEYA7MLldfBiEgjimhc3KaU= MIME-Version: 1.0 Received: by 10.181.221.15 with SMTP id y15mr849583bkq.121.1235736822198; Fri, 27 Feb 2009 04:13:42 -0800 (PST) Date: Fri, 27 Feb 2009 13:13:42 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636c5a3ed52b1210463e5662b Subject: [mmox] Keys as numbers in the binary format ; two different protocols X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 12:13:23 -0000 --001636c5a3ed52b1210463e5662b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > > - it would be less simple in a program because you would need to look > > up in a table to solve the indirections > > I don't think that's intellectually honest. Don't call me dishonest. I have probably said something stupid here, but please let me the privilege to recognize it. > > - if you have been unable to transmit the packet containing the > > table, you can't do anything anymore > > If I can't send data, I can't send data, that's right! If I can't send > data, why am I trying to do a live, real-time streaming application anyway? I disagree on this one. It is one thing to lose a given packed that would prevent your avatar from receiving an IM message or from moving 10 centimeters to the right, and it is another thing to fail receiving a list of numbers that would allow you to decode the entire session. That's probably the showstopper point. For the rest, you are right, my arguments don't resist a serious examination. > Note that I am not proposing using schema-driven binary interchange for > transactional or durable applications. I believe we need at least two > separate systems: a very efficient transmission format for streaming > live, high-bandwidth data (such as a stream of entity property updates > during simulation), and a very robust exchange format for transactional, > batch or offline processing (such as "properly structured" XML). It makes sense. Now is it really a good idea to make both systems derive of the binary serialization? Probably not. As I see it, LLSD is really fit to real time data, but its XML serialization, at least in its current state, is not what I would call "properly structured" for all the reasons that I already explained. Having two different systems would also remove the problem of negotiation. Real time data would be binary encoded, transactional data would be XML encoded (SOAP, XML-RPC, whatever). Different class of problems, different encodings, so there's nothing to negociate. Each packet would naturally fall in one of each classes, real time or transactional. We could even decide that the first class should be transported by UDP and the second one by HTTPS (Infinity will kill me for this remark). Perharps it is really worth rewriting the XML serialisation so that it fits into good XML practice, after all. -- Cathy --001636c5a3ed52b1210463e5662b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > > =C2=A0- it would be less simple in a program because you would ne= ed to look
> > up in a table to solve the indirections
> > I don't think that's intellectually honest.

Don't= call me dishonest.

I have probably said something stupid here, but please let me the privi= lege to recognize it.

> > =C2=A0- if you have been unable to t= ransmit the packet containing the
> > table, you can't do any= thing anymore
>
> If I can't send data, I can't send data, that's ri= ght! If I can't send
> data, why am I trying to do a live, real-= time streaming application anyway?

I disagree on this one. It is one= thing to lose a given packed that would prevent your avatar from receiving= an IM message or from moving 10 centimeters to the right, and it is anothe= r thing to fail receiving a list of numbers that would allow you to decode = the entire session. That's probably the showstopper point.

For the rest, you are right, my arguments don't resist a serious ex= amination.

> Note that I am not proposing using schema-driven bin= ary interchange for
> transactional or durable applications. I belie= ve we need at least two
> separate systems: a very efficient transmission format for streaming <= br>> live, high-bandwidth data (such as a stream of entity property upda= tes
> during simulation), and a very robust exchange format for tran= sactional,
> batch or offline processing (such as "properly structured" X= ML).

It makes sense.

Now is it really a good idea to make bot= h systems derive of the binary serialization? Probably not. As I see it, LL= SD is really fit to real time data, but its XML serialization, at least in = its current state, is not what I would call "properly structured"= for all the reasons that I already explained.

Having two different systems would also remove the problem of negotiati= on. Real time data would be binary encoded, transactional data would be XML= encoded (SOAP, XML-RPC, whatever). Different class of problems, different = encodings, so there's nothing to negociate.

Each packet would naturally fall in one of each classes, real time or t= ransactional. We could even decide that the first class should be transport= ed by UDP and the second one by HTTPS (Infinity will kill me for this remar= k).

Perharps it is really worth rewriting the XML serialisation so that it = fits into good XML practice, after all.

--
Cathy
--001636c5a3ed52b1210463e5662b-- From lenglish5@cox.net Fri Feb 27 04:27:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602733A6A20 for ; Fri, 27 Feb 2009 04:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.503 X-Spam-Level: X-Spam-Status: No, score=0.503 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLefa9jfgf7C for ; Fri, 27 Feb 2009 04:27:13 -0800 (PST) Received: from fed1rmmtao105.cox.net (fed1rmmtao105.cox.net [68.230.241.41]) by core3.amsl.com (Postfix) with ESMTP id 6E2663A682A for ; Fri, 27 Feb 2009 04:27:13 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao105.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090227122737.FDMM15318.fed1rmmtao105.cox.net@fed1rmimpo01.cox.net>; Fri, 27 Feb 2009 07:27:37 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id M0Tb1b0034N6T0Q030TbnR; Fri, 27 Feb 2009 07:27:35 -0500 X-Authority-Analysis: v=1.0 c=1 a=H7oVHkRPDCcA:10 a=xj0JfVIbDmkA:10 a=Wajolswj7cQA:10 a=mK_AVkanAAAA:8 a=FSFrTptfSGqYZ9lETS4A:9 a=WBUHUGQ5yUI9ZcjhqpAp8n7jRsEA:4 a=QMgMR9M9BAsA:10 a=9xyTavCNlvEA:10 X-CM-Score: 0.00 Message-ID: <49A7DC37.1050002@cox.net> Date: Fri, 27 Feb 2009 05:27:35 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jesrad References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> In-Reply-To: <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 12:27:14 -0000 Jesrad wrote: > Heartily seconded, there are lots of divergent interests that would > hamper the broad adoption of the protocol if we tried to include too > many things, just as well as including too little would severly limit > the interest of the whole thing for the end users. > > Which makes me think we might need to tag some of the features as optional. > > On Fri, Feb 27, 2009 at 10:49 AM, Morgaine > wrote: > >> Well said, Heiner. Conflating the two quite separate interests into just >> one is not helping progress in either direction at the moment. >> >> Morgaine. >> >> >> My own take is that fragmenting the working group at this point is counter-productive. We can recognize several [types of] low-hanging fruit[s] that may apply to many worlds or just 2 or more of a given type (e.g. Second Life/OpenSIm compatible). In other words, here's more than one possible sub-tree these inter-operable fruits are hanging from and it is likely more like a digraph than a simple tree (who knows, possibly not merely a digraph either if there are dependencies that go back up the "tree"). E.G.: Interoperability scenarios for virtual worlds | ------------------------------------------------------------------------- | | Authentication for SL-type worlds Authentication of Other worlds / | \ / | \ -------------------------------------------------------- [...] etc | | | / ] \ Agent Domain HyperGrid Something Else At the same level we might search for alternate ways of: expressing basic protocols LLSD vs xxSD vs ... or of geometry: OBJ vs SL-extended prims vs Callada vs world-specific terrains/... or of group IM: SL-style vs javbber vs irc vs... Etc. There's no reason to assume that full interoperability can be obtained amongst all worlds in the same way, but no reason to assume we can't find points of commonality which can mix and match. The OGP has made a good start for authentication and TP between OpenSim and Second Life, and OpenSim has come up with an alternative called HyperGrid. Our meeting on video streaming showed that there are points of inter-operability between SL, OpenSim and Croquet/Qwaq. Surely we can find others. To say: "let us split the working group up from the start into SL-compatible and incompatible worlds" assumes that we can find no common ground at all. I think that is the wrong way to go. Lawson From morgaine.dinova@googlemail.com Fri Feb 27 07:40:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006B63A6A78 for ; Fri, 27 Feb 2009 07:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFGi-SjMRrjy for ; Fri, 27 Feb 2009 07:40:25 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id B7ECE3A68D5 for ; Fri, 27 Feb 2009 07:40:24 -0800 (PST) Received: by bwz26 with SMTP id 26so1080577bwz.37 for ; Fri, 27 Feb 2009 07:40:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kxFxxZHRXMFS6GvWFo/xzDMs/OZGi/HV+e483yGvGnQ=; b=nfyyZdCuy1Q/ZuKuTJxsckiqYC4cholXE4IlozOuwqqZldfh77EF7MuYjHDwCIhAar IFtPtQ3ghvgvmTH1/ZrAV1icSkILU/VvjL4U1VYN0thMjCvDoN1a839mZheFVfscLHNF kzLQUDKqz4IyjfL/wjDjXjwhHwzu1jOz/w3QU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q0XCEGP1pHZdhJFISf7GvA5URFAreb02RUbyfcZbSw2/WcmlOeCbh1v7soq9R9bR9T NmlzPdGqCBokKCXTFEZ9zyi3ZC9VWR4UJY8Si1rZujEFdn2JlZ680yMDKpMNtANrXfvy VHzPBwCd9nq9QATcBNwdcyzVwbxSO81GUIzAk= MIME-Version: 1.0 Received: by 10.181.61.7 with SMTP id o7mr907524bkk.85.1235749246321; Fri, 27 Feb 2009 07:40:46 -0800 (PST) In-Reply-To: <49A7DC37.1050002@cox.net> References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> Date: Fri, 27 Feb 2009 15:40:46 +0000 Message-ID: From: Morgaine To: lenglish5@cox.net Content-Type: multipart/alternative; boundary=001636499147dbc5a10463e84a92 Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 15:40:27 -0000 --001636499147dbc5a10463e84a92 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 27, 2009 at 12:27 PM, Lawson English wrote: > > My own take is that fragmenting the working group at this point is > counter-productive. We can > recognize several [types of] low-hanging fruit[s] that may apply to many > worlds or just 2 or more > of a given type (e.g. Second Life/OpenSIm compatible). But it is of no interest to the MMOX group *as a whole* to achieve interoperability between only 2 or more worlds of a given type. Such progress would be great for the worlds concerned, but of no use to anyone else. > > > There's no reason to assume that full interoperability can be obtained > amongst all worlds > in the same way, but no reason to assume we can't find points of > commonality which can > mix and match. "Full interoperability" is not something that anyone has proposed, so knocking it down is just a straw man. Instead, we've been looking for ways to achieve *some* degree of interop by focusing on just a few things that are common to virtually all worlds. A common protocol that deals extensibly with those few things would be an amazing achievement, but locking down the solution space even before the group has a charter is not the way to go about it ... except in a group dedicated to a specific solution. > > > The OGP has made a good start for authentication and TP > between OpenSim and Second Life, and OpenSim has come up with an > alternative called HyperGrid. > Our meeting on video streaming showed that there are points of > inter-operability between SL, OpenSim > and Croquet/Qwaq. Surely we can find others. To say: "let us split the > working group up from the start > into SL-compatible and incompatible worlds" assumes that we can find no > common ground at all. > > > Oh I'm fairly certain that we *CAN* find common ground in MMOX --- indeed, that's the whole reason we're here. Unfortunately the effort is derailed when one party requires that that all the "common ground" has to be within their own solution space. The only reason I proposed a split is to get around the impasse of what appears to be one entrenched position, so that everyone can make good progress on all fronts to the benefit of all. If there are no preconditions though, then of course we could continue to search for natural common ground, and I have no reason to believe that we would not succeed. The phrase "Where there's a will there's a way" is very germane here. Given the will to move off one's own turf opens up numerous avenues for finding common ground with others. Morgaine. On Fri, Feb 27, 2009 at 12:27 PM, Lawson English wrote: > Jesrad wrote: > >> Heartily seconded, there are lots of divergent interests that would >> hamper the broad adoption of the protocol if we tried to include too >> many things, just as well as including too little would severly limit >> the interest of the whole thing for the end users. >> >> Which makes me think we might need to tag some of the features as >> optional. >> >> On Fri, Feb 27, 2009 at 10:49 AM, Morgaine >> wrote: >> >> >>> Well said, Heiner. Conflating the two quite separate interests into >>> just >>> one is not helping progress in either direction at the moment. >>> >>> Morgaine. >>> >>> >>> >>> >> > > My own take is that fragmenting the working group at this point is > counter-productive. We can > recognize several [types of] low-hanging fruit[s] that may apply to many > worlds or just 2 or more > of a given type (e.g. Second Life/OpenSIm compatible). > > In other words, here's more than one possible sub-tree these inter-operable > fruits are hanging from and > it is likely more like a digraph than a simple tree (who knows, possibly > not merely a digraph either if > there are dependencies that go back up the "tree"). > > E.G.: > > Interoperability scenarios for virtual worlds > | > ------------------------------------------------------------------------- > | | > > Authentication for SL-type worlds Authentication of Other worlds > / | \ > / | \ > -------------------------------------------------------- [...] > etc > | | | > / ] \ > Agent Domain HyperGrid Something Else > > > > > At the same level we might search for alternate ways of: > > expressing basic protocols > > LLSD vs xxSD vs ... > > or of geometry: > > OBJ vs SL-extended prims vs Callada vs world-specific terrains/... > > or of group IM: > > SL-style vs javbber vs irc vs... > > Etc. > > > There's no reason to assume that full interoperability can be obtained > amongst all worlds > in the same way, but no reason to assume we can't find points of > commonality which can > mix and match. > > The OGP has made a good start for authentication and TP > between OpenSim and Second Life, and OpenSim has come up with an > alternative called HyperGrid. > Our meeting on video streaming showed that there are points of > inter-operability between SL, OpenSim > and Croquet/Qwaq. Surely we can find others. To say: "let us split the > working group up from the start > into SL-compatible and incompatible worlds" assumes that we can find no > common ground at all. > > > > > I think that is the wrong way to go. > > > Lawson > > > > > > > > --001636499147dbc5a10463e84a92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 27, 2009 at 12:27 PM, Lawson English= <lenglish5@cox.n= et> wrote:
=A0
My own take is that fragmenting the working group at this point is counter-= productive. We can
recognize several [types of] low-hanging fruit[s] that may apply to many wo= rlds or just 2 or more
of a given type (e.g. Second Life/OpenSIm compatible).

But it is of no interest to the MMOX group as a whole to= achieve interoperability between only 2 or more worlds of a given type.=A0= Such progress would be great for the worlds concerned, but of no use to an= yone else.


There's no reason to assume that full interoperability can be obtained = amongst all worlds
in the same way, but no reason to assume we can't find points of common= ality which can
mix and match.


"Full interoperability" i= s not something that anyone has proposed, so knocking it down is just a str= aw man.=A0 Instead, we've been looking for ways to achieve some = degree of interop by focusing on just a few things that are common to virtu= ally all worlds.=A0 A common protocol that deals extensibly with those few = things would be an amazing achievement, but locking down the solution space= even before the group has a charter is not the way to go about it ... exce= pt in a group dedicated to a specific solution.


The OGP has made a good start for authentication and TP
between OpenSim and Second Life, and OpenSim has come up with an alternativ= e called HyperGrid.
Our meeting on video streaming showed that there are points of inter-operab= ility between SL, OpenSim
and Croquet/Qwaq. Surely we can find others. To say: "let us split the= working group up from the start
into SL-compatible and incompatible worlds" assumes that we can find n= o common ground at all.


Oh I'm fairly certain = that we CAN find common ground in MMOX --- indeed, that's the wh= ole reason we're here.=A0 Unfortunately the effort is derailed when one= party requires that that all the "common ground" has to be withi= n their own solution space.

The only reason I proposed a split is to get around the imp= asse of what appears to be one entrenched position, so that everyone can ma= ke good progress on all fronts to the benefit of all.=A0 If there are no pr= econditions though, then of course we could continue to search for natural = common ground, and I have no reason to believe that we would not succeed.
The phrase "Where there's a will there's a way" is ve= ry germane here.=A0 Given the will to move off one's own turf opens up = numerous avenues for finding common ground with others.


Morgaine= .







On Fri, Feb 27, 2009= at 12:27 PM, Lawson English <lenglish5@cox.net> wrote:
Jesrad wrote:
Heartily seconded, there are lots of divergent interests that would
hamper the broad adoption of the protocol if we tried to include too
many things, just as well as including too little would severly limit
the interest of the whole thing for the end users.

Which makes me think we might need to tag some of the features as optional.=

On Fri, Feb 27, 2009 at 10:49 AM, Morgaine
<mor= gaine.dinova@googlemail.com> wrote:
=A0
Well said, Heiner. =A0 Conflating the two quite separate interests into jus= t
one is not helping progress in either direction at the moment.

Morgaine.


=A0 =A0


My own take is that fragmenting the working group at this point is counter-= productive. We can
recognize several [types of] low-hanging fruit[s] that may apply to many wo= rlds or just 2 or more
of a given type (e.g. Second Life/OpenSIm compatible).

In other words, here's more than one possible sub-tree these inter-oper= able fruits are hanging from and
it is likely more like a digraph than a simple tree (who knows, possibly no= t merely a digraph either if
there are dependencies that go back up the "tree").

E.G.:

Interoperability scenarios for virtual worlds
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
------------------------------------------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|

Authentication for SL-type worlds =A0 =A0 =A0 =A0 =A0Authentication of Othe= r worlds
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0| =A0\ =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 / =A0| =A0 \ =A0 =A0 ---------------------------------= ----------------------- =A0 [...] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 etc
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ ] \
Agent Domain =A0 =A0 HyperGrid =A0 =A0 =A0Something Else




At the same level we might search for alternate ways of:

expressing basic protocols

LLSD vs xxSD vs ...

or =A0of geometry:

OBJ vs SL-extended prims vs Callada vs world-specific terrains/...

or of group IM:

SL-style vs javbber vs irc vs...

Etc.


There's no reason to assume that full interoperability can be obtained = amongst all worlds
in the same way, but no reason to assume we can't find points of common= ality which can
mix and match.

The OGP has made a good start for authentication and TP
between OpenSim and Second Life, and OpenSim has come up with an alternativ= e called HyperGrid.
Our meeting on video streaming showed that there are points of inter-operab= ility between SL, OpenSim
and Croquet/Qwaq. Surely we can find others. To say: "let us split the= working group up from the start
into SL-compatible and incompatible worlds" assumes that we can find n= o common ground at all.




I think that is the wrong way to go.


Lawson








--001636499147dbc5a10463e84a92-- From lenglish5@cox.net Fri Feb 27 07:50:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B22928C0DD for ; Fri, 27 Feb 2009 07:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.87 X-Spam-Level: X-Spam-Status: No, score=0.87 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPkZILLbnKVf for ; Fri, 27 Feb 2009 07:50:38 -0800 (PST) Received: from fed1rmmtao104.cox.net (fed1rmmtao104.cox.net [68.230.241.42]) by core3.amsl.com (Postfix) with ESMTP id A279028C141 for ; Fri, 27 Feb 2009 07:50:38 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090227155101.PJRG16134.fed1rmmtao104.cox.net@fed1rmimpo02.cox.net>; Fri, 27 Feb 2009 10:51:01 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id M3r01b00D4N6T0Q043r0YV; Fri, 27 Feb 2009 10:51:01 -0500 X-Authority-Analysis: v=1.0 c=1 a=H7oVHkRPDCcA:10 a=xj0JfVIbDmkA:10 a=Wajolswj7cQA:10 a=kviXuzpPAAAA:8 a=JdDMFvmFr3jRpFqNsUcA:9 a=nPxeAv4HAIN7ypRW0xDWxhcxHFwA:4 a=EvFsD9_1mWgA:10 a=4vB-4DCPJfMA:10 a=Ie_yz-n3dUD_hApw:21 a=5FFUG9pIka4zEbRl:21 X-CM-Score: 0.00 Message-ID: <49A80BE4.7000206@cox.net> Date: Fri, 27 Feb 2009 08:51:00 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Morgaine References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 15:50:39 -0000 Morgaine wrote: > On Fri, Feb 27, 2009 at 12:27 PM, Lawson English > wrote: > > > My own take is that fragmenting the working group at this point is > counter-productive. We can > recognize several [types of] low-hanging fruit[s] that may apply > to many worlds or just 2 or more > of a given type (e.g. Second Life/OpenSIm compatible). > > > > But it is of no interest to the MMOX group */as a whole/* to achieve > interoperability between only 2 or more worlds of a given type. Such > progress would be great for the worlds concerned, but of no use to > anyone else. But interoperation between worlds is obviously eaisier with some than others. It seems to me that YOU are proposing an "all or none" solution here. The OGP solution should work for most worlds, as long as people understand the abstraction: login to Agent Domain means to get some kind of recognition from that specific authorizing authority (however its done behind the scenes) teleport from one region to another means to request that the Agent Domain signal the destination world/sim/whatever should start the process of creating a presence for the avatar while signalling the current world that such a presence is no longer valid combined with providing connections/services/whatevers between the client and relevant server(s) to make this work. Lawson From Chris.Down@alcor.co.uk Fri Feb 27 09:12:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A4D28C330 for ; Fri, 27 Feb 2009 09:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKMr4z8otQBq for ; Fri, 27 Feb 2009 09:12:11 -0800 (PST) Received: from merak.alcor.co.uk (merak.alcor.co.uk [217.155.59.205]) by core3.amsl.com (Postfix) with ESMTP id 7842128C26F for ; Fri, 27 Feb 2009 09:12:09 -0800 (PST) Received: from sirius.alcor.co.uk ([192.168.1.2]) by merak.alcor.co.uk with esmtp (Exim 4.69) (envelope-from ) id 1Ld6GE-0007P7-KD; Fri, 27 Feb 2009 17:12:30 +0000 Message-ID: <49A81F25.3030702@alcor.co.uk> Date: Fri, 27 Feb 2009 17:13:09 +0000 From: Chris Down User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090226 Lightning/1.0pre Shredder/3.0b3pre MIME-Version: 1.0 To: "dyerbrookme@juno.com" References: <20090227.105308.6400.0@webmail06.vgs.untd.com> In-Reply-To: <20090227.105308.6400.0@webmail06.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:12:12 -0000 This did not get to the list and therefore I am including your complete email in my reply and keep my comments short. I do not intend to carry on this thread as (a) It does not really belong on this list (b) You are obviously not interested in anyone's point of view but your own. I have given you some friendly advice and you choose to criticise and ignore it. You twist peoples replies and are deliberately obtuse. On 27/02/2009 15:53, dyerbrookme@juno.com wrote: > I'm going to answer this on the list as I think off-list admonishments are inappropriate. > >> You seem to object to open source and I don't understand why. I use both closed an opensource products and I have no objection to paying for the closed source products I use as long as I get support for that product. > > I object to opensource exclusivity and the collectivist and forced-sharing mentality that goes along with it as any kind of norm. It's not a norm. The overwhelming majority of hundreds of millions of people use Microsoft or Apple operating systems, not Linux. This is why I often say "open source=closed society" -- because of the failure to ensure there is *choice* between collectivist and proprietary software and because of the notion that a project is "open" merely technically, although usually it is so complex and rigid in its cultural norms that it isn't really open in practice. Uhm. MAC OSX is a layer on top of Darwin. "Darwin is an open source POSIX-compliant computer operating system released by Apple Inc. in 2000. It is composed of code developed by Apple, as well as code derived from NEXTSTEP, FreeBSD, and other free software projects". >> I am sure that you are aware that without opensource you would not have SecondLife. The viewer that LL wrote comprises a lot of opensource products. > > This notion that you cannot criticize opensource mentality without being lectured with homilies like "Don't you know the Internet wouldn't be here today" etc. is silly. So what? It's only one form of property, not exclusively the norm, nor necessarily desirable. By itself, it does not ensure *the choice of commerce*. That's the problem. > >> The servers that LL use run on (openssource)Linux machines as does a large portion of the internet. > > And...so what? A goodly portion of the Internet *does not* run on Linuxness too. Without the commerce or the ebays and the amazons, there'd be no Internet *either*. And a large part of the consumer sector of IT *does not* run on Linux. So there. There is no need for us to genuflect constantly to the Linux cult in creating standards for the Metaverse. > >> People will always put forward unpopular ideas, it does not mean that > they will be adopted. Anyone involved in SecondLife, Opensimulator or > any any other similar product is fully aware of the necessity for a > system that allows (secure) trading. However there are many use cases > that this is not necessary and in fact having such a system mandated > would cause problems. > > This is a peculiar proposition indeed. Suddenly, there's an admission that concepts stripping out trading and commerce might be "unpopular". Say, there'd be a good reason for that! Because they are not the norm, nor reflective of the mass of human activity on the real world planet. The idea that in real life, you would never strip out trading or secure trading from any country unless you were way out on the extremes of say, a North Korea, doesn't seem to mitigate against your extremism. Just because there are purportedly "use cases" that dictate that trade is "not necessary" is hardly a reason to drop commerce completely from a system (I think such use cases would be in the distinct minority and your claim that there are "many" isn't proven). You choose to deliberately misrepresent what I said. > > It surely is odd that I would have to stump for you all to put commerce, trade, property rights and such into a virtual world system when every single one of you on this list benefits from commerce in some fashion, if not directly by working for profit-making companies that function in the real world in free enterprise systems that make your profit from selling technology, services, or entertainment -- or from universities that exist either on taxpayers' funds generated from commerce or from private foundation grants generated from the last centuries' wealth in industries. > > So I can only throw that back to you, the way you constantly and speciously throw at critics this notion that "OMGODZORZ the entire Internet is based on opensource and Linux so shut up already". > >> What David said was "..... for the moment, I'm going to keep those terms off the table to think about the problem in its more general form." > > Yes, a seemingly innocent, innocuous, practical, speculative sort of proposition that is "just for the prototyping" and "just for discussion" and "just to make it easy to conceptualize". > > And yet I point out that it is at this moment that all the tethered terms of avatar=person, property rights, geographic contiguity (the hatred of geographic contiguity by extremists often goes with the hatred of commerce for reasons I don't yet understand), etc. all begin to lose their moorings and we enter the realm of Extropia or the Bright Future of Communism. I so marked the moment. My purpose in so marking the moment wasn't to engage in lengthy political debates on a "list just here to talk about technology please" but to point out the particular moments when decisions about social systems get welded into the technological blueprint. For you, commerce is a model and an add-on. It isn't for the overwhelming majority of users of Second Life who are utterly unintersted in opensource sandboxing but exist in a RL versimilitude of consumer creation and commerce. > >> To me that does not say these terms and their implications are being > abandoned. It says we need to think in general terms before we look at > specifics and I totally agree with this. I am not adopting any ism or > ideology I am adopting a technique that assists it defining the outline before adding the detail and complexities that will eventually be necessary. > > Well, that's "to you" *shrugs*. I don't see it as "moving to general terms" but rather a profoundly disruptive, extremist, heavily ideological move, untethering the basic concepts of avatar, space, inventory, etc. from their > > You might say, "Good! The internet is about evolution! Embrace the inevitable! and all the other social Darwinisms we're always forced to endure from extremists. But it's not about having a political discussion. It's practical. It's saying, "Who's going to pay for this carnival ride, dude?" because you've stripped out commerce and invoked wacky notions of everybody generating soup out of stones and profit out of sharing as they goof off from their big IT jobs where they are paid for other mundane tasks. > >> Your arguments do not come across as logical they come across as wordy and, dare I say, aggressive. My interpretation is that commerce, currency, property and profit are at a level of abstraction that will be considered as the standards develop. > > Um, I'm awfully glad you have a felt need for detecting and berating aggressiveness. This is laudable on a list. I hope you will be an equal-opportunity applier of this laudable goal to the many other aggressive statements made on the list by people with decidedly ambitious agendas. > > Commerce, currency, property and *gasp* profit (the horrah!) are not abstractions, not tack-on modules, not afterthoughts, but should be at the heart of the system. If they aren't, you no longer have choice. You've scrubbed them out of the DNA at the start. That's wrong. The tack-on modules should be the minority worlds that want to have endless tekkie sandboxing and sharing. Not a single one of the opensim projects has any viable population; those that even have any participation have put in some form of commerce, even with their own internal currency. > >> Why would you think I was situated at the extreme? Nothing I said in my email suggested that. My point of view is that in this (virtual)world there is room for people at the copyleft end of the spectrum and at the "I am only in it for the money" plus all sahdes in between. I have a potential application for a virtual world, it will be a completely closed environment and it will not need any currency, trading or IP protection but will require interop between other instances of the application. I will earn my money/profit from the products I sell that are used with the application. > > You are situated at the extreme if you are unwilling to put in a list of the basic ingredients of a virtual world at the start the functions of trade, commerce, currency etc. that reflect an inherent proposition of private property. Why is that so scary? It ought to be normal in the course of things. Every single MMORPG designer in the entire universe puts trade and inventory and currency into their game without a blink of the eye. What happens to virtual world makers that they get all weird about doing this?! > > I fail to see, if you have an application for a closed non-currency, non-copyright world that interoperability with other worlds that *do* have currency and copyright would present any sort of problem, unless of course you were expecting them to pour all their content for free, without permissions, and without payment, into your world. It ought to be obvious from plenty of real-life examples and from the examples of incidents we already see happening with these virtual worlds: if you lay down a system of capitalism, a system of socialism can fork off from it; if you lay down a system of communism, a system of capitalism cannot fork off from it. > >> I agree with you here and what I am saying is (trying to be diplomatic) it is not necessarily what you say that is putting people off it is the way that you say it. It can come across as slightly aggressive and intimidating. I am not trying to offend you I am only trying to express my concern.On this list, I suggest that it may be better to put your views forward in a more succinct and logical manner. > > Once again, you're suggesting that there is something inherently illogical or logically fallacious about calling for commerce, currency, capitalism. But the illogic comes in fact with demanding the opposite. > >> Leave your other views on opensource and techno communism for your blog and we will all get along fine :-) > > I fail to see why I have to be driven off to my blog as if I've raised something completely wacky -- like the concept of Extropianism itself overrepresented on this list. It's very important for someone to speak up at the outset of the interoperability exercise and point out that choices are being lost, options are being stripped out, forced marches are being flogged because of a few who showed up, under the tyranny of those who show up, to insist on their own extremist vision. We're already suffering from that problem with the AWG/OGP which began their work by questioning the viability of currency in the design documents and raising a storm of questions about intellectual property. > > It's important to come out of the code cave and realize that virtual worlds are for masses of people. Masses of people don't like living under technocommunism. It's a closed niche that is attractive only for some. They are entitled to that choice. They should not impose it on everyone else. Chris From jwatte@gmail.com Fri Feb 27 09:40:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2513C28C13E for ; Fri, 27 Feb 2009 09:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kematgrpMhET for ; Fri, 27 Feb 2009 09:40:05 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id A6A4228C1DB for ; Fri, 27 Feb 2009 09:40:05 -0800 (PST) Received: by gxk22 with SMTP id 22so2855004gxk.13 for ; Fri, 27 Feb 2009 09:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hYorQ/8FJso4OkXgF0GT8zXMZykpHelVpL1D7b78sHo=; b=wdqU5VmWvh7qXKJC/EnILuWcQJTd9NH6c2hHS7XeYJ1xLspG0e0B8uwTdTt71sJzID pHZHQ+x6rakE4w9arM5SaZaMMwBHhOr6tfJHJ785OsqnOtRJtcHqd/wl/KIGHX9JCtIx PccjWg9rW37Z9U29nU/oc5Th9M9GCLP54S9uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=I+O/0dLe5a2B/IcQfatKaPyF7Lo7Wc67Hf7aP9L9hDhdJUfS1o6Bc+Hfj9S+0UhSXc YRkIGTU82V8X90/craPSLC19RwBr3JS1hK2E0z3ChLkHOwolfcphfl/dVKxM+T6FLuFc GZfP+gEo+ev3WuQBh5So1i2zJJdfPJE3MWJ/s= Received: by 10.100.132.4 with SMTP id f4mr418244and.16.1235756428203; Fri, 27 Feb 2009 09:40:28 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b32sm5400154ana.55.2009.02.27.09.40.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 09:40:27 -0800 (PST) Message-ID: <49A82588.6080708@gmail.com> Date: Fri, 27 Feb 2009 09:40:24 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Chris Down References: <49A7B3E3.8050703@alcor.co.uk> In-Reply-To: <49A7B3E3.8050703@alcor.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:40:07 -0000 Chris Down wrote: > On 26/02/2009 22:33, dyerbrookme@juno.com wrote: >> Once you change this to "Experience Space for Logged-on Entities in >> Persistent Viewing Zones with Transmissable Data" you are well on the >> way to -- well, some sort of ism or another, perhaps communism, >> perhaps Extropianism. > > This list is not a platform for your extreme political views. A lot of Please keep this civil. There is no need to call anyone's views "extreme," because, to the person in question, those views are correct, and other views are extreme. This list is not a platform for anyone's political views. This list is for defining a vendor neutral wire protocol to enable interoperability between virtual worlds. Because different virtual worlds have different approaches to IP protection, such a standard will necessarily have to support both the use case where the originating world *requires* strong DRM, and the use case where the originating world *requires* copyleft. Trying to interoperate between those two worlds wouldn't actually work out in the end, of course, unless there was an alternate middle ground substitution available somewhere. But, technically, I think we've already acknowledged the feasibility and requirement, so any more discussion on specific opinions about one or the other, or opinions about opinions, seem to be off topic. Sincerely, jw From infinity@lindenlab.com Fri Feb 27 09:41:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23E6828C335 for ; Fri, 27 Feb 2009 09:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrtrflVICFqX for ; Fri, 27 Feb 2009 09:41:13 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id B9A8228C1D6 for ; Fri, 27 Feb 2009 09:41:13 -0800 (PST) Received: from [192.168.1.10] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 19F863DBC460; Fri, 27 Feb 2009 09:41:36 -0800 (PST) Message-Id: <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Morgaine In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-1--248744736 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 09:41:32 -0800 References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com><53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com><49A7DC37.1050002@cox.net> X-Mailer: Apple Mail (2.930.3) Cc: lenglish5@cox.net, mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:41:15 -0000 --Apple-Mail-1--248744736 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit really? why is it of no interest to achieve interoperability between 2 or more worlds of a given type? On Feb 27, 2009, at 7:40 AM, Morgaine wrote: > On Fri, Feb 27, 2009 at 12:27 PM, Lawson English > wrote: > > My own take is that fragmenting the working group at this point is > counter-productive. We can > recognize several [types of] low-hanging fruit[s] that may apply to > many worlds or just 2 or more > of a given type (e.g. Second Life/OpenSIm compatible). > > > But it is of no interest to the MMOX group as a whole to achieve > interoperability between only 2 or more worlds of a given type. > Such progress would be great for the worlds concerned, but of no use > to anyone else. > > > There's no reason to assume that full interoperability can be > obtained amongst all worlds > in the same way, but no reason to assume we can't find points of > commonality which can > mix and match. > > > "Full interoperability" is not something that anyone has proposed, > so knocking it down is just a straw man. Instead, we've been > looking for ways to achieve some degree of interop by focusing on > just a few things that are common to virtually all worlds. A common > protocol that deals extensibly with those few things would be an > amazing achievement, but locking down the solution space even before > the group has a charter is not the way to go about it ... except in > a group dedicated to a specific solution. > > > The OGP has made a good start for authentication and TP > between OpenSim and Second Life, and OpenSim has come up with an > alternative called HyperGrid. > Our meeting on video streaming showed that there are points of inter- > operability between SL, OpenSim > and Croquet/Qwaq. Surely we can find others. To say: "let us split > the working group up from the start > into SL-compatible and incompatible worlds" assumes that we can find > no common ground at all. > > > Oh I'm fairly certain that we CAN find common ground in MMOX --- > indeed, that's the whole reason we're here. Unfortunately the > effort is derailed when one party requires that that all the "common > ground" has to be within their own solution space. > > The only reason I proposed a split is to get around the impasse of > what appears to be one entrenched position, so that everyone can > make good progress on all fronts to the benefit of all. If there > are no preconditions though, then of course we could continue to > search for natural common ground, and I have no reason to believe > that we would not succeed. > > The phrase "Where there's a will there's a way" is very germane > here. Given the will to move off one's own turf opens up numerous > avenues for finding common ground with others. > > > Morgaine. > > > > > > > > On Fri, Feb 27, 2009 at 12:27 PM, Lawson English > wrote: > Jesrad wrote: > Heartily seconded, there are lots of divergent interests that would > hamper the broad adoption of the protocol if we tried to include too > many things, just as well as including too little would severly limit > the interest of the whole thing for the end users. > > Which makes me think we might need to tag some of the features as > optional. > > On Fri, Feb 27, 2009 at 10:49 AM, Morgaine > wrote: > > Well said, Heiner. Conflating the two quite separate interests > into just > one is not helping progress in either direction at the moment. > > Morgaine. > > > > > > My own take is that fragmenting the working group at this point is > counter-productive. We can > recognize several [types of] low-hanging fruit[s] that may apply to > many worlds or just 2 or more > of a given type (e.g. Second Life/OpenSIm compatible). > > In other words, here's more than one possible sub-tree these inter- > operable fruits are hanging from and > it is likely more like a digraph than a simple tree (who knows, > possibly not merely a digraph either if > there are dependencies that go back up the "tree"). > > E.G.: > > Interoperability scenarios for virtual worlds > | > ------------------------------------------------------------------------- > | | > > Authentication for SL-type worlds Authentication of Other > worlds > / | > \ / | \ > -------------------------------------------------------- > [...] etc > | | > | / ] \ > Agent Domain HyperGrid Something Else > > > > > At the same level we might search for alternate ways of: > > expressing basic protocols > > LLSD vs xxSD vs ... > > or of geometry: > > OBJ vs SL-extended prims vs Callada vs world-specific terrains/... > > or of group IM: > > SL-style vs javbber vs irc vs... > > Etc. > > > There's no reason to assume that full interoperability can be > obtained amongst all worlds > in the same way, but no reason to assume we can't find points of > commonality which can > mix and match. > > The OGP has made a good start for authentication and TP > between OpenSim and Second Life, and OpenSim has come up with an > alternative called HyperGrid. > Our meeting on video streaming showed that there are points of inter- > operability between SL, OpenSim > and Croquet/Qwaq. Surely we can find others. To say: "let us split > the working group up from the start > into SL-compatible and incompatible worlds" assumes that we can find > no common ground at all. > > > > > I think that is the wrong way to go. > > > Lawson > > > > > > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-1--248744736 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable really?

why = is it of no interest to achieve interoperability between 2 or more = worlds of a given type?

On Feb 27, = 2009, at 7:40 AM, Morgaine wrote:

On Fri, Feb 27, 2009 at 12:27 PM, Lawson English = <lenglish5@cox.net> = wrote:
 
My own take is that = fragmenting the working group at this point is counter-productive. We = can
recognize several [types of] low-hanging fruit[s] that may apply = to many worlds or just 2 or more
of a given type (e.g. Second = Life/OpenSIm compatible).


But it is of no = interest to the MMOX group as a whole to achieve = interoperability between only 2 or more worlds of a given type.  = Such progress would be great for the worlds concerned, but of no use to = anyone else.


There's no reason to assume that = full interoperability can be obtained amongst all worlds
in the same = way, but no reason to assume we can't find points of commonality which = can
mix and match.


"Full interoperability" = is not something that anyone has proposed, so knocking it down is just a = straw man.  Instead, we've been looking for ways to achieve = some degree of interop by focusing on just a few things that are = common to virtually all worlds.  A common protocol that deals = extensibly with those few things would be an amazing achievement, but = locking down the solution space even before the group has a charter is = not the way to go about it ... except in a group dedicated to a specific = solution.


The OGP has made a good start for = authentication and TP
between OpenSim and Second Life, and OpenSim = has come up with an alternative called HyperGrid.
Our meeting on = video streaming showed that there are points of inter-operability = between SL, OpenSim
and Croquet/Qwaq. Surely we can find others. To = say: "let us split the working group up from the start
into = SL-compatible and incompatible worlds" assumes that we can find no = common ground at all.


Oh I'm fairly certain that we = CAN find common ground in MMOX --- indeed, that's the whole = reason we're here.  Unfortunately the effort is derailed when one = party requires that that all the "common ground" has to be within their = own solution space.

The only reason I proposed a = split is to get around the impasse of what appears to be one entrenched = position, so that everyone can make good progress on all fronts to the = benefit of all.  If there are no preconditions though, then of = course we could continue to search for natural common ground, and I have = no reason to believe that we would not succeed.

The phrase = "Where there's a will there's a way" is very germane here.  Given = the will to move off one's own turf opens up numerous avenues for = finding common ground with others.


Morgaine.
=






On Fri, Feb 27, = 2009 at 12:27 PM, Lawson English <lenglish5@cox.net> = wrote:
Jesrad wrote:
Heartily seconded, = there are lots of divergent interests that would
hamper the broad = adoption of the protocol if we tried to include too
many things, = just as well as including too little would severly limit
the = interest of the whole thing for the end users.

Which makes me = think we might need to tag some of the features as optional.

On = Fri, Feb 27, 2009 at 10:49 AM, Morgaine
<morgaine.dinova@googlemail.com> wrote:
=  
Well said, Heiner.   Conflating the two quite separate = interests into just
one is not helping progress in either direction = at the moment.

Morgaine.


   
=


My own take is that = fragmenting the working group at this point is counter-productive. We = can
recognize several [types of] low-hanging fruit[s] that may apply = to many worlds or just 2 or more
of a given type (e.g. Second = Life/OpenSIm compatible).

In other words, here's more than one = possible sub-tree these inter-operable fruits are hanging from and
= it is likely more like a digraph than a simple tree (who knows, possibly = not merely a digraph either if
there are dependencies that go back = up the "tree").

E.G.:

Interoperability scenarios for = virtual worlds
              =           |
= -------------------------------------------------------------------------<= br>                   =       |               =                     =        |

Authentication for SL-type worlds =          Authentication of Other worlds
=                     =         /  |  \       =                     =                     =     /  |   \     = --------------------------------------------------------   [...] =                 etc
|   =                     =         |             =            |         =                     =            / ] \
Agent Domain   =   HyperGrid      Something Else



=
At the same level we might search for alternate ways of:

= expressing basic protocols

LLSD vs xxSD vs ...

or =  of geometry:

OBJ vs SL-extended prims vs Callada vs = world-specific terrains/...

or of group IM:

SL-style = vs javbber vs irc vs...

Etc.


There's no reason to = assume that full interoperability can be obtained amongst all worlds
= in the same way, but no reason to assume we can't find points of = commonality which can
mix and match.

The OGP has made a = good start for authentication and TP
between OpenSim and Second = Life, and OpenSim has come up with an alternative called HyperGrid.
= Our meeting on video streaming showed that there are points of = inter-operability between SL, OpenSim
and Croquet/Qwaq. Surely we = can find others. To say: "let us split the working group up from the = start
into SL-compatible and incompatible worlds" assumes that we = can find no common ground at all.




I think that = is the wrong way to go.


Lawson
=







= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mmox

= --Apple-Mail-1--248744736-- From jwatte@gmail.com Fri Feb 27 09:49:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A9028C34D for ; Fri, 27 Feb 2009 09:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHE-sJ0pK5+W for ; Fri, 27 Feb 2009 09:49:47 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 0D61928C362 for ; Fri, 27 Feb 2009 09:49:43 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b2so1086958ana.4 for ; Fri, 27 Feb 2009 09:50:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8JXN8u3B89d3pU4LOrlXJ5WZ5cPTPzMv/ENDFUHg5SI=; b=pk0lfaXYovYBUu4e9+7S/HWsDan3nZsGw3Y6K8gO2SRRwdvwGLYncK5fE06/bb++4N /87Za7jnvBXD4E9FypriHqF0wKmV5dLZR8g2Zg8em3M1a6fqKNQnBkteJB4V8nO05jE0 Hno1C6iwBydzV/vOMxLcxfn7W1lsK6qRYMA5M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wBXgt2SSmRVIPkYTIbLYBrFs2NYmwpQisn28hH2lXd2IUvXSf0yUUHCfdjaHNSZQF/ vVmYTbCTYcL9Jo7JB6x8R6qqRWBGJpjcRPJSZwPoBQlDRDBzx1gwKGVGMioHmFybQTxt WWDvq0zPGfmURdfPBOfJ1vOClS4Jq5kflyn60= Received: by 10.100.127.18 with SMTP id z18mr2927464anc.6.1235757005843; Fri, 27 Feb 2009 09:50:05 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c40sm5277918anc.48.2009.02.27.09.50.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 09:50:05 -0800 (PST) Message-ID: <49A827CB.4030600@gmail.com> Date: Fri, 27 Feb 2009 09:50:03 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jesrad References: <49A736AA.2020205@gmail.com> <4EC4C999-59E9-49BF-99C0-82ED4BBD9A64@lindenlab.com> <53cd6c2e0902270316j36df5b42qd319d9103fce3976@mail.gmail.com> In-Reply-To: <53cd6c2e0902270316j36df5b42qd319d9103fce3976@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Use cases? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:49:48 -0000 Jesrad wrote: > The use cases certainly help focus on the "meat" of the protocol, > however they can also easily miss entire domains of application for > the protocol, so they won't be the sole source for listing > > I don't quite understand this statement. It sounds to me as if you believe there are intended uses for a protocol that you cannot describe a use case for. That sounds a little oxymoronic to me -- if you have an intended use, that is per definition a use case. Note that I do not believe my 5 use cases are the end-all of virtual world interoperability; just an illustration of what I believe the low-hanging "actually useful" fruit would be. Please contribute more use cases if you have other intended uses! > That poses a problem: not all VWs will be interested in sharing all > their features cross-grid, nor even all the features they have in > common with other VWs, so I think the MMOX protocol needs to define > levels of partial compliance, possibly in the form of a dependencies > tree. I believe making sure some interoperability is sufficient while > not mandating all-inclusive interoperability will appeal more to the > "big players" that are still not represented in this group. > > I don't think any mandate can be done. Even with a standard protocol, you can choose to not provide certain information. For example, a HTTP server can choose to not serve a given document, either by sending a 404 not found, or a 401 denied, or some other method. > So I suggest use-cases only come after we get a good idea of what > features' PDUs the protocol will transport, and how they might be > I think that's putting the cart before the horse. The use cases define what we actually need to work towards. If there is no use case for a feature, that means there's no reason to implement it, because nobody will use it. Meanwhile, if you don't have use cases, then you can't tease out what things you actually ought to be building. Note that use cases are all about *what* you build, though -- not *how* you build it, which I feel is what you're trying to get at. De-coupling and separability (as you describe) are all very useful traits in a technical design, but are all about the "how," not the "what." Sincerely, jw From jwatte@gmail.com Fri Feb 27 09:57:32 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B199C28C362 for ; Fri, 27 Feb 2009 09:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGE8z5eQcOlY for ; Fri, 27 Feb 2009 09:57:31 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 9DBFD28C354 for ; Fri, 27 Feb 2009 09:57:31 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so1504151ywh.49 for ; Fri, 27 Feb 2009 09:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=EYN2YgdQgIsm9T5ryaOYwKqsxSreFHbc+IMMVNnEl9Y=; b=qAecbAaqXJSDSLd+lflV/+Ve4Pg37Xz0/FVY6F5SEWiGGKiTABJOk2rjPbo/l9w1OJ r2xbwGGttu87UnBddcL0vkt5ye7GvcnwKKDz6stTEwkXq/Eo+2X/em5Uu17WHhzYjL3p Krv9rMiviEnTLHpbdiegZuEP+/2eI/jNcdrt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qn7XwKpMl4sl8/yx/vOPK9fUFDA68iTu6rxC66TtifrAqYqM1VDrFZgIK4s5I5kmZI Bb6p+l/pnxmP9Va0brJSYZQaE1GsHv+fkUiXRi25/vftBMF2mH9356xMi/vAU59IGorw Mr2ZaCuyLmYnbtL1bUULeCB3zRUbCWw99P3Gg= Received: by 10.100.111.5 with SMTP id j5mr2901033anc.54.1235757474067; Fri, 27 Feb 2009 09:57:54 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d35sm9182801and.38.2009.02.27.09.57.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 09:57:53 -0800 (PST) Message-ID: <49A8299F.1020904@gmail.com> Date: Fri, 27 Feb 2009 09:57:51 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Catherine Pfeffer References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Keys as numbers in the binary format ; two different protocols X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:57:32 -0000 Catherine Pfeffer wrote: > > > - it would be less simple in a program because you would need to > look > > > up in a table to solve the indirections > > > > I don't think that's intellectually honest. > > Don't call me dishonest. > To nit pick, I didn't call you dishonest ("I don't think you are ..."), I called the argument dishonest ("I don't think that's ..."). I have not seen any reason to believe you are anything but an upstanding, smart, helpful intellectual. Please accept my apologies if you inferred something else from my statement. > > > - if you have been unable to transmit the packet containing the > > > table, you can't do anything anymore > > > > If I can't send data, I can't send data, that's right! If I can't send > > data, why am I trying to do a live, real-time streaming application > anyway? > > I disagree on this one. It is one thing to lose a given packed that > would prevent your avatar from receiving an IM message or from moving > 10 centimeters to the right, and it is another thing to fail receiving > a list of numbers that would allow you to decode the entire session. > That's probably the showstopper point. > If some data has to be transmitted before you can continue with the session, then the session protocol has to make sure that that data is transmitted. Easiest is of course to run the session through TCP. If, for some reason, you don't want the data queuing/delay semantic of TCP, there are various "reliable over UDP" options you could implement. An alternative is also to send the required set-up data using TCP (say, when establishing a session), and using a separate UDP channel for lossy real-time data. In other words: your argument says that we have to be careful in implementation, but it doesn't say that implementation has to be impossible, or even hard. > > Now is it really a good idea to make both systems derive of the binary > serialization? Probably not. As I see it, LLSD is really fit to real > time data, but its XML serialization, at least in its current state, > is not what I would call "properly structured" for all the reasons > that I already explained. > And I think LLSD doesn't fit real-time data, because it is too verbose to send the tag and type for each and every piece of data, when you can omit it with no loss of generality. I believe, like you, that deriving everything from the binary serialization is not the best approach. I believe that you should start with a description of the data you need in the abstract, and then separately derive efficient binary representations, and durable XML representations, from that description. That allows you to keep the data description in one place, which is important to avoid versioning de-sync, and it also allows you to design each serialization to fit the particular format. > Having two different systems would also remove the problem of > negotiation. Real time data would be binary encoded, transactional > data would be XML encoded (SOAP, XML-RPC, whatever). Different class > of problems, different encodings, so there's nothing to negociate. > I fully agree with this. Each service would be defined in terms of which serialization it uses. Meanwhile, having a common "root" format for describing the data you want to exchange means you don't have to worry about double development, version slew, etc. The format would necessarily need to have enough information in it such that a good XSD and a good binary serialization could both be generated. Sincerely, jw From jwatte@gmail.com Fri Feb 27 09:59:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05EC028C36F for ; Fri, 27 Feb 2009 09:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxm3L-rDXG6T for ; Fri, 27 Feb 2009 09:59:02 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 4489C28C363 for ; Fri, 27 Feb 2009 09:59:02 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1509029yxm.49 for ; Fri, 27 Feb 2009 09:59:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/+fbpvtGuYil25UfX5W22smWGvNrRT2CJX3LxIWWMuA=; b=JyAeu3+ZON/17aN5F57sV2ozWYdk5YvhF3zKej+Vr2tBuAiOT/vB5vvnYTR2Eipz6E /8Ukdnz4jeBeLQBbcyklBMWHQUe10voV5ei9sYyJ+0EOozgosjm3YUSxTxkBVMkucFMQ Vnd4YkfFWiTGCcTTrStrv5rfSk3Oax2BW03mg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cjgWAvzZSk5s5NrayuAfCBsJu80BZuoO/5VNtKYjyRiKaIJ/aEni1QcXJH3bRHZPuL Z3DHL1NWZfMgwSaBfjy5KYa5ji/CvzbvFH3WJe67FHwKGoX6Ykm0RyovpURSiXe67UI0 xLqq4pEsxQX5jYHnnmhE/JZoI/MBocpvQ0USU= Received: by 10.100.133.2 with SMTP id g2mr2857902and.134.1235757564607; Fri, 27 Feb 2009 09:59:24 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b7sm5587509ana.19.2009.02.27.09.59.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 09:59:23 -0800 (PST) Message-ID: <49A829FA.9010500@gmail.com> Date: Fri, 27 Feb 2009 09:59:22 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> In-Reply-To: <49A7DC37.1050002@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 17:59:03 -0000 Lawson English wrote: > My own take is that fragmenting the working group at this point is > counter-productive. We can > recognize several [types of] low-hanging fruit[s] that may apply to > many worlds or just 2 or more > of a given type (e.g. Second Life/OpenSIm compatible). The charter for the group is vendor neutral interoperability. If you want to design a Second-Life-derived protocol under this group, then I cannot support the group, for pretty obvious reasons, and I believe it would reflect very negatively on the sponsors of the group to go against the charter. Sincerely, jw From lenglish5@cox.net Fri Feb 27 10:06:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C4228C34F for ; Fri, 27 Feb 2009 10:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.877 X-Spam-Level: X-Spam-Status: No, score=0.877 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCkLXfnUOKah for ; Fri, 27 Feb 2009 10:06:06 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 05AD628C344 for ; Fri, 27 Feb 2009 10:06:05 -0800 (PST) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090227180629.PGHA10385.fed1rmmtao107.cox.net@fed1rmimpo02.cox.net>; Fri, 27 Feb 2009 13:06:29 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id M66U1b00G4N6T0Q0466Unk; Fri, 27 Feb 2009 13:06:28 -0500 X-Authority-Analysis: v=1.0 c=1 a=H7oVHkRPDCcA:10 a=xj0JfVIbDmkA:10 a=Wajolswj7cQA:10 a=eiicDBvxwccPVodv_ZoA:9 a=-Lu17fcjJYMp6T7e4huluLEAYNUA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <49A82BA4.1090006@cox.net> Date: Fri, 27 Feb 2009 11:06:28 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <49A829FA.9010500@gmail.com> In-Reply-To: <49A829FA.9010500@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:06:06 -0000 Jon Watte wrote: > Lawson English wrote: >> My own take is that fragmenting the working group at this point is >> counter-productive. We can >> recognize several [types of] low-hanging fruit[s] that may apply to >> many worlds or just 2 or more >> of a given type (e.g. Second Life/OpenSIm compatible). > > The charter for the group is vendor neutral interoperability. If you > want to design a Second-Life-derived protocol under this group, then I > cannot support the group, for pretty obvious reasons, and I believe it > would reflect very negatively on the sponsors of the group to go > against the charter. > Hmmmm.... So you're insisting that we design a one-size fits all protocol. Does this mean that the OGP between SL and OpenSim can't be endorsed as a special case of the mmox interoperability protocols? Lawson From lenglish5@cox.net Fri Feb 27 10:20:12 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883843A683E for ; Fri, 27 Feb 2009 10:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeS-RTSmSH88 for ; Fri, 27 Feb 2009 10:20:11 -0800 (PST) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id A112B3A67D4 for ; Fri, 27 Feb 2009 10:20:11 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090227182035.UAPD12540.fed1rmmtao106.cox.net@fed1rmimpo01.cox.net>; Fri, 27 Feb 2009 13:20:35 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id M6LZ1b00U4N6T0Q036LaTS; Fri, 27 Feb 2009 13:20:34 -0500 X-Authority-Analysis: v=1.0 c=1 a=H7oVHkRPDCcA:10 a=xj0JfVIbDmkA:10 a=Wajolswj7cQA:10 a=y_Y_fkRGQTXaV36_BNsA:9 a=9Uu4VIi0U5O9V9IVvl9MYSb0ExkA:4 a=zUBsD6tbDSsA:10 X-CM-Score: 0.00 Message-ID: <49A82EF1.5070006@cox.net> Date: Fri, 27 Feb 2009 11:20:33 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Jon Watte References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <49A829FA.9010500@gmail.com> In-Reply-To: <49A829FA.9010500@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:20:12 -0000 Jon Watte wrote: > Lawson English wrote: >> My own take is that fragmenting the working group at this point is >> counter-productive. We can >> recognize several [types of] low-hanging fruit[s] that may apply to >> many worlds or just 2 or more >> of a given type (e.g. Second Life/OpenSIm compatible). > > The charter for the group is vendor neutral interoperability. If you > want to design a Second-Life-derived protocol under this group, then I > cannot support the group, for pretty obvious reasons, and I believe it > would reflect very negatively on the sponsors of the group to go > against the charter. > > Sincerely, > There are many possibilities here, IMHO: at one extreme, there are worlds that can interop intimately with little modification, such as Second LIfe and OpenSIm, and at the other, there likely will be needed a lot more intermediate plumbing to make things work. At the lowest level, the interop protocol of MMOX shouldn't assume how much, if any, plumbing is required and allow the client/Agent Domain/whatever to determine the specific needs for interop on-the-fly. More specific protocols can be devised to handle general cases, specific cases, whatever, but to insist that one-size fits all beyond establishing a standard way to figure out what is needed for interop between any 2 specific worlds is to ignore that virtual worlds are rather varied in their implementation and functionality and some are more compatible than others. Laawson From missannotoole@yahoo.com Fri Feb 27 10:49:03 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FF428C38A for ; Fri, 27 Feb 2009 10:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alS52ve5MMGU for ; Fri, 27 Feb 2009 10:49:02 -0800 (PST) Received: from web59103.mail.re1.yahoo.com (web59103.mail.re1.yahoo.com [66.196.101.14]) by core3.amsl.com (Postfix) with SMTP id 2E2A328C381 for ; Fri, 27 Feb 2009 10:49:02 -0800 (PST) Received: (qmail 41375 invoked by uid 60001); 27 Feb 2009 18:49:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1235760564; bh=fG1JYG0ze30UkU9ZiySs0IJXEwt56VNF7BmyT9fpB6o=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=NqxSNVtIRw1DhursWu+U7697Wf2pfkDH/KeLM4wNqShPNY0Gdos8Sf6uEukvxL2WPZBOb2eDfpdBaZR+azLYIQ7AEB/ej/uBgSXsbHIPebZP3E44wW1E+nU7O/gPfcILMt+DWhcxB9JD/NsEaeumfWcCFn94P9s0KaBKoUGDsz4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tmoI8/ZfKo+8CkKkFffqDCeTT07eEmIRhimgK78wqt4As4cI2IrdOcqVEP6uqJ0sro1OiUNDBoItf9/eiRhQ2SSXSshW0dS40jWpOxiBLNoJfaoCcKa6vuAEdkwoa4fOu+nDiaoj2obnGPWQVGoOMTiu2PdLEOIwFThBBIOE5FU=; Message-ID: <760397.41366.qm@web59103.mail.re1.yahoo.com> X-YMail-OSG: 3NqYaBIVM1mpoDdmFF_QAqKzplQel2LbN1sa196Qy9f_gquwxm.JpTp7M4ggiLITwRfBAfpay0RXHvdD4Qdp7z.xIryQGRA.8i09gkiRmDqNTqeOb3cP1peIfFVPmQLzJe6cjUfNY0BDx6UikDNEK0hxn4UsCfZKicLo35pcNcRaSWlH1Ow3C3aqFlvo35rm0J.bzmFxpq_W7TRpQPLs07AZ.nB5 Received: from [97.102.254.236] by web59103.mail.re1.yahoo.com via HTTP; Fri, 27 Feb 2009 10:49:24 PST X-Mailer: YahooMailRC/1277.29 YahooMailWebService/0.7.289.1 References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <49A829FA.9010500@gmail.com> <49A82BA4.1090006@cox.net> Date: Fri, 27 Feb 2009 10:49:24 -0800 (PST) From: Ann Otoole To: lenglish5@cox.net, Jon Watte In-Reply-To: <49A82BA4.1090006@cox.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1367445507-1235760564=:41366" Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:49:03 -0000 --0-1367445507-1235760564=:41366 Content-Type: text/plain; charset=us-ascii Perhaps the focus needs to be on public worlds and people with worlds that, by their very nature, will never interop anyway, really should back off unless their respective companies have at least one public access virtual world,. Why should this group involve itself with closed access worlds where no interop will ever happen anyway because of the danger of espionage? The blade cuts both ways. Just a thought. From: Lawson English To: Jon Watte Cc: mmox@ietf.org Sent: Friday, February 27, 2009 1:06:28 PM Subject: Re: [mmox] Chartering for requirements only Jon Watte wrote: > Lawson English wrote: >> My own take is that fragmenting the working group at this point is counter-productive. We can >> recognize several [types of] low-hanging fruit[s] that may apply to many worlds or just 2 or more >> of a given type (e.g. Second Life/OpenSIm compatible). > > The charter for the group is vendor neutral interoperability. If you want to design a Second-Life-derived protocol under this group, then I cannot support the group, for pretty obvious reasons, and I believe it would reflect very negatively on the sponsors of the group to go against the charter. > Hmmmm.... So you're insisting that we design a one-size fits all protocol. Does this mean that the OGP between SL and OpenSim can't be endorsed as a special case of the mmox interoperability protocols? Lawson _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --0-1367445507-1235760564=:41366 Content-Type: text/html; charset=us-ascii
Perhaps the focus needs to be on public worlds and people with worlds that, by their very nature, will never interop anyway, really should back off unless their respective companies have at least one public access virtual world,. Why should this group involve itself with closed access worlds where no interop will ever happen anyway because of the danger of espionage?

The blade cuts both ways.

Just a thought.


From: Lawson English <lenglish5@cox.net>
To: Jon Watte <jwatte@gmail.com>
Cc: mmox@ietf.org
Sent: Friday, February 27, 2009 1:06:28 PM
Subject: Re: [mmox] Chartering for requirements only

Jon Watte wrote:
> Lawson English wrote:
>> My own take is that fragmenting the working group at this point is counter-productive. We can
>> recognize several [types of] low-hanging fruit[s] that may apply to many worlds or just 2 or more
>> of a given type (e.g. Second Life/OpenSIm compatible).
>
> The charter for the group is vendor neutral interoperability. If you want to design a Second-Life-derived protocol under this group, then I cannot support the group, for pretty obvious reasons, and I believe it would reflect very negatively on the sponsors of the group to go against the charter.
>

Hmmmm....


So you're insisting that we design a one-size fits all protocol. Does this mean that the OGP between SL and OpenSim can't be endorsed as a special case of the mmox interoperability protocols?


Lawson
_______________________________________________
mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox

--0-1367445507-1235760564=:41366-- From jwatte@gmail.com Fri Feb 27 10:55:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D27528C397 for ; Fri, 27 Feb 2009 10:55:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXQY08RhWZSd for ; Fri, 27 Feb 2009 10:55:40 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 5E54528C396 for ; Fri, 27 Feb 2009 10:55:40 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so1533116ywh.49 for ; Fri, 27 Feb 2009 10:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=WI5zgCedtD2YR6oKtKdXOPsrGvPc4UOckv8v+jEs6xk=; b=Oepolg/Dldxf0IVNtBY2D/sAQUVA3CUP1VCfOJEGU/eZyJPHhZ3tE095eHjtbIu3wK bXaBLrQZTNyCGg2nlP3pRHo/h9REtPdtWXpaC2WjQj6S3s+w3FgPomVhC4xT1FEXzW0o bCAqC6kuysHIGcMN0l4vrerb2mUaPPyPudGW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=oE5/K1UxKHd1UY7kyXPtmTifoa6CDQfplggMKl4jbfH5Qp0yUnrQCaNJfzo41SDzfq vDxy4X+63xFbu7psRcZ5Zv0cGgAZy/IaLiwy2PR9BueDf3MajLx+RCHhJT8kxoYL5Euf 1OV8AdZrVLyq2nZUp48Fz+zsCnHRph3vo+HBw= Received: by 10.101.67.11 with SMTP id u11mr2123842ank.121.1235760962753; Fri, 27 Feb 2009 10:56:02 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b14sm6694848ana.56.2009.02.27.10.56.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 10:56:02 -0800 (PST) Message-ID: <49A83740.5090003@gmail.com> Date: Fri, 27 Feb 2009 10:56:00 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com><53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com><49A7DC37.1050002@cox.net> <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> In-Reply-To: <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lenglish5@cox.net, mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 18:55:41 -0000 Meadhbh Hamrick (Infinity) wrote: > > why is it of no interest to achieve interoperability between 2 or more > worlds of a given type? > It is not of interest to a vendor neutral standard to achieve interoperability between two worlds that use a vendor-derived approach. It may be interesting as a case study, and it may be interesting in and of itself in a forum dedicated to such interoperability, but the explicit "vendor neutral" part of the charter seems like it would move such interoperability outside the purview of this group. Sincerely, jw From jwatte@gmail.com Fri Feb 27 11:03:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D7928C122 for ; Fri, 27 Feb 2009 11:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub-9LBfvwsIn for ; Fri, 27 Feb 2009 11:03:37 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 512BD3A69E3 for ; Fri, 27 Feb 2009 11:03:37 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1540877yxm.49 for ; Fri, 27 Feb 2009 11:04:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NCDVZmdXdOObGQ1pZBGeceWMT/Zxxc1QmSTxz28GVRg=; b=xhu4FAmy57NlMaqXHfzWjzBTp7HiVW92I7IVWY1RhweI8DrXT572T4FP9Xw0OsX6sG WxOEf5x2cIi1V7eRG2GmGwr0uoOm9WnL0AF7TiwUPnflVVIMmWcvM4HoSJ2cBUreRNwP C0vL30C3fhPTL+vRnQsWfr4+0lfXyzb2hmblc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=sMNDvRyls8bM0YnTmY/9xTq5l8EGa13T2I7POJoo70gCAScJnJsE3ZX3z0HADQXtpr FNmhD3cTBxPWscF+MQeodEJjU6swdDydrISQ+0eocfVADnUYE4o1QZ9eulQ+awFsCgCf mPxyj72WhzZNId7A93nTTq0uy77irC8yn8O3c= Received: by 10.100.154.17 with SMTP id b17mr623673ane.120.1235761439926; Fri, 27 Feb 2009 11:03:59 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b29sm5487077ana.31.2009.02.27.11.03.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 11:03:59 -0800 (PST) Message-ID: <49A8391D.9020409@gmail.com> Date: Fri, 27 Feb 2009 11:03:57 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <49A829FA.9010500@gmail.com> <49A82BA4.1090006@cox.net> In-Reply-To: <49A82BA4.1090006@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:03:38 -0000 Lawson English wrote: > So you're insisting that we design a one-size fits all protocol. Does > this mean that the OGP between SL and OpenSim can't be endorsed as a > special case of the mmox interoperability protocols? One-size-fits-all sounds rather loaded. I want a protocol that seeks a "common ground" model that is guaranteed to be able to interoperate to the level of capability that each virtual world may have. The problem with the Second Life protocol, and indeed OGP in general, is that it assumes the Second Life approach to simulation, avatar management, object representation, etc, which according to Second Life themselves is "different from how everyone else does it." (And I would agree). I can't see how that could be moved into a "common ground," open, vendor neutral standard. Sincerely, jw From RGehorsam@forterrainc.com Fri Feb 27 11:04:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890FD28C175 for ; Fri, 27 Feb 2009 11:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m40UBLgRRfIM for ; Fri, 27 Feb 2009 11:04:26 -0800 (PST) Received: from smtp.forterrainc.com (smtp.forterrainc.com [208.64.184.34]) by core3.amsl.com (Postfix) with ESMTP id 7BB443A69E3 for ; Fri, 27 Feb 2009 11:04:26 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9990E.65C33F7A" Date: Fri, 27 Feb 2009 11:04:47 -0800 Message-ID: <9A27EF31A4DF2C4C8BB45D661B13BA8705408177@MERCURY.forterrainc.com> In-Reply-To: <760397.41366.qm@web59103.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mmox] Chartering for requirements only thread-index: AcmZDEEtG4iO+RwZRoGKhFIkdkmukAAARH1g References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com><53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com><49A7DC37.1050002@cox.net> <49A829FA.9010500@gmail.com><49A82BA4.1090006@cox.net> <760397.41366.qm@web59103.mail.re1.yahoo.com> From: "Robert Gehorsam" To: "Ann Otoole" , , "Jon Watte" Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:04:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9990E.65C33F7A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ann, =20 I understand your concerns/fears, etc., but there's a larger context. It's possible -- essential, really -- to envision worlds that are private (meaning, run by companies for their own employees' utility) that also need to connect to other private worlds....partners, customers, industry/trade organizations, etc. In fact, broadly speaking, this may be the area where interoperability is most valuable. Parts of the US or state or local governments would clearly have that as well. For example, the Department of Education may have its own virtual world, and want to connect it to virtual worlds operated by the National Science Foundation and the American Federation of Teachers. =20 This broad scenario is certainly the one that interests me the most. =20 So public worlds (meaning, really, "consumer" worlds) are just one category of virtual worlds where interoperability is important. But private <---> private and private <---->public are also critical components. =20 Robert ________________________________ From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of Ann Otoole Sent: Friday, February 27, 2009 1:49 PM To: lenglish5@cox.net; Jon Watte Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only Perhaps the focus needs to be on public worlds and people with worlds that, by their very nature, will never interop anyway, really should back off unless their respective companies have at least one public access virtual world,. Why should this group involve itself with closed access worlds where no interop will ever happen anyway because of the danger of espionage? The blade cuts both ways. Just a thought. From: Lawson English To: Jon Watte Cc: mmox@ietf.org Sent: Friday, February 27, 2009 1:06:28 PM Subject: Re: [mmox] Chartering for requirements only Jon Watte wrote: > Lawson English wrote: >> My own take is that fragmenting the working group at this point is counter-productive. We can >> recognize several [types of] low-hanging fruit[s] that may apply to many worlds or just 2 or more >> of a given type (e.g. Second Life/OpenSIm compatible). >=20 > The charter for the group is vendor neutral interoperability. If you want to design a Second-Life-derived protocol under this group, then I cannot support the group, for pretty obvious reasons, and I believe it would reflect very negatively on the sponsors of the group to go against the charter. >=20 Hmmmm.... So you're insisting that we design a one-size fits all protocol. Does this mean that the OGP between SL and OpenSim can't be endorsed as a special case of the mmox interoperability protocols? Lawson _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox ------_=_NextPart_001_01C9990E.65C33F7A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ann,
 
I understand your concerns/fears, etc., but there's = a larger=20 context.  It's possible -- essential, really -- to envision = worlds=20 that are private (meaning, run by companies for their own employees' = utility)=20 that also need to connect to other private worlds....partners, = customers,=20 industry/trade organizations, etc.  In fact, broadly speaking, this = may be=20 the area where interoperability is most valuable.  Parts of the US = or state=20 or local governments would clearly have that as well.  For example, = the=20 Department of Education may have its own virtual world, and want to = connect it=20 to virtual worlds operated by the National Science Foundation and the = American=20 Federation of Teachers.
 
This broad scenario is certainly the one that interests = me the=20 most.
 
So public worlds (meaning, really, "consumer" worlds) are = just one=20 category of virtual worlds where interoperability is important.  = But=20 private <---> private and private  <---->public are = also=20 critical components.
 
Robert

From: mmox-bounces@ietf.org=20 [mailto:mmox-bounces@ietf.org] On Behalf Of Ann = Otoole
Sent:=20 Friday, February 27, 2009 1:49 PM
To: lenglish5@cox.net; Jon=20 Watte
Cc: mmox@ietf.org
Subject: Re: [mmox] = Chartering for=20 requirements only

Perhaps the focus needs to be on public worlds and people with = worlds that,=20 by their very nature, will never interop anyway, really should back off = unless=20 their respective companies have at least one public access virtual = world,. Why=20 should this group involve itself with closed access worlds where no = interop will=20 ever happen anyway because of the danger of espionage?

The blade = cuts=20 both ways.

Just a thought.


From: Lawson=20 English <lenglish5@cox.net>
To: Jon Watte=20 <jwatte@gmail.com>
Cc:=20 mmox@ietf.org
Sent: = Friday,=20 February 27, 2009 1:06:28 PM
Subject: Re: [mmox] Chartering = for=20 requirements only

Jon Watte wrote:
> Lawson English=20 wrote:
>> My own take is that fragmenting the working group at = this=20 point is counter-productive. We can
>> recognize several [types = of]=20 low-hanging fruit[s] that may apply to many worlds or just 2 or = more
>>=20 of a given type (e.g. Second Life/OpenSIm compatible).
>
> = The=20 charter for the group is vendor neutral interoperability. If you want to = design=20 a Second-Life-derived protocol under this group, then I cannot support = the=20 group, for pretty obvious reasons, and I believe it would reflect very=20 negatively on the sponsors of the group to go against the = charter.
>=20

Hmmmm....


So you're insisting that we design a = one-size fits=20 all protocol. Does this mean that the OGP between SL and OpenSim can't = be=20 endorsed as a special case of the mmox interoperability=20 protocols?


Lawson
_________________________________________= ______
mmox=20 mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
<= /DIV>

------_=_NextPart_001_01C9990E.65C33F7A-- From jwatte@gmail.com Fri Feb 27 11:14:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717A528C395 for ; Fri, 27 Feb 2009 11:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0IjtqKTNXDz for ; Fri, 27 Feb 2009 11:14:44 -0800 (PST) Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id 3F67628C38E for ; Fri, 27 Feb 2009 11:14:44 -0800 (PST) Received: by gxk22 with SMTP id 22so2950323gxk.13 for ; Fri, 27 Feb 2009 11:15:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mPHsJhq4aLsLNsXBKS6mComakX1qIDKUU0Z8kDnB2Ds=; b=S0gE1B/MfVMg9/6r6CAkIaARuI997maISPw1RA81IdTD5E6HZw3W7mhcclAKLwt9Fc dLdGUo7BLjmbmh3CqJatmJ21uQeKhQy7QYvPcM2Aiz5H/4w+Gv0ww7DjIjvsXbLmiRdr UlyV4pJjWZBY3dB4JIL9/cEyIR/pngo6GRII0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=eEWshIo8iw1/Lndzu++8EgyR5RL5zyA6JfLd8n44Y+udMD2r0faUjvRWJ3EXvoiEQm cFrrOHhmsnYcvRPpOm5E47i2myll9BnjZVRzgy7nn1lDOv39j7Cc3LHZ9CZspkATFXnb xBObXFAdveKeigpg5vyYHJ0HziIgEiaVXJdH8= Received: by 10.100.143.14 with SMTP id q14mr1331216and.139.1235762106379; Fri, 27 Feb 2009 11:15:06 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id d21sm3863198and.46.2009.02.27.11.15.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 11:15:05 -0800 (PST) Message-ID: <49A83BB7.900@gmail.com> Date: Fri, 27 Feb 2009 11:15:03 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Ann Otoole References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <49A829FA.9010500@gmail.com> <49A82BA4.1090006@cox.net> <760397.41366.qm@web59103.mail.re1.yahoo.com> In-Reply-To: <760397.41366.qm@web59103.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lenglish5@cox.net, mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:14:45 -0000 Ann Otoole wrote: > Perhaps the focus needs to be on public worlds and people with worlds > that, by their very nature, will never interop anyway, really should > back off unless their respective companies have at least one public > access virtual world,. Why should this group involve itself with > closed access worlds where no interop will ever happen anyway because > of the danger of espionage? I seem to detect two assumptions here that I would disagree with. Correct me if I'm wrong. First, you are assuming that someone is selling virtual worlds that will never have public access. I don't think anyone on this list is in that situation. Forterra Systems certainly isn't -- our first licensee was There.com, which has built a thriving set of branded and white-label virtual worlds for consumer access. Other licensees of ours are building worlds that are public to some degree or another -- some licensees currently have their worlds "public" only to their employees, others are intending to provide virtual-worlds based services such as online conferencing or distance education. While those are not "free trial" or "entertainment" based virtual worlds, I believe they serve a very important role in the general acceptance of virtual worlds beyond the early adopter fringe, and I believe all those cases would be well served by working interoperability. Second, you are assuming that a virtual world that does not want to interoperate with the public, would not be served by interoperability. I think that's entirely wrong. In large systems acquisition, whether it be a platform for a company like General Electric, or the FBI, or some super-secret black ops laboratory, a final system is seldom built using components from only one vendor. Typically, a systems integrator (like Lockheed-Martin, Northrop-Grumman, SAIC etc) will source a number of pieces from a number of different vendors, and work to put them all together into a working solution. Even if that working solution will be locked in a mountain underground, with no cables in or out, the work of building that system is greatly simplified if there are working interoperability standards for the components in question. In the end, that ends up saving taxpayer money (in the case of systems built for the government). I believe that a vibrant, working, vendor neutral interoperability protocol is key to making virtual worlds really competetive in many of these large markets, which in turn means that many vendors can be considered for programs where they currently can't be, for cost, integration or lock-in reasons. In that sense, everyone in the Virtual Worlds business wins. The competition is not "Forterra vs Second Life" -- in fact, we're not in the business of leasing server time at all. The competition is "Virtual Worlds vs The Way We've Always Done It." I hope we on this list are all on the same side of that battle! Sincerely, jw From eh2th-mmox@yahoo.com Fri Feb 27 11:16:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 993AC28C26A for ; Fri, 27 Feb 2009 11:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJiTW2kQiDGs for ; Fri, 27 Feb 2009 11:16:29 -0800 (PST) Received: from web65701.mail.ac4.yahoo.com (web65701.mail.ac4.yahoo.com [76.13.9.93]) by core3.amsl.com (Postfix) with SMTP id BCFA128C39A for ; Fri, 27 Feb 2009 11:16:29 -0800 (PST) Received: (qmail 15163 invoked by uid 60001); 27 Feb 2009 19:16:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=txFxz2mzTHwXcbY2IDCX94G0/eotGVbZcP00Pu3px82G/88IxrZRVn555bcI6AGpkwZjng+fob7XuEIVkuliOusDto6MhsppMVlwu+NpcfEUbeKKrm3Cc1J8yMaNq9Jd0eW2LjmCMkODSEyF719E8iER40MRSLMht5mDVNsmCZE=; X-YMail-OSG: _uDyfVoVM1nAq0ySMcT8WrQ3coULHomRwkXPQhDZ5zHpb5PjRYYcgQM8jLy1xKY1pCgVHpWURaPYfFZGQC41D_PCPI8EeDuzMfKPeW33r7Dug6m5lSk3WMCHB33YsXnRVZV9hJ4M7jCN5nO3wjthUMhlE9Z0LkjCTssXaCzhCt_9PvsmlipZ.6ZshAg7YS07_EIqL5ZFuks7ZpBkCuKUoICYEA-- Received: from [72.220.236.152] by web65701.mail.ac4.yahoo.com via HTTP; Fri, 27 Feb 2009 11:16:52 PST X-Mailer: YahooMailWebService/0.7.289.1 Date: Fri, 27 Feb 2009 11:16:52 -0800 (PST) From: eh2th-mmox@yahoo.com To: mmox@ietf.org In-Reply-To: <49A83740.5090003@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <222637.14738.qm@web65701.mail.ac4.yahoo.com> Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: eh2th-mmox@yahoo.com List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:16:30 -0000 I would hope that this group could adopt the best from the available unencumbered implementations and boil them down into an efficient protocol which provides a high quality service in as many conditions as possible, and then build upon that to correct any deficiencies. If parties adopt a "Not if it wasn't invented by us" approach, then I suspect achieving this group's goals will become quite difficult. Best regards, --Tom Hoff --- On Fri, 2/27/09, Jon Watte wrote: > From: Jon Watte > Subject: Re: [mmox] Chartering for requirements only > To: "Meadhbh Hamrick (Infinity)" > Cc: lenglish5@cox.net, mmox@ietf.org > Date: Friday, February 27, 2009, 10:56 AM > Meadhbh Hamrick (Infinity) wrote: > > > > why is it of no interest to achieve interoperability > between 2 or more worlds of a given type? > > > > > It is not of interest to a vendor neutral standard to > achieve interoperability between two worlds that use a > vendor-derived approach. It may be interesting as a case > study, and it may be interesting in and of itself in a forum > dedicated to such interoperability, but the explicit > "vendor neutral" part of the charter seems like it > would move such interoperability outside the purview of this > group. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Fri Feb 27 11:20:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5778E3A67D4 for ; Fri, 27 Feb 2009 11:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w147ceqrM-cC for ; Fri, 27 Feb 2009 11:20:04 -0800 (PST) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 885103A67A3 for ; Fri, 27 Feb 2009 11:20:04 -0800 (PST) Received: from [192.168.1.10] (dsl-63-249-112-43.cruzio.com [63.249.112.43]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 2AAA01414005; Fri, 27 Feb 2009 11:20:27 -0800 (PST) Message-Id: <7A9B06CB-C6A2-48F3-A8C3-E6E63E09EC46@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49A83740.5090003@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 27 Feb 2009 11:20:24 -0800 References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com><53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com><49A7DC37.1050002@cox.net> <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> <49A83740.5090003@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: lenglish5@cox.net, mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:20:05 -0000 i think you're conflating "vendor proposed" with "vendor neutral." OGP as it is proposed IS NOT the legacy Second Life protocol and we claim no proprietary interest in the protocol (thus our actions of publishing it with an IETF trust copyright.) Sure. we would balk at you if you tried to propose OLIVE(tm)'s communication protocols as a standard, but again.. OGP IS NOT the same thing as the Second Life legacy protocol. if _you_ made a proposal that was not the existing proprietary OLIVE(tm) communication protocol and disclaimed proprietary interest in it, we would be interested because we're generally interested in VW interoperability. but to date, there are no other proposals on the table, so we're talking about OGP. if you want the discussion to include an OLIVE(tm) derived open protocol, please propose one. On Feb 27, 2009, at 10:56 AM, Jon Watte wrote: > Meadhbh Hamrick (Infinity) wrote: >> >> why is it of no interest to achieve interoperability between 2 or >> more worlds of a given type? >> > > > It is not of interest to a vendor neutral standard to achieve > interoperability between two worlds that use a vendor-derived > approach. It may be interesting as a case study, and it may be > interesting in and of itself in a forum dedicated to such > interoperability, but the explicit "vendor neutral" part of the > charter seems like it would move such interoperability outside the > purview of this group. > > Sincerely, > > jw > From jwatte@gmail.com Fri Feb 27 11:31:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 026B928C20D for ; Fri, 27 Feb 2009 11:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H232Hkq8Ts+m for ; Fri, 27 Feb 2009 11:31:37 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id BDF9C28C15C for ; Fri, 27 Feb 2009 11:31:36 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1554909yxm.49 for ; Fri, 27 Feb 2009 11:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=5oWVPPNYrX18zN7P6E8GIHRWGn3mvyi7YX5HAWuPHg8=; b=JSYyBx3BaDkhgk9NITdTaAadZk5pSrPVt78L9DZqXvvL5OBXrQt9UO9MJv6dKE58er JHky8ktva8v7jjRAnbksDKOWtqCoVFXB4P4NYw1VIrXrfRglqzHiiAiPnGFlZjneZxMQ boxd4uoDlg4Z9zAtINXxZY+5KAyUaWBxJejIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NudsW71F482xrTItzVApJzXCkDs5cK6v0PJBbILRKS9oBzVOqtnY+H7mUMqVxR4JkM +kbu9Nkyg9MPHUorMsaIi4QUs2WXGkq8JypauxVqlhPqwgem0bSFNPyUiBJbTmOu3R5j hi3jVCuI8ku3TeuD0S59xrbz5uWMoG0FwmdCU= Received: by 10.100.242.20 with SMTP id p20mr3003585anh.83.1235763119232; Fri, 27 Feb 2009 11:31:59 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b14sm6760366ana.56.2009.02.27.11.31.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 11:31:58 -0800 (PST) Message-ID: <49A83FAC.60300@gmail.com> Date: Fri, 27 Feb 2009 11:31:56 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com><53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com><49A7DC37.1050002@cox.net> <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> <49A83740.5090003@gmail.com> <7A9B06CB-C6A2-48F3-A8C3-E6E63E09EC46@lindenlab.com> In-Reply-To: <7A9B06CB-C6A2-48F3-A8C3-E6E63E09EC46@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lenglish5@cox.net, mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:31:38 -0000 Meadhbh Hamrick (Infinity) wrote: > i think you're conflating "vendor proposed" with "vendor neutral." OGP > as it is proposed IS NOT the legacy Second Life protocol and we claim > no proprietary interest in the protocol (thus our actions of > publishing it with an IETF trust copyright.) Sure. we would balk at > you if you tried to propose OLIVE(tm)'s communication protocols as a > standard, but again.. OGP We've already been over that. OGP has two problems: 1) It assumes the Second Life way of doing things. It talks about rezzing and de-rezzing avatars, for example. That's something that I believe should be entirely implementation dependent for each virtual world system, and is one of the few things that do *not* need standardization. 2) As far as actual interoperability goes, it's just an empty pipe. Empty pipes where each technology will put their technology-specific bits in does not make for useful and usable vendor-neutral interoperability. > IS NOT the same thing as the Second Life legacy protocol. if _you_ > made a proposal that was not the existing proprietary OLIVE(tm) > communication protocol and disclaimed proprietary interest in it, we > would be interested because we're generally interested in VW > interoperability. > I already posted a link to a sketch of such a protocol that I made almost two years ago, entirely based on my understanding of what the "common ground" of most protocols would be. That link was met with even more silence than my use cases. However, I still maintain that it's too early to even talk about protocol specifics. We need to agree on requirements first. To get to requirements, we need to agree on use cases. If we cannot achieve that, we cannot achieve vendor neutral, working interoperability. > but to date, there are no other proposals on the table, so we're > talking about OGP. if you want the discussion to include an OLIVE(tm) > derived open protocol, please propose one. I have proposed one, but here's the catch: It's not OLIVE(tm) derived. It's not at all like what OLIVE does internally. It's something where I have sat down, looked at the interoperability we've done since 2005, looked at the systems we've previously integrated with, and looked at the technology of other vendors with open technology stacks (Multiverse, Wonderland, Kaneva, plus a bunch of the game engines of the world), and then synthesized that experience into a "middle ground" proposal. I recently took what learning I've gained from the past 18 months (including this mailing list), and updated the proposal. If you want a protocol proposal, check out http://www.interopworld.com/mmox-less-protocol I think you will find that it is both more vendor neutral, and would provide significantly richer interoperability than the currently visible OGP proposal. It is, however, not a complete protocol stack -- there's a whole set of metadata, negotiation, policy etc that needs to go around it. I have ideas about that as well, but haven't spent the time to write them down in detail, because I don't think we have consensus on requirements (or even use cases) yet. In a sense, I'm posting this proposal because I want to avoid someone trying to ram-rod OGP through the group, which I think would be a miserable failure of the group charter. However, I'd much rather we first agreed on requirements. Sincerely, jw From jwatte@gmail.com Fri Feb 27 11:33:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990FE3A6765 for ; Fri, 27 Feb 2009 11:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjjk21awizsr for ; Fri, 27 Feb 2009 11:33:39 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 9DADE3A67A3 for ; Fri, 27 Feb 2009 11:33:39 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so1552253ywh.49 for ; Fri, 27 Feb 2009 11:34:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=V+/T34qrpWYqHTj5SGBaysuGOTX5D2PsBoLPkFZC0dA=; b=my6skTKvd4WBblNfuSraGXFKcS+NRppBvHP5e+muAMucnySjasgECjCDYbBsAEVJrG N6rCLg0kokxwKbd585DXt2nivkMCBHU8ugQVFutxumtjDeadt3KZSLtSNQrWLuDY1hK+ wEH5R97LbEjFST4/gMjkcIfLuiCzpVMLOGHnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=sRtAPOiy71GlIelbik+quZdiU8A26TYoiU6RWgMIlmkGtzTqYcCaWF7ZTCGBrJ0ZkD IPolpDE5PnA9RBknVopDoBRTQ1cOEaZylS5bCrufdJVTwlW2QqgpPBSFvIS8p8TPyNrh gKpABEWYc0UoNrP0H1+HPbAPioV8vLvedNHZ4= Received: by 10.100.58.18 with SMTP id g18mr3017448ana.26.1235763242101; Fri, 27 Feb 2009 11:34:02 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c40sm2558443anc.28.2009.02.27.11.34.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 11:34:01 -0800 (PST) Message-ID: <49A84027.7070705@gmail.com> Date: Fri, 27 Feb 2009 11:33:59 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] LESS: The Live Entity State Stream protocol X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:33:40 -0000 Given that everybody seems intent on talking about protocols, instead of requirements, I have synthesized and edited my previous interoperability protocol proposal from 18 months ago, and posted an updated version for your consideration. Here's the pre-amble: This protocol (the LESS protocol) describes updating virtual world object properties between virtual world peers (typically, servers of virtual world instances). It allows peers to introduce the types of objects that they will provide, and allows the responding peers to decide what types, and what properties within those types, they actually understand and are interested in. This protocol is part of a suite of protocols that together make up an advanced virtual world interoperability standard; when all the protocols are implemented by two or more separate virtual world systems, those systems can interoperate at a high level, and provide a congruent shared experience to participants from all those worlds. Additional use cases include traditional data loggers, a standardized set of analysis tools, and others. The basic model is that objects are simulated on one host, and a certain set of typically well-known properties (identified by id in LESS, and by well- known name mapping to id in schema) are mirrored to observing peers .... More at http://www.interopworld.com/mmox-less-protocol Sincerely, jw From cathypfeffer@gmail.com Fri Feb 27 11:33:47 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDE223A683E for ; Fri, 27 Feb 2009 11:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDvnJC8-l19V for ; Fri, 27 Feb 2009 11:33:47 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.186]) by core3.amsl.com (Postfix) with ESMTP id 99FBC3A6959 for ; Fri, 27 Feb 2009 11:33:46 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so588390fkf.5 for ; Fri, 27 Feb 2009 11:34:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=8YLfqktTchqg2bgYprwRgpRdbKW2sDY0iToFZe0QVsw=; b=VUVl+jjLkSw4ZS0CdVULjbTjtpp6Y6FjtQPyZ6EX8TFlZixgZ44GabWaGgJZM0rrb6 hAHYXPpGZh1sjiPVQrGtL7KByw05tBKCBfCTr8gHInto87Q/bWWKBLBEo9emEfWN3KNR rdF3cU+Ug8R/YjsE9lhJN9m9mnVaruQFoLkcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=vMu97D29ttKaptBlJ76WuGQ+vdFgW3aHC8n3/AhSud5ihB2Vk1L7ReZxlcmL2u2lm/ PBBLgg7AQ7ltMnETFyWsevQO96L4d5Vvuuqm4NmqBBuVTO5B167bjYbTtf51NE5ojl4J 1E1lOAEN4FQlXA1bcnqkgDN+5q/hFHL1jNqoY= MIME-Version: 1.0 Received: by 10.180.222.14 with SMTP id u14mr968692bkg.141.1235763248588; Fri, 27 Feb 2009 11:34:08 -0800 (PST) Date: Fri, 27 Feb 2009 20:34:08 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636c924577566a00463eb8d95 Subject: [mmox] Technical problems in the XML serialization DTD (appendix B) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:33:48 -0000 --001636c924577566a00463eb8d95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi all, In appendix B of LLSD draft: 1) the DTD defines three elements DATA, SIMPLE and KEYDATA, but I doubt anyone plans to write or tags in XML LLSD ;-). I suppose it was intended to use parameter entities here (the ones starting with the ampersand sign %) : %DATA, %SIMPLE, and %KEYDATA 2) llsd element is defined as (DATA), i.e. as a single data. I suppose this is a mistake, because there should be more than one piece of data in a LLSD data flow ;-). Add an asterisk to define llsd as a (%DATA)* 3) I'm not sure, but I think that normally the asterisk is outside the parenthesis. I'm referring to but this one would need to be checked. I hope that helps -- Cathy --001636c924577566a00463eb8d95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all,


In appendix B of LLSD draft:


1) the DTD defin= es three elements DATA, SIMPLE and KEYDATA, but I doubt anyone plans to wri= te <KEYDATA> or <SIMPLE> tags in XML LLSD ;-).

I suppose= it was intended to use parameter entities here (the ones starting with the= ampersand sign %) : %DATA, %SIMPLE, and %KEYDATA


2) llsd element is defined as (DATA), i.e. as a single data. I supp= ose this is a mistake, because there should be more than one piece of data = in a LLSD data flow ;-).

Add an asterisk to define llsd as a (%DATA)= *


3) I'm not sure, but I think that normally the as= terisk is outside the parenthesis. I'm referring to
=C2=A0 <!ELEM= ENT map (KEYDATA*)>
but this one would need to be checked.

I hope that helps

--
Cathy
--001636c924577566a00463eb8d95-- From lenglish5@cox.net Fri Feb 27 11:38:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8580F3A68CD for ; Fri, 27 Feb 2009 11:38:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.331 X-Spam-Level: X-Spam-Status: No, score=0.331 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCWKO0AkMhcN for ; Fri, 27 Feb 2009 11:38:14 -0800 (PST) Received: from fed1rmmtao102.cox.net (fed1rmmtao102.cox.net [68.230.241.44]) by core3.amsl.com (Postfix) with ESMTP id 9F51F3A6765 for ; Fri, 27 Feb 2009 11:38:14 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao102.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090227193837.ZKRO13097.fed1rmmtao102.cox.net@fed1rmimpo03.cox.net>; Fri, 27 Feb 2009 14:38:37 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id M7ec1b00G4N6T0Q047edZy; Fri, 27 Feb 2009 14:38:37 -0500 X-Authority-Analysis: v=1.0 c=1 a=H7oVHkRPDCcA:10 a=xj0JfVIbDmkA:10 a=Wajolswj7cQA:10 a=48vgC7mUAAAA:8 a=xXNbnSOHXWRz0g4zoBkA:9 a=ASF2uLmaoU8Kbe2s4oEA:7 a=cacrwdGZCgBpH8QnZRAQg8dyBEcA:4 a=72oxJoRhc8oA:10 a=EDL5KKi-BPWPrr5q:21 a=n6WzqaLIEd6yFPWf:21 X-CM-Score: 0.00 Message-ID: <49A8413C.4050003@cox.net> Date: Fri, 27 Feb 2009 12:38:36 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com><53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com><49A7DC37.1050002@cox.net> <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> <49A83740.5090003@gmail.com> <7A9B06CB-C6A2-48F3-A8C3-E6E63E09EC46@lindenlab.com> In-Reply-To: <7A9B06CB-C6A2-48F3-A8C3-E6E63E09EC46@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, Jon Watte Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:38:15 -0000 Meadhbh Hamrick (Infinity) wrote: > i think you're conflating "vendor proposed" with "vendor neutral." OGP > as it is proposed IS NOT the legacy Second Life protocol and we claim > no proprietary interest in the protocol (thus our actions of > publishing it with an IETF trust copyright.) Sure. we would balk at > you if you tried to propose OLIVE(tm)'s communication protocols as a > standard, but again.. OGP IS NOT the same thing as the Second Life > legacy protocol. if _you_ made a proposal that was not the existing > proprietary OLIVE(tm) communication protocol and disclaimed > proprietary interest in it, we would be interested because we're > generally interested in VW interoperability. > > but to date, there are no other proposals on the table, so we're > talking about OGP. if you want the discussion to include an OLIVE(tm) > derived open protocol, please propose one. > Perhaps, to clarify: OGP is implemented in a special patch in the GPL Second CLient, and in libaries in the Apache V2 licensed pyogp client, and in special patches in certain proprietary Second Life beta grid simulators and as a BSD licensed patch for the OpenSim simulators. AWG and Linden Lab made a good faith effort to make the OGP as generic as possible from the start with an eye to getting other virtual worlds vendors to use it. However, as Zha Ewry (David Levine) pointed out today in the mmox@jabber.ietf.org chat room, there's a lot of hidden SL-specific assumptions in the OGP implementation that need to be abstracted to make it suitable for mmox, If anyone looks at today's transcript, I think they can find common ground for the beginnings of an abstracted interoperability strategy that can be embodied in appropriate vendor-neutral protocols--not just for Second Life/OpenSim. http://jabber.ietf.org/logs/mmox/2009-02-27.txt starting around 15:30 Lawson From jwatte@gmail.com Fri Feb 27 11:54:51 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1769228C0EF for ; Fri, 27 Feb 2009 11:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjyko8HnFomb for ; Fri, 27 Feb 2009 11:54:49 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 900E13A68AE for ; Fri, 27 Feb 2009 11:54:49 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1566738yxm.49 for ; Fri, 27 Feb 2009 11:55:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tup7UXtyG9/bPmtUc8thmVGmAfCcDDwJGinRNYPHT+o=; b=tPlbfm4aFkfs0yWyCwt5TpZW1tg4yWcAmipyAbPSm06veAxkmyTb5JgqXA068qbC+L YW0ct7zZT56BD+OSjIID9HOq/Ahi8ce7VaFZUDInedjZbVz0X2PmfCEMXMAxIGoUzbgR DURCjET+jyQxddNtbCqi27UIhq5qdSBdxLKcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=CGxWxapE9knbOazx+3sKnuwy4FHRycNY+bTTyZpHWlcIukiF977U2c/9ZKDaw8L5Zi SyeC+0TBFGsmKntLFScDAsskyYjqCLT/GuhcSlsX/OPHQKOIbz3OOrbjQoIpupv3scWw CjwXkzX/ZqW5hSMH3w9gJ90WkMo44MEiTtaC8= Received: by 10.100.153.4 with SMTP id a4mr3035591ane.56.1235764511922; Fri, 27 Feb 2009 11:55:11 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c14sm5854550ana.41.2009.02.27.11.55.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 11:55:09 -0800 (PST) Message-ID: <49A8451A.4050901@gmail.com> Date: Fri, 27 Feb 2009 11:55:06 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: lenglish5@cox.net References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com><53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com><49A7DC37.1050002@cox.net> <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> <49A83740.5090003@gmail.com> <7A9B06CB-C6A2-48F3-A8C3-E6E63E09EC46@lindenlab.com> <49A8413C.4050003@cox.net> In-Reply-To: <49A8413C.4050003@cox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:54:51 -0000 Lawson English wrote: > http://jabber.ietf.org/logs/mmox/2009-02-27.txt starting around 15:30 > [16:00:55] Jon's somewhat blinded I would very much like a little more detailed description, because if there's something I'm not getting, I need to fix that! Meanwhile, I still think the discussion hasn't assimilated the actual requirements of vendor neutral interoperability. It still talks about things like "I inject my avatar into some arbitrary server." Here's what's wrong with that, in my (blinded?) view: You can't do that in a generally interoperable way, because avatars are objects with behavior, and I thought we all agreed that we cannot reasonably standardize how behavior is implemented. Thus, I have to log in my avatar in a system that knows how to execute my avatar. That system can then peer my avatar over to another system -- but that's no different from peering any other object (such as a tree) -- and the acts of "teleport" or "login" are necessarily specific to my host system, and separated from the interoperability. That's just a logical consequence of not standardizing the execution environment. It seems to me from that discussion that Linden is still intent on standardizing the execution environment, and in that case, standardizing it to the current Linden environment. VRML tried doing that in 1995, using a vendor neutral, standard execution environment. That didn't fly back then, and is even less likely to fly with a vendor-specific environment now. Now, it may be that I'm missing something entirely, thus being "somewhat blinded," but nobody has shown me through factual argument how that's the case. I'm looking forward to it, though! Sincerely, jw From MysticalDemina@xrgrid.com Fri Feb 27 11:56:18 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA28D3A67EC for ; Fri, 27 Feb 2009 11:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpNZM-pTH9Yt for ; Fri, 27 Feb 2009 11:56:17 -0800 (PST) Received: from k2smtpout04-01.prod.mesa1.secureserver.net (k2smtpout04-01.prod.mesa1.secureserver.net [64.202.189.166]) by core3.amsl.com (Postfix) with SMTP id C370C3A67B1 for ; Fri, 27 Feb 2009 11:56:17 -0800 (PST) Received: (qmail 9620 invoked from network); 27 Feb 2009 19:56:39 -0000 Received: from unknown (HELO TWEEDY001.kevin-tweedy.com) (68.178.225.179) by k2smtpout04-01.prod.mesa1.secureserver.net (64.202.189.166) with ESMTP; 27 Feb 2009 19:56:39 -0000 Received: from KEVINPC ([173.49.10.182]) by kevin-tweedy.com with MailEnable ESMTP; Fri, 27 Feb 2009 12:56:49 -0700 From: "Mystical Demina" To: References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com><53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com><49A7DC37.1050002@cox.net> <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com><49A83740.5090003@gmail.com> <7A9B06CB-C6A2-48F3-A8C3-E6E63E09EC46@lindenlab.com> In-Reply-To: <7A9B06CB-C6A2-48F3-A8C3-E6E63E09EC46@lindenlab.com> Date: Fri, 27 Feb 2009 14:56:20 -0500 Message-ID: <8CBF4CA2230A4E5590520D9DAACAF8C4@KEVINPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049 Thread-Index: AcmZEHp4DNw/Vrn5TBGpCgkP94h1rAAA3RDg Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 19:56:18 -0000 Regarding there are no more proposals could you help me understand how this process will work? When is the time to send in an RFC? What am I specifically sending a RFC in about? I may have some interest in writing up some proposals but I am not sure when and how that process will work. To me there are lots of situations the OGP protocol doesn't address and as such until we define and abstract out the client to server, and server to server relationship independent of technology and solution how can we say any specific protocol is something we can support and write code to support. Kevin Tweedy SL: Mystical Demina http://www.XRGrid.com -----Original Message----- From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of Meadhbh Hamrick (Infinity) Sent: Friday, February 27, 2009 2:20 PM To: Jon Watte Cc: lenglish5@cox.net; mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only i think you're conflating "vendor proposed" with "vendor neutral." OGP as it is proposed IS NOT the legacy Second Life protocol and we claim no proprietary interest in the protocol (thus our actions of publishing it with an IETF trust copyright.) Sure. we would balk at you if you tried to propose OLIVE(tm)'s communication protocols as a standard, but again.. OGP IS NOT the same thing as the Second Life legacy protocol. if _you_ made a proposal that was not the existing proprietary OLIVE(tm) communication protocol and disclaimed proprietary interest in it, we would be interested because we're generally interested in VW interoperability. but to date, there are no other proposals on the table, so we're talking about OGP. if you want the discussion to include an OLIVE(tm) derived open protocol, please propose one. On Feb 27, 2009, at 10:56 AM, Jon Watte wrote: > Meadhbh Hamrick (Infinity) wrote: >> >> why is it of no interest to achieve interoperability between 2 or >> more worlds of a given type? >> > > > It is not of interest to a vendor neutral standard to achieve > interoperability between two worlds that use a vendor-derived > approach. It may be interesting as a case study, and it may be > interesting in and of itself in a forum dedicated to such > interoperability, but the explicit "vendor neutral" part of the > charter seems like it would move such interoperability outside the > purview of this group. > > Sincerely, > > jw > _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox From john.hurliman@intel.com Fri Feb 27 12:47:35 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931353A6832 for ; Fri, 27 Feb 2009 12:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ4qgcqV4YL8 for ; Fri, 27 Feb 2009 12:47:34 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 952593A657C for ; Fri, 27 Feb 2009 12:47:34 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 27 Feb 2009 12:47:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,278,1233561600"; d="scan'208";a="115194733" Received: from rrsmsx601.amr.corp.intel.com ([10.31.0.151]) by azsmga001.ch.intel.com with ESMTP; 27 Feb 2009 12:47:57 -0800 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Fri, 27 Feb 2009 13:47:57 -0700 From: "Hurliman, John" To: "mmox@ietf.org" Date: Fri, 27 Feb 2009 13:47:57 -0700 Thread-Topic: [mmox] Chartering for requirements only Thread-Index: AcmZEv6qt2Y4WlIeSMCM79KtpnvLEwABgyqw Message-ID: <62BFE5680C037E4DA0B0A08946C0933D5034A914@rrsmsx506.amr.corp.intel.com> References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com><53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com><49A7DC37.1050002@cox.net> <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> <49A83740.5090003@gmail.com> <7A9B06CB-C6A2-48F3-A8C3-E6E63E09EC46@lindenlab.com> <49A8413C.4050003@cox.net> In-Reply-To: <49A8413C.4050003@cox.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 20:47:35 -0000 -----Original Message----- > From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf=20 > Of Lawson English > Sent: Friday, February 27, 2009 11:39 AM > To: Meadhbh Hamrick (Infinity) > Cc: mmox@ietf.org; Jon Watte > Subject: Re: [mmox] Chartering for requirements only >=20 > Meadhbh Hamrick (Infinity) wrote: >> i think you're conflating "vendor proposed" with "vendor neutral." OGP >> as it is proposed IS NOT the legacy Second Life protocol and we claim >> no proprietary interest in the protocol (thus our actions of publishing >> it with an IETF trust copyright.) Sure. we would balk at you if you >> tried to propose OLIVE(tm)'s communication protocols as a standard, but >> again.. OGP IS NOT the same thing as the Second Life legacy protocol. >> if _you_ made a proposal that was not the existing proprietary >> OLIVE(tm) communication protocol and disclaimed proprietary interest in >> it, we would be interested because we're generally interested in VW >> interoperability. >>=20 >> but to date, there are no other proposals on the table, so we're >> talking about OGP. if you want the discussion to include an >> OLIVE(tm) derived open protocol, please propose one. >>=20 >=20 > Perhaps, to clarify: >=20 > OGP is implemented in a special patch in the GPL Second CLient, and in > libaries in the Apache V2 licensed pyogp client, and in special > patches in certain proprietary Second Life beta grid simulators and as > a BSD licensed patch for the OpenSim simulators. >=20 >=20 > AWG and Linden Lab made a good faith effort to make the OGP as generic > as possible from the start with an eye to getting other virtual worlds > vendors to use it. >=20 > However, as Zha Ewry (David Levine) pointed out today in the > mmox@jabber.ietf.org chat room, there's a lot of hidden SL-specific > assumptions in the OGP implementation that need to be abstracted to > make it suitable for mmox, If anyone looks at today's transcript, I > think they can find common ground for the beginnings of an abstracted > interoperability strategy that can be embodied in appropriate vendor- > neutral protocols--not just for Second Life/OpenSim. >=20 OGP establishes explicit (partial) trust maps between separate authorities = to achieve interoperability. This is a special case of interoperability, si= milar to Apple letting you login to iTunes using either an Apple ID or an A= OL ID. It is a separate case from interoperability in the sense of POP/IMAP= or HTTP, where I can send e-mail to anyone on the web or visit any website= without having to worry if the appropriate trust has been established by t= wo service providers. Explicit trust maps between virtual worlds would have= many useful applications, but it is not the ultimate goal when many MMOX p= articipants talk about virtual world interoperability. The problems arising from Second Life assumptions being baked into the curr= ent OGP discussion have already been discussed extensively. There is also a= strong push from Meadhbh, as the co-chair of MMOX, to structure the discus= sion as OGP/LLSD-based, but open to the consideration of other proposals (h= ttp://www.ietf.org/mail-archive/web/mmox/current/msg00627.html). These alte= rnative proposals should be structured in the context of an alternative to = what Linden Lab already has working code for, and to consider Linden Lab's = cost of switching to something different (http://www.ietf.org/mail-archive/= web/mmox/current/msg00584.html). Because of these large disconnects at both technical and policy levels, I s= upport either renaming the MMOX group and changing the draft charter to an = OGP/LLSD-centric group, or splitting off OGP/LLSD into a separate group. John From lenglish5@cox.net Fri Feb 27 12:58:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394DB3A6893 for ; Fri, 27 Feb 2009 12:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.421 X-Spam-Level: X-Spam-Status: No, score=-0.421 tagged_above=-999 required=5 tests=[AWL=1.048, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xs04Uvlzi1c for ; Fri, 27 Feb 2009 12:58:15 -0800 (PST) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id D8DB83A67AE for ; Fri, 27 Feb 2009 12:58:14 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090227205748.ELCL4363.fed1rmmtao103.cox.net@fed1rmimpo01.cox.net>; Fri, 27 Feb 2009 15:57:48 -0500 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id M8xm1b00B4N6T0Q038xmiv; Fri, 27 Feb 2009 15:57:46 -0500 X-Authority-Analysis: v=1.0 c=1 a=H7oVHkRPDCcA:10 a=xj0JfVIbDmkA:10 a=Wajolswj7cQA:10 a=48vgC7mUAAAA:8 a=bdlxvuk3LIxutk8BZOQA:9 a=SI_6bR9ynHEDXFuWbukA:7 a=qFUGdAGmd64jbSWkvp6P3RoQukkA:4 a=J3kPgAfI5rUA:10 a=lZB815dzVvQA:10 a=HGEFCvOflcF-RvY9:21 a=NUqzOoRXRZkaA6oO:21 X-CM-Score: 0.00 Message-ID: <49A853CA.7070801@cox.net> Date: Fri, 27 Feb 2009 13:57:46 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Hurliman, John" References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com><53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com><49A7DC37.1050002@cox.net> <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> <49A83740.5090003@gmail.com> <7A9B06CB-C6A2-48F3-A8C3-E6E63E09EC46@lindenlab.com> <49A8413C.4050003@cox.net> <62BFE5680C037E4DA0B0A08946C0933D5034A914@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D5034A914@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 20:58:16 -0000 Hurliman, John wrote: > -----Original Message----- > >> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf >> Of Lawson English >> Sent: Friday, February 27, 2009 11:39 AM >> To: Meadhbh Hamrick (Infinity) >> Cc: mmox@ietf.org; Jon Watte >> Subject: Re: [mmox] Chartering for requirements only >> >> Meadhbh Hamrick (Infinity) wrote: >> >>> i think you're conflating "vendor proposed" with "vendor neutral." OGP >>> as it is proposed IS NOT the legacy Second Life protocol and we claim >>> no proprietary interest in the protocol (thus our actions of publishing >>> it with an IETF trust copyright.) Sure. we would balk at you if you >>> tried to propose OLIVE(tm)'s communication protocols as a standard, but >>> again.. OGP IS NOT the same thing as the Second Life legacy protocol. >>> if _you_ made a proposal that was not the existing proprietary >>> OLIVE(tm) communication protocol and disclaimed proprietary interest in >>> it, we would be interested because we're generally interested in VW >>> interoperability. >>> >>> but to date, there are no other proposals on the table, so we're >>> talking about OGP. if you want the discussion to include an >>> OLIVE(tm) derived open protocol, please propose one. >>> >>> >> Perhaps, to clarify: >> >> OGP is implemented in a special patch in the GPL Second CLient, and in >> libaries in the Apache V2 licensed pyogp client, and in special >> patches in certain proprietary Second Life beta grid simulators and as >> a BSD licensed patch for the OpenSim simulators. >> >> >> AWG and Linden Lab made a good faith effort to make the OGP as generic >> as possible from the start with an eye to getting other virtual worlds >> vendors to use it. >> >> However, as Zha Ewry (David Levine) pointed out today in the >> mmox@jabber.ietf.org chat room, there's a lot of hidden SL-specific >> assumptions in the OGP implementation that need to be abstracted to >> make it suitable for mmox, If anyone looks at today's transcript, I >> think they can find common ground for the beginnings of an abstracted >> interoperability strategy that can be embodied in appropriate vendor- >> neutral protocols--not just for Second Life/OpenSim. >> >> > > OGP establishes explicit (partial) trust maps between separate authorities to achieve interoperability. This is a special case of interoperability, similar to Apple letting you login to iTunes using either an Apple ID or an AOL ID. It is a separate case from interoperability in the sense of POP/IMAP or HTTP, where I can send e-mail to anyone on the web or visit any website without having to worry if the appropriate trust has been established by two service providers. Explicit trust maps between virtual worlds would have many useful applications, but it is not the ultimate goal when many MMOX participants talk about virtual world interoperability. > > The problems arising from Second Life assumptions being baked into the current OGP discussion have already been discussed extensively. There is also a strong push from Meadhbh, as the co-chair of MMOX, to structure the discussion as OGP/LLSD-based, but open to the consideration of other proposals (http://www.ietf.org/mail-archive/web/mmox/current/msg00627.html). These alternative proposals should be structured in the context of an alternative to what Linden Lab already has working code for, and to consider Linden Lab's cost of switching to something different (http://www.ietf.org/mail-archive/web/mmox/current/msg00584.html). > > Because of these large disconnects at both technical and policy levels, I support either renaming the MMOX group and changing the draft charter to an OGP/LLSD-centric group, or splitting off OGP/LLSD into a separate group. > > Read todays transcript, I take it.... L From morgaine.dinova@googlemail.com Fri Feb 27 13:25:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0D133A67B6 for ; Fri, 27 Feb 2009 13:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjncLP4nPW+w for ; Fri, 27 Feb 2009 13:25:23 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 7D4BE3A68E8 for ; Fri, 27 Feb 2009 13:25:22 -0800 (PST) Received: by fxm24 with SMTP id 24so1239664fxm.37 for ; Fri, 27 Feb 2009 13:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=IXK7GhXqJN0dn89GOukNeYQn78K+W3vBAgij66bCig4=; b=AltS89PMrUZ/WC+GJjrOaBnwMBvYGTjqC3EsqqN/jAMxyLRoR665K3/ONOlmc573NT X/cLFaGvSGJM/gL/aSyMmGlxWYbnUGe2RGei9b6gOtMzRGlwQiqcPGdrNQsqFA2y2KbP C1ELHi5+79XIK1EZIWorsKF6M3pvCRBKUkew0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jmb2cQskiJE3S4Sne5YYpVvaGlCcFW0zimjNUE+BxeniAZbAZi0BQat4BGZgjIiGkL 2SG0FOyIG1QFpXnOverprhfCkA5VFVdRX3aK3dxV2TbkQMcLY20xHX0B8P+cU+AarKLs GpsYfyrgMv1gIk+5TY8007L5CxW31ivZRZXd4= MIME-Version: 1.0 Received: by 10.181.207.9 with SMTP id j9mr1001960bkq.149.1235769944255; Fri, 27 Feb 2009 13:25:44 -0800 (PST) In-Reply-To: <49A80BE4.7000206@cox.net> References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <49A80BE4.7000206@cox.net> Date: Fri, 27 Feb 2009 21:25:44 +0000 Message-ID: From: Morgaine To: lenglish5@cox.net Content-Type: multipart/alternative; boundary=0016e6d5094c8d2d780463ed1c7d Cc: mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 21:25:26 -0000 --0016e6d5094c8d2d780463ed1c7d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 27, 2009 at 3:51 PM, Lawson English wrote: But interoperation between worlds is obviously eaisier with some than > others. Indeed, but I have to reiterate that defining interop between two very similar worlds is of no interest to anyone else. > It seems to me that YOU are proposing an "all or none" solution here. I would call it a "have your cake and eat it too" solution, since I've suggested a way for both parties to make progress without impeding each other. Much closer to an "all or nothing" situation is the "LLSD/OGP or nothing" impasse that we have now. ;-) I can see three ways to help us work more cooperatively: 1. Work in two streams, one explicitly OGP which is very targetted at a specific solution, and the other explicitly MMOX which is much wider, with people contributing to one or both. If MMOX identifies other possible solutions then additional workgroups could be created to handle them. 2. Remove the constraints (expressed as an intention) imposed by LL on the solution space, so that MMOX can find common ground among VW architectures and then seek solutions without being placed in a straightjacket by Linden-only issues. Notice that this may even lead to OGP being identified as a good solution. 3. Unpack the OGP proposal in all its glory into all the {problem,solution} pairs that led up to it, and describe the details in a marathon session of explanation/indoctrination so that there can be broad buy-in to that technology from a large proportion of MMOX participants. If they agree that LLSD/OGP can solve the interop problem for their own worlds equitably, then we might be onto a winner. It's worth pointing out that we have spent 16 months in AWG talking about OGP, so we have a good grasp of how it can be adapted for interop among very diverse worlds. A large proportion of MMOX participants do not have the benefit of our deliberations, and so the lack of wide backing for what is seen as "Linden Lab's solution" is not very surprising. (And some participants who are fully aware of OGP have questioned its appropriateness too, so this issue is by no means settled.) Something needs to be done, or the lack of even a rough consensus might impact badly on our ability to form a workgroup after the BoF, let alone actually get good work done. I don't mind which path we take, as long as it provides a means of cooperation in place of outright conflict. (A bit of conflict is of course both inevitable and useful.) And flexibility is mandatory whichever path we take. Tying the group down to suit one particular vendor's business requirements is not satisfactory for a group targetting a broad problem space. Morgaine. --0016e6d5094c8d2d780463ed1c7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Feb 27, 2009 at 3:51 PM, Lawson = English <lenglish= 5@cox.net> wrote:

But interoperation between worlds is obviously eaisier with some than other= s.

Indeed, but I have to reiterate that defining inter= op between two very similar worlds is of no interest to anyone else.

=A0
It s= eems to me that YOU are proposing an "all or none" solution here.=

I would call it a "have your cake and eat it too" soluti= on, since I've suggested a way for both parties to make progress withou= t impeding each other.=A0=A0 Much closer to an "all or nothing" s= ituation is the "LLSD/OGP or nothing" impasse that we have now. ;= -)

I can see three ways to help us work more cooperatively:
  1. Wor= k in two streams, one explicitly OGP which is very targetted at a specific = solution, and the other explicitly MMOX which is much wider, with people co= ntributing to one or both.=A0 If MMOX identifies other possible solutions t= hen additional workgroups could be created to handle them.
  2. Remove the constraints (expressed as an=A0intention) imposed by LL= on the solution space, so that MMOX can find common ground among VW archit= ectures and then seek solutions without being placed in a straightjacket by= Linden-only issues.=A0 Notice that this may even lead to OGP being identif= ied as a good solution.
  3. Unpack the OGP proposal in all its glory into all the {problem,solution= } pairs that led up to it, and describe the details in a marathon session o= f explanation/indoctrination so that there can be broad buy-in to that tech= nology from a large proportion of MMOX participants.=A0 If they agree that = LLSD/OGP can solve the interop problem for their own worlds equitably, then= we might be onto a winner.
It's worth pointing out that we have spent 16 months in AWG talkin= g about OGP, so we have a good grasp of how it can be adapted for interop a= mong very diverse worlds.=A0 A large proportion of MMOX participants do not= have the benefit of our deliberations, and so the lack of wide backing for= what is seen as "Linden Lab's solution" is not very surprisi= ng.=A0 (And some participants who are fully aware of OGP have questioned it= s appropriateness too, so this issue is by no means settled.)

Something needs to be done, or the lack of even a rough consensus might= impact badly on our ability to form a workgroup after the BoF, let alone a= ctually get good work done.=A0 I don't mind which path we take, as long= as it provides a means of cooperation in place of outright conflict.=A0 (A= bit of conflict is of course both inevitable and useful.)

And flexibility is mandatory whichever path we take.=A0 Tying the group= down to suit one particular vendor's business requirements is not sati= sfactory for a group targetting a broad problem space.

=A0
Morgaine.

--0016e6d5094c8d2d780463ed1c7d-- From cathypfeffer@gmail.com Fri Feb 27 13:38:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95EF3A67B6 for ; Fri, 27 Feb 2009 13:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGFaD-XO2aKm for ; Fri, 27 Feb 2009 13:38:09 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id C28193A6A1A for ; Fri, 27 Feb 2009 13:37:58 -0800 (PST) Received: by fxm24 with SMTP id 24so1243964fxm.37 for ; Fri, 27 Feb 2009 13:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=9aor82AjgUs4KL6KxbuIViuDOTYc4ikKJ5L1PxJAG3I=; b=PZCDI5eQQGlK+v0LnHGdjn0BIzAUPNgqWc3ZLRrmDVyq82jfies1kJuFoFFCES+jqH fZR4VGaX/Q6qFPdFcc4Ag1IcBYzw8QmYT9PsKrfxpsEVoZeYjYeuTi84NwBTu1j9z8Ax 7libsCEo19hVYYEX64P5hhlSrQ8yyvCu/Na9E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=e+7y0Xr80xrFKO7EnCt3dJzVDrFpn5D2dqzDWk9IvHB6RxeTegrlywmdGh9BI26vEi 7c+J58HqoBUSGYUGiJj0rmfZWgMYp/nDVwUqaZvcUI+mbUUqkuYKdVuh/hjv+BUtz7wQ UwOjmAC+88qMdd35icerKoKKJ0p5RJE7rFzX4= MIME-Version: 1.0 Received: by 10.180.213.14 with SMTP id l14mr1009361bkg.107.1235770700606; Fri, 27 Feb 2009 13:38:20 -0800 (PST) Date: Fri, 27 Feb 2009 22:38:20 +0100 Message-ID: From: Catherine Pfeffer To: mmox@ietf.org Content-Type: multipart/mixed; boundary=001636c5b0a3a22b970463ed49cb Subject: [mmox] Small contributions X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 21:38:10 -0000 --001636c5b0a3a22b970463ed49cb Content-Type: multipart/alternative; boundary=001636c5b0a3a22b8f0463ed49c9 --001636c5b0a3a22b8f0463ed49c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello, You'll find attached three files. - test.xsl is a XSLT style sheet that tests the access to some data, either using the original LLSD specification, or using what we called "the XML way" - llsd-draft-revision-horrible-serialisation.txt is a small set of corrections to the original LLSD specification to avoid the key-data alternance that does not fit well within DOM or XPath. It includes a DTD (which this time has correct syntax and has been tested -- lol). - llsd-draft-revision-xml-way.txt is a much more radical change to the XML serialization to acheive the "XML way". These sets of corrections do not address other problems like name of the standard, lack of unsigneds, or alternative scalar sizes. I don't think anyone needs my help for these details. Having sent these files, with the hope they can help, I must say it was my last message to this list. I am spending too much time on this for an amateur, but this is not the main reason for my withdrawal. I am stopping this because of the weight of the responsibility: what if I am giving bad advice? what if I am delaying, with my remarks, the adoption of virtual world standards? I have started feeling a ball in the stomach and that is not pleasant to live with. So, Jon, Infinity, Lisa, Morgaine, Sai, and all the others, I enjoyed chatting about technical matters with you. Take care, and I wish you all the best luck and success in defining the standards of tomorrow's 3D web :-). PS: Yes there is only one data item in the tag. My remark was wrong. PPS: If attachements are not allowed on this mailing list I'll send them to infinity by some other way. -- Cathy --001636c5b0a3a22b8f0463ed49c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello,


You'll find attached three files.
=C2=A0- test.xsl= is a XSLT style sheet that tests the access to some data, either using the= original LLSD specification, or using what we called "the XML way&quo= t;
=C2=A0- llsd-draft-revision-horrible-serialisation.txt is a small set of co= rrections to the original LLSD specification to avoid the key-data alternan= ce that does not fit well within DOM or XPath. It includes a DTD (which thi= s time has correct syntax and has been tested -- lol).
=C2=A0 - llsd-draft-revision-xml-way.txt is a much more radical change to t= he XML serialization to acheive the "XML way".
T= hese sets of corrections do not address other problems like name of the sta= ndard, lack of unsigneds, or alternative scalar sizes. I don't think an= yone needs my help for these details.

Having sent these files, with the hope they can help, I must say it was= my last message to this list. I am spending too much time on this for an a= mateur, but this is not the main reason for my withdrawal. I am stopping th= is because of the weight of the responsibility: what if I am giving bad adv= ice? what if I am delaying, with my remarks, the adoption of virtual world = standards? I have started feeling a ball in the stomach and that is not ple= asant to live with.

So, Jon, Infinity, Lisa, Morgaine, Sai, and all the others, I enjoyed c= hatting about technical matters with you. Take care, and I wish you all the= best luck and success in defining the standards of tomorrow's 3D web := -).


PS: Yes there is only one data item in the <llsd> tag. My rem= ark was wrong.
PPS: If attachements are not allowed on this mailing list= I'll send them to infinity by some other way.
--
Cathy
--001636c5b0a3a22b8f0463ed49c9-- --001636c5b0a3a22b970463ed49cb Content-Type: text/plain; charset=US-ASCII; name="llsd-draft-revision-horrible-serialisation.txt" Content-Disposition: attachment; filename="llsd-draft-revision-horrible-serialisation.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_frpdd7ia1 My4xLjIuICBTZXJpYWxpemluZyBDb21wb3NpdGUgVHlwZXMKCiAgIENvbXBvc2l0ZSB0eXBlcyBp biB0aGUgWE1MIHNlcmlhbGl6YXRpb24gc2NoZW1lIGFyZSByZXByZXNlbnRlZCB3aXRoCiAgICdh cnJheScgYW5kICdtYXAnIGVsZW1lbnRzLiAgQXJyYXkgZWxlbWVudHMsIHdoaWNoIHJlcHJlc2Vu dCBhCiAgIGNvbGxlY3Rpb24gb2YgdmFsdWVzIGluZGV4ZWQgYnkgcG9zaXRpb24sIGNvbnRhaW4g YSBzaW1wbGUgbGlzdCBvZgogICB0eXBlZCB2YWx1ZXMuICBNYXAgZWxlbWVudHMgcmVwcmVzZW50 IGEgY29sbGVjdGlvbiBvZiB2YWx1ZXMgaW5kZXhlZAogICBieSBhIHN0cmluZyBpZGVudGlmaWVy LiAgRWFjaCBrZXktdmFsdWUgcGFpciBpbiBhIG1hcCB0YWtlcyB0aGUgZm9ybQogICBvZiBhbiAn ZScgKGVudHJ5KSBlbGVtZW50IHdpdGggYSAna2V5JyBhdHRyaWJ1dGUgdGhhdCBkZXNjcmliZXMg dGhlCiAgIGluZGV4aW5nIGlkZW50aWZpZXIsIGFuZCB3aXRoIGEgdmFsdWUgY29udGFpbmVkIGlu IHRoZSBlbnRyeS4KCiAgIE5vdGUgdGhhdCBlbGVtZW50cyBvZiBhbiBhcnJheSBtYXkgYmUgb2Yg ZGlmZmVyaW5nIHR5cGVzLiAgQWxzbyBub3RlCiAgIHRoYXQgY29tcG9zaXRlIHR5cGVzIG1heSBj b250YWluIG90aGVyIGNvbXBvc2l0ZSB0eXBlczsgaXQgaXMgbm90IGFuCiAgIGVycm9yIGZvciBh biBhcnJheSBvciBtYXAgdG8gY29udGFpbiBhbm90aGVyIGFycmF5LCBtYXAgb3Igc2ltcGxlCiAg IHR5cGUuCgozLjEuMy4gIEV4YW1wbGUgb2YgWE1MIExMU0QgU2VyaWFsaXphdGlvbgoKICAgVGhp cyBleGFtcGxlIHNob3dzIHRoZSBYTUwgc2VyaWFsaXphdGlvbiBvZiBhbiBhcnJheSB3aGljaCBj b250YWlucwogICBhbiBpbnRlZ2VyLCBhIFVVSUQgYW5kIGEgbWFwLgoKPD94bWwgdmVyc2lvbj0i MS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPGxsc2Q+CiA8YXJyYXk+CiAgPGludGVnZXI+NDI8L2lu dGVnZXI+CiAgPHV1aWQ+NmJhZDI1OGUtMDZmMC00YTg3LWE2NTktNDkzMTE3YzljMTYyPC91dWlk PgogIDxtYXA+CiAgIDxlIGtleT0iaG90Ij4gPHN0cmluZz5jb2xkPC9zdHJpbmc+IDwvZT4KICAg PGUga2V5PSJoaWdnc19ib3Nvbl9yZXN0X21hc3MiPiA8dW5kZWYvPiA8L2U+CiAgIDxlIGtleT0i aW5mb19wYWdlIj4KICAgICA8dXJpPmh0dHBzOi8vZXhhbXBsZS5vcmcvci82YmFkMjU4ZS0wNmYw LTRhODctYTY1OS00OTMxMTdjOWMxNjI8L3VyaT4KICAgPC9lPgogICA8ZSBrZXk9InN0YXR1c19y ZXBvcnRfZHVlX2J5Ij4gPGRhdGU+MjAwOC0xMC0xM1QxOTowMC4wMFo8L2RhdGU+IDwvZT4KICA8 L21hcD4KIDwvYXJyYXk+CjwvbGxzZD4KCgoKQXBwZW5kaXggQi4gIFhNTCBTZXJpYWxpemF0aW9u IERURAoKICAgVGhlIGZvbGxvd2luZyBEb2N1bWVudCBUeXBlIERlZmluaXRpb24gKERURCkgZGVz Y3JpYmVzIHRoZSBmb3JtYXQgb2YKICAgTExTRCBYTUwgU2VyaWFsaXphdGlvbi4gIERURHMgYXJl IGRlc2NyaWJlZCBpbiB0aGUgRXh0ZW5zaWJsZSBNYXJrdXAKICAgTGFuZ3VhZ2UgKFhNTCkgMS4w IChGb3VydGggRWRpdGlvbikgW1hNTDIwMDZdIHNwZWNpZmljYXRpb24uCgogICA8IUVOVElUWSAl IFNJTVBMRQogICAgICIodW5kZWZ8Ym9vbGVhbnxpbnRlZ2VyfHJlYWx8dXVpZHxzdHJpbmd8ZGF0 ZXx1cml8YmluYXJ5KSI+CiAgIDwhRU5USVRZICUgREFUQSAiKCVTSU1QTEU7fG1hcHxhcnJheSki PgoKICAgPCFFTEVNRU5UIGxsc2QgKCVEQVRBOyk+CiAgIDwhRUxFTUVOVCBrZXkgKCNQQ0RBVEEp PgogICA8IUVMRU1FTlQgYXJyYXkgKCVEQVRBOykqPgogICA8IUVMRU1FTlQgbWFwIChlKSo+CiAg IDwhRUxFTUVOVCBlICglREFUQTspPgogICA8IUVMRU1FTlQgdW5kZWYgRU1QVFk+CiAgIDwhRUxF TUVOVCBib29sZWFuICgjUENEQVRBKT4KICAgPCFFTEVNRU5UIGludGVnZXIgKCNQQ0RBVEEpPgog ICA8IUVMRU1FTlQgcmVhbCAoI1BDREFUQSk+CiAgIDwhRUxFTUVOVCB1dWlkICgjUENEQVRBKT4K ICAgPCFFTEVNRU5UIHN0cmluZyAoI1BDREFUQSk+CiAgIDwhRUxFTUVOVCBkYXRlICgjUENEQVRB KT4KICAgPCFFTEVNRU5UIHVyaSAoI1BDREFUQSk+CiAgIDwhRUxFTUVOVCBiaW5hcnkgKCNQQ0RB VEEpPgoKICAgPCFBVFRMSVNUIHN0cmluZyB4bWw6c3BhY2UgKGRlZmF1bHR8cHJlc2VydmUpICdw cmVzZXJ2ZSc+CiAgIDwhQVRUTElTVCBlIGtleSBDREFUQSAjUkVRVUlSRUQ+CiAgIDwhQVRUTElT VCBiaW5hcnkgZW5jb2RpbmcgQ0RBVEEgImJhc2U2NCI+Cg== --001636c5b0a3a22b970463ed49cb Content-Type: text/xml; charset=US-ASCII; name="test.xsl" Content-Disposition: attachment; filename="test.xsl" Content-Transfer-Encoding: base64 X-Attachment-Id: f_frpd7o650 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiID8+Cjx4c2w6c3R5bGVzaGVldCB2 ZXJzaW9uPSIxLjAiCiAgICAgICAgICAgICAgICB4bWxuczp4c2w9Imh0dHA6Ly93d3cudzMub3Jn LzE5OTkvWFNML1RyYW5zZm9ybSI+Cgo8eHNsOm91dHB1dCBtZXRob2Q9InRleHQiIGVuY29kaW5n PSJVVEYtOCIgLz4KCjx4c2w6dGVtcGxhdGUgbWF0Y2g9Im1hcC9rZXlbLiA9ICdQQ29kZSddIj4K CTx4c2w6dmFsdWUtb2Ygc2VsZWN0PSJmb2xsb3dpbmctc2libGluZzo6aW50ZWdlcltwb3NpdGlv bigpID0gMV0iIC8+Cgk8eHNsOmFwcGx5LXRlbXBsYXRlcyAvPgo8L3hzbDp0ZW1wbGF0ZT4KCjx4 c2w6dGVtcGxhdGUgbWF0Y2g9Ik9iamVjdERhdGEiPgoJPHhzbDp2YWx1ZS1vZiBzZWxlY3Q9IkBQ Q29kZSIgLz4KCTx4c2w6YXBwbHktdGVtcGxhdGVzIC8+CjwveHNsOnRlbXBsYXRlPgoKPHhzbDp0 ZW1wbGF0ZSBtYXRjaD0idGV4dCgpIj4KPC94c2w6dGVtcGxhdGU+Cgo8L3hzbDpzdHlsZXNoZWV0 Pgo= --001636c5b0a3a22b970463ed49cb Content-Type: text/plain; charset=US-ASCII; name="llsd-draft-revision-xml-way.txt" Content-Disposition: attachment; filename="llsd-draft-revision-xml-way.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_frpddjwf2 My4xLiAgWE1MIFNlcmlhbGl6YXRpb24KCiAgIFhNTCBzZXJpYWxpemF0aW9uIG9mIExMU0QgZGF0 YSBpcyBpbiBjb21tb24gdXNlIGluIHByb3RvY29scwogICBpbXBsZW1lbnRpbmcgdmlydHVhbCB3 b3JsZHMuICBXaGVuIHVzZWQgdG8gY29tbXVuaWNhdGUgcHJvdG9jb2wgZGF0YQogICB3aXRoIGEg dHJhbnNwb3J0IHRoYXQgcmVxdWlyZXMgdGhlIHVzZSBvZiBhIFR5cGUsIHRoZSB0eXBlCiAgICdh cHBsaWNhdGlvbi9sbHNkK3htbCcgaXMgdXNlZC4KCiAgIFRoZSBEVEQgZm9yIFhNTCBzZXJpYWxp emF0aW9uIG9mIExMU0QgaXMgbGFyZ2VseSBkZXRlcm1pbmVkIGJ5CiAgIGNvbnNpZGVyYXRpb25z IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgozLjEuMS4gIFNlcmlhbGl6aW5n IFNpbXBsZSBUeXBlcwoKICAgTW9zdCBzaW1wbGUgdHlwZXMgYXJlIHNlcmlhbGl6ZWQgYnkgcGxh Y2luZyB0aGUgc3RyaW5nIHJlcHJlc2VudGF0aW9uCiAgIG9mIHRoZSBkYXRhIGFzIGFuIGF0dHJp YnV0ZSBiZXR3ZWVuIHF1b3Rlcy4gIFRoaXMgaXMgdHJ1ZSBmb3IgdW5kZWZpbmVkLAogICBib29s ZWFuLCBpbnRlZ2VyLCByZWFsLCBVVUlELCBzdHJpbmcsIGRhdGUgYW5kIFVSSSB0eXBlZCB2YWx1 ZXMuCiAgIFZhbHVlcyBvZiB0eXBlIGJpbmFyeSBhcmUgZWl0aGVyIHNlcmlhbGl6ZWQgYXMgYW4g YXR0cmlidXRlIGluCiAgIGhleGFkZWNpbWFsIG5vdGF0aW9uLCBvciBieSBwbGFjaW5nIHRoZSBC QVNFNjQgZW5jb2RpbmcgKGRlZmluZWQgaW4gUkZDIDQ2NDgKICAgW1JGQzQ2NDhdICkgb2YgdGhl IGJpbmFyeSBkYXRhIHdpdGhpbiBiZWdpbm5pbmcgYW5kIGVuZGluZwogICB0YWdzLiAgSXQgaXMg ZXhwZWN0ZWQgdGhhdCBmdXR1cmUgdmVyc2lvbnMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIG1heQog ICBhbGxvdyBlbmNvZGluZ3Mgb3RoZXIgdGhhbiBCQVNFNjQsIHNvIHRoZSBtYW5kYXRvcnkgYXR0 cmlidXRlCiAgICdlbmNvZGluZycgaXMgdXNlZCB0byBpZGVudGlmeSB0aGUgbWV0aG9kIHVzZWQg dG8gZW5jb2RlIHRoZSBiaW5hcnkKICAgZGF0YS4KCiAgIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBz aG93cyBhbiBYTUwgZG9jdW1lbnQgcmVwcmVzZW50aW5nIHRoZQogICBzZXJpYWxpemF0aW9uIG9m IHRoZSBpbnRlZ2VyIC01NTkwMzg3MzcuCgogICA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5n PSJVVEYtOCI/PgogICA8bGxzZD4KICAgICA8c29tZWRhdGEgaT0iLTU1OTAzODczNyI+CiAgIDwv bGxzZD4KCiAgIFRoZSBuYW1lIG9mIHRhZyAnc29tZWRhdGEnIGFuZCBvZiBhdHRyaWJ1dGUgJ2kn IGFyZSBkZXRlcm1pbmVkIG91dHNpZGUKICAgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQsCgoK CgoKCgoKQnJhc2hlYXJzLCBldCBhbC4gICAgICAgIEV4cGlyZXMgQXVndXN0IDgsIDIwMDkgICAg ICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICBMaW5kZW4gTGFi IFN0cnVjdHVyZWQgRGF0YSAgICAgICAgICBGZWJydWFyeSAyMDA5CgoKICAgV2hpbGUgdGhpcyBl eGFtcGxlIHNob3dzIHRoZSBzZXJpYWxpemF0aW9uIG9mIGEgYmluYXJ5IGFycmF5IG9mCiAgIG9j dGV0cyBjb250YWluaW5nIHRoZSB2YWx1ZXMgMjIyLCAxNzMsIDE5MCBhbmQgMjM5LgoKICAgPD94 bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KICAgPGxsc2Q+CiAgICAgPHNvbWVk YXRhIGI9IjB4REVBREJFRUYiIC8+CiAgIDwvbGxzZD4KCiAgIG9yCgogICA8P3htbCB2ZXJzaW9u PSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/PgogICA8bGxzZD4KICAgICA8c29tZWRhdGE+CiAgICAg ICA8YiBlbmNvZGluZz0iQkFTRTY0Ij4zcTIrN3c9PTwvYj4KICAgICA8L3NvbWVkYXRhPgogICA8 L2xsc2Q+CgozLjEuMi4gIFNlcmlhbGl6aW5nIENvbXBvc2l0ZSBUeXBlcwoKICAgQ29tcG9zaXRl IHR5cGVzIGluIHRoZSBYTUwgc2VyaWFsaXphdGlvbiBzY2hlbWUgYXJlIHJlcHJlc2VudGVkIHdp dGgKICAgJ2FycmF5JyBhbmQgJ21hcCcgZWxlbWVudHMuICBCb3RoIG9mIHRoZXNlIGVsZW1lbnRz IG1heSBjb250YWluCiAgIGVsZW1lbnRzIGVuY2xvc2luZyBzaW1wbGUgdHlwZXMgb3Igb3RoZXIg Y29tcG9zaXRlIHR5cGVzLiAgQXJyYXkKICAgZWxlbWVudHMsIHdoaWNoIHJlcHJlc2VudCBhIGNv bGxlY3Rpb24gb2YgdmFsdWVzIGluZGV4ZWQgYnkgcG9zaXRpb24sCiAgIGNvbnRhaW4gYSBzaW1w bGUgbGlzdCBvZiB0eXBlZCB2YWx1ZXMuICBNYXAgZWxlbWVudHMgcmVwcmVzZW50IGEKICAgY29s bGVjdGlvbiBvZiB2YWx1ZXMgaW5kZXhlZCBieSBhIHN0cmluZyBpZGVudGlmaWVyLiAgVGhleSBj b250YWluIGEKICAgbGlzdCBvZiBrZXktdmFsdWUgcGFpcnMgd2hlcmUgdGhlICdrZXknIGVsZW1l bnQgZGVzY3JpYmVzIHRoZQogICBpbmRleGluZyBpZGVudGlmaWVyIHdoaWxlIHRoZSB2YWx1ZSAo d2hpY2ggZm9sbG93cyB0aGUgJ2tleScgZWxlbWVudCkKICAgaXMgaXRzIFhNTCByZXByZXNlbnRh dGlvbi4KCiAgIE5vdGUgdGhhdCBlbGVtZW50cyBvZiBhbiBhcnJheSBtYXkgYmUgb2YgZGlmZmVy aW5nIHR5cGVzLiAgQWxzbyBub3RlCiAgIHRoYXQgY29tcG9zaXRlIHR5cGVzIG1heSBjb250YWlu IG90aGVyIGNvbXBvc2l0ZSB0eXBlczsgaXQgaXMgbm90IGFuCiAgIGVycm9yIGZvciBhbiBhcnJh eSBvciBtYXAgdG8gY29udGFpbiBhbm90aGVyIGFycmF5LCBtYXAgb3Igc2ltcGxlCiAgIHR5cGUu CgozLjEuMy4gIEV4YW1wbGUgb2YgWE1MIExMU0QgU2VyaWFsaXphdGlvbgoKICAgVGhpcyBleGFt cGxlIHNob3dzIHRoZSBYTUwgc2VyaWFsaXphdGlvbiBvZiBhbiBhcnJheSB3aGljaCBjb250YWlu cwogICBhbiBpbnRlZ2VyLCBhIFVVSUQgYW5kIGEgbWFwLgoKPD94bWwgdmVyc2lvbj0iMS4wIiBl bmNvZGluZz0iVVRGLTgiPz4KPGxsc2Q+CiA8c29tZWRhdGEKICAgdW5pdmVyc2U9IjQyIgogICBz b21lb25lPSI2YmFkMjU4ZS0wNmYwLTRhODctYTY1OS00OTMxMTdjOWMxNjIiCiAgPgogICA8b3Ro ZXJkYXRhCiAgICAgaG90PSJjb2xkIgogICAgIGhpZ2dzX2Jvc29uX3Jlc3RfbWFzcz0iIgogICAg IGluZm9fcGFnZT0iaHR0cHM6Ly9leGFtcGxlLm9yZy9yLzZiYWQyNThlLTA2ZjAtNGE4Ny1hNjU5 LTQ5MzExN2M5YzE2MiIKICAgICBzdGF0dXNfcmVwb3J0X2R1ZV9ieT0iMjAwOC0xMC0xM1QxOTow MC4wMFoiCiAgIC8+CiAgPC9zb21lZGF0YT4KIDwvYXJyYXk+CjwvbGxzZD4KCiAgICAnc29tZWRh dGEnLCAndW5pdmVyc2UnLCAnc29tZW9uZScsIGFuZCAnb3RoZXJkYXRhJyBpZGVudGlmaWVycyBh cmUKICAgIGRldGVybWluZWQgYnkgY29uc2lkZXJhdGlvbnMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhpcyBkb2N1bWVudC4KCkFwcGVuZGl4IEIuICBYTUwgU2VyaWFsaXphdGlvbiBEVEQKCiAgIChy ZW1vdmVkKQo= --001636c5b0a3a22b970463ed49cb-- From jwatte@gmail.com Fri Feb 27 13:40:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D41B03A6936 for ; Fri, 27 Feb 2009 13:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8RDwP-BDlcX for ; Fri, 27 Feb 2009 13:40:07 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id D5B0F3A689F for ; Fri, 27 Feb 2009 13:40:06 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 5so1617946ywh.49 for ; Fri, 27 Feb 2009 13:40:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=j7C+05I1QzrbpKRol9wAI55Cd5F+Wz8Lu723zo/SloA=; b=r1KWvMvPn09iqrjke5DGe8Z72o5/PiWkHadhKW0gAGVp5b/OgQkqdX+VlMo/lkj/XT KBDfReOFgQYLmgwfpCLt/bvnU5YUeDGgAzcUf5w8FgIsxZnCzvRAca4vlNoa9X4bhlr/ BULrjvSMgJam3rEkID3c6ARXiIvrjiMFfuZhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Pf9MCUmc1qzwGD52cIrVvkIEPsK1swsSKqa5d0chapcRsYPTxCeDPnfY3IgugVgZXR DWpYP357D3kE2IVqZ1KTpNINZTdrl3VDBE5X3vJU+CUegll+O7ndgh3VyhpB/a3WY9ds 1EwI6RRnq34G/MIkQTGt0YDxcQdP6aLhTAAkY= Received: by 10.90.84.17 with SMTP id h17mr495815agb.40.1235770829318; Fri, 27 Feb 2009 13:40:29 -0800 (PST) Received: from ?192.168.168.108? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id 36sm7549923aga.29.2009.02.27.13.40.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 13:40:28 -0800 (PST) Message-ID: <49A85DC9.2020501@gmail.com> Date: Fri, 27 Feb 2009 13:40:25 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <49A80BE4.7000206@cox.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: lenglish5@cox.net, mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 21:40:07 -0000 Morgaine wrote: > > 1. Work in two streams, one explicitly OGP which is very targetted > at a specific solution, and the other explicitly MMOX which is > much wider, with people contributing to one or both. If MMOX > identifies other possible solutions then additional workgroups > could be created to handle them. > 2. Remove the constraints (expressed as an intention > ) > imposed by LL on the solution space, so that MMOX can find > common ground among VW architectures and then seek solutions > without being placed in a straightjacket by Linden-only issues. > Notice that this may even lead to OGP being identified as a good > solution. > 3. Unpack the OGP proposal in all its glory into all the > {problem,solution} pairs that led up to it, and describe the > details in a marathon session of explanation/indoctrination so > that there can be broad buy-in to that technology from a large > proportion of MMOX participants. If they agree that LLSD/OGP > can solve the interop problem for their own worlds equitably, > then we might be onto a winner. > While this seems like possible ways to structure the groups, I still don't know what the groups are supposed to do. What problem are we solving? Which requirements do we need to fill? What use cases led to those requirements? > > Something needs to be done, or the lack of even a rough consensus > might impact badly on our ability to form a workgroup after the BoF, > let alone actually get good work done. I don't mind which path we > take, as long as it provides a means of cooperation in place of > outright conflict. (A bit of conflict is of course both inevitable > and useful.) From my point of view, OGP seems to attempt to solve a problem that is not applicable to vendor-neutral interoperability. It tries to solve the problem of "entity X wants to instantiate an authoritative copy of object Y into server Z." I believe that instantiating authoritative objects (as opposed to showing ghost copies of them) is necessarily technology specific, and thus necessarily outside the scope of a vendor- and technology neutral interoperability protocol. However, I don't know if that comment is even applicable, because we don't have any requirements yet. Sincerely, jw From morgaine.dinova@googlemail.com Fri Feb 27 13:54:00 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6058F3A689F for ; Fri, 27 Feb 2009 13:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KSW8A8zzvBf for ; Fri, 27 Feb 2009 13:53:58 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id D57993A684C for ; Fri, 27 Feb 2009 13:53:57 -0800 (PST) Received: by fxm24 with SMTP id 24so1249405fxm.37 for ; Fri, 27 Feb 2009 13:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QtCBimLOf8dJrXlR8Fs2fixOZK/DhKcl3Cbgj/VrCac=; b=fn1M5856GQzf4IhYSMq6XJXSG8dn3A9xfNwq18USD42vPxfADDY6L3UVjihBmh539b Xrq94Txf5wDdcS80h2lgLLJwpbTLL7H++KrMJWDLJz3Z8jxDcjy87U12Gjg/gJR51TDL /SP7WDcpCeJQa0M7KNRMJCRJW1p0zwLMX5t6Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QpiNavj1dZAuFh/0P6kKX22Rmkv5y9tadM7QV5YJYb5VdVN0B0EuYiyLVkQ6yOK3sA YP9tw8T80ljy4yBXdYSZ68guXFGFlsu1AScQqVZBZUp1dE9dSUpBIJe/H7GdNQphGibC zSp8V8+45g3c661Il5YJElmqG2LPeNOSu+9WU= MIME-Version: 1.0 Received: by 10.181.138.13 with SMTP id q13mr1015191bkn.95.1235771659613; Fri, 27 Feb 2009 13:54:19 -0800 (PST) In-Reply-To: <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <9DFBF8F7-DF47-4CFA-ABD9-50E18F97394A@lindenlab.com> Date: Fri, 27 Feb 2009 21:54:19 +0000 Message-ID: From: Morgaine To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=001485f85a94cb77ec0463ed82f6 Cc: lenglish5@cox.net, mmox@ietf.org Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 21:54:00 -0000 --001485f85a94cb77ec0463ed82f6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Feb 27, 2009 at 5:41 PM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > really? > why is it of no interest to achieve interoperability between 2 or more > worlds of a given type? > By choosing to leave off my phrase "to the MMOX group *as a whole"*, you created a question by omitting the answer already provided. It should be obvious that obtaining interop for only a fraction of all the parties in the group is of no interest "to the MMOX group *as a whole". *One-liner miss-representations and straw men are really not the way to conduct a professional discussion. Morgaine. * * On Fri, Feb 27, 2009 at 5:41 PM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > really? > why is it of no interest to achieve interoperability between 2 or more > worlds of a given type? > > On Feb 27, 2009, at 7:40 AM, Morgaine wrote: > > On Fri, Feb 27, 2009 at 12:27 PM, Lawson English wrote: > >> >> My own take is that fragmenting the working group at this point is >> counter-productive. We can >> recognize several [types of] low-hanging fruit[s] that may apply to many >> worlds or just 2 or more >> of a given type (e.g. Second Life/OpenSIm compatible). > > > > But it is of no interest to the MMOX group *as a whole* to achieve > interoperability between only 2 or more worlds of a given type. Such > progress would be great for the worlds concerned, but of no use to anyone > else. > >> >> >> There's no reason to assume that full interoperability can be obtained >> amongst all worlds >> in the same way, but no reason to assume we can't find points of >> commonality which can >> mix and match. > > > > "Full interoperability" is not something that anyone has proposed, so > knocking it down is just a straw man. Instead, we've been looking for ways > to achieve *some* degree of interop by focusing on just a few things that > are common to virtually all worlds. A common protocol that deals extensibly > with those few things would be an amazing achievement, but locking down the > solution space even before the group has a charter is not the way to go > about it ... except in a group dedicated to a specific solution. > >> >> >> The OGP has made a good start for authentication and TP >> between OpenSim and Second Life, and OpenSim has come up with an >> alternative called HyperGrid. >> Our meeting on video streaming showed that there are points of >> inter-operability between SL, OpenSim >> and Croquet/Qwaq. Surely we can find others. To say: "let us split the >> working group up from the start >> into SL-compatible and incompatible worlds" assumes that we can find no >> common ground at all. >> >> >> Oh I'm fairly certain that we *CAN* find common ground in MMOX --- > indeed, that's the whole reason we're here. Unfortunately the effort is > derailed when one party requires that that all the "common ground" has to be > within their own solution space. > > The only reason I proposed a split is to get around the impasse of what > appears to be one entrenched position, so that everyone can make good > progress on all fronts to the benefit of all. If there are no preconditions > though, then of course we could continue to search for natural common > ground, and I have no reason to believe that we would not succeed. > > The phrase "Where there's a will there's a way" is very germane here. > Given the will to move off one's own turf opens up numerous avenues for > finding common ground with others. > > > Morgaine. > > > > > > > > On Fri, Feb 27, 2009 at 12:27 PM, Lawson English wrote: > >> Jesrad wrote: >> >>> Heartily seconded, there are lots of divergent interests that would >>> hamper the broad adoption of the protocol if we tried to include too >>> many things, just as well as including too little would severly limit >>> the interest of the whole thing for the end users. >>> >>> Which makes me think we might need to tag some of the features as >>> optional. >>> >>> On Fri, Feb 27, 2009 at 10:49 AM, Morgaine >>> wrote: >>> >>> >>>> Well said, Heiner. Conflating the two quite separate interests into >>>> just >>>> one is not helping progress in either direction at the moment. >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>> >> >> My own take is that fragmenting the working group at this point is >> counter-productive. We can >> recognize several [types of] low-hanging fruit[s] that may apply to many >> worlds or just 2 or more >> of a given type (e.g. Second Life/OpenSIm compatible). >> >> In other words, here's more than one possible sub-tree these >> inter-operable fruits are hanging from and >> it is likely more like a digraph than a simple tree (who knows, possibly >> not merely a digraph either if >> there are dependencies that go back up the "tree"). >> >> E.G.: >> >> Interoperability scenarios for virtual worlds >> | >> ------------------------------------------------------------------------- >> | | >> >> Authentication for SL-type worlds Authentication of Other worlds >> / | \ >> / | \ >> -------------------------------------------------------- [...] >> etc >> | | | >> / ] \ >> Agent Domain HyperGrid Something Else >> >> >> >> >> At the same level we might search for alternate ways of: >> >> expressing basic protocols >> >> LLSD vs xxSD vs ... >> >> or of geometry: >> >> OBJ vs SL-extended prims vs Callada vs world-specific terrains/... >> >> or of group IM: >> >> SL-style vs javbber vs irc vs... >> >> Etc. >> >> >> There's no reason to assume that full interoperability can be obtained >> amongst all worlds >> in the same way, but no reason to assume we can't find points of >> commonality which can >> mix and match. >> >> The OGP has made a good start for authentication and TP >> between OpenSim and Second Life, and OpenSim has come up with an >> alternative called HyperGrid. >> Our meeting on video streaming showed that there are points of >> inter-operability between SL, OpenSim >> and Croquet/Qwaq. Surely we can find others. To say: "let us split the >> working group up from the start >> into SL-compatible and incompatible worlds" assumes that we can find no >> common ground at all. >> >> >> >> >> I think that is the wrong way to go. >> >> >> Lawson >> >> >> >> >> >> >> >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > --001485f85a94cb77ec0463ed82f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable =A0
On Fri, Feb 27, 2009 at 5:41 PM, Meadhbh = Hamrick (Infinity) <infinity@lindenlab.com> wrote:
really?

why is it of no interest to achi= eve interoperability between 2 or more worlds of a given type?
<= /blockquote>


By choosing to leave off my phrase "to the MM= OX group as a whole", you created a question by omitting= the answer already provided.=A0 It should be obvious that obtaining intero= p for only a fraction of all the parties in the group is of no interest &qu= ot;to the MMOX group as a whole".

One-liner miss-representations and straw men are really not the= way to conduct a professional discussion.


Morgaine.





On Fri= , Feb 27, 2009 at 5:41 PM, Meadhbh Hamrick (Infinity) <= ;infinity@lindenlab.com> wrote:
r= eally?

why is it of no interest to achieve interoperabil= ity between 2 or more worlds of a given type?

On Feb = 27, 2009, at 7:40 AM, Morgaine wrote:

= On Fri, Feb 27, 2009 at 12:27 PM, Lawson English <lenglish5@cox.net>= ; wrote:
=A0
My own take is that fragmenting the working group at this point is count= er-productive. We can
recognize several [types of] low-hanging fruit[s] that may apply to many w= orlds or just 2 or more
of a given type (e.g. Second Life/OpenSIm compa= tible).


But it is of no interest to the MMOX group= as a whole to achieve interoperability between only 2 or mor= e worlds of a given type.=A0 Such progress would be great for the worlds co= ncerned, but of no use to anyone else.


= There's no reason to assume that full interoperability can be obtained = amongst all worlds
in the same way, but no reason to assume we can't find points of commo= nality which can
mix and match.


"Full int= eroperability" is not something that anyone has proposed, so knocking = it down is just a straw man.=A0 Instead, we've been looking for ways to= achieve some degree of interop by focusing on just a few things tha= t are common to virtually all worlds.=A0 A common protocol that deals exten= sibly with those few things would be an amazing achievement, but locking do= wn the solution space even before the group has a charter is not the way to= go about it ... except in a group dedicated to a specific solution.


= The OGP has made a good start for authentication and TP
between OpenSim= and Second Life, and OpenSim has come up with an alternative called HyperG= rid.
Our meeting on video streaming showed that there are points of inter-opera= bility between SL, OpenSim
and Croquet/Qwaq. Surely we can find others.= To say: "let us split the working group up from the start
into SL= -compatible and incompatible worlds" assumes that we can find no commo= n ground at all.


Oh I'm fair= ly certain that we CAN find common ground in MMOX --- indeed, that&#= 39;s the whole reason we're here.=A0 Unfortunately the effort is derail= ed when one party requires that that all the "common ground" has = to be within their own solution space.

The only reason I proposed a split is to get around the im= passe of what appears to be one entrenched position, so that everyone can m= ake good progress on all fronts to the benefit of all.=A0 If there are no p= reconditions though, then of course we could continue to search for natural= common ground, and I have no reason to believe that we would not succeed.<= br>
The phrase "Where there's a will there's a way" is v= ery germane here.=A0 Given the will to move off one's own turf opens up= numerous avenues for finding common ground with others.


Morgain= e.







On Fri, Feb 27, 200= 9 at 12:27 PM, Lawson English <lenglish5@cox.net> wrote:
=
Jesrad wrote:
Heartily seconded, there are lots of divergent interests that would=
hamper the broad adoption of the protocol if we tried to include too
m= any things, just as well as including too little would severly limit
th= e interest of the whole thing for the end users.

Which makes me th= ink we might need to tag some of the features as optional.

On Fri, Feb 27, 2009 at 10:49 AM, Morgaine
<morgaine.dinova@googlemai= l.com> wrote:
=A0
Well said, Heiner. =A0 Conflating the two quite separate interests into ju= st
one is not helping progress in either direction at the moment.
<= br> Morgaine.


=A0 =A0

My own take is that fragmenting the working group at this point is counter= -productive. We can
recognize several [types of] low-hanging fruit[s] t= hat may apply to many worlds or just 2 or more
of a given type (e.g. Se= cond Life/OpenSIm compatible).

In other words, here's more than one possible sub-tree these inte= r-operable fruits are hanging from and
it is likely more like a digraph= than a simple tree (who knows, possibly not merely a digraph either if
there are dependencies that go back up the "tree").

E.G= .:

Interoperability scenarios for virtual worlds
=A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
---------------------------------= ----------------------------------------
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|

Authe= ntication for SL-type worlds =A0 =A0 =A0 =A0 =A0Authentication of Other wor= lds
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0| =A0\= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 / =A0| =A0 \ =A0 =A0 --------------------------= ------------------------------ =A0 [...] =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 et= c
| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/ ] \
Agent Domain =A0 = =A0 HyperGrid =A0 =A0 =A0Something Else




At the same= level we might search for alternate ways of:

expressing basic protocols

LLSD vs xxSD vs ...

or = =A0of geometry:

OBJ vs SL-extended prims vs Callada vs world-speci= fic terrains/...

or of group IM:

SL-style vs javbber vs i= rc vs...

Etc.


There's no reason to assume that full interope= rability can be obtained amongst all worlds
in the same way, but no rea= son to assume we can't find points of commonality which can
mix and= match.

The OGP has made a good start for authentication and TP
between O= penSim and Second Life, and OpenSim has come up with an alternative called = HyperGrid.
Our meeting on video streaming showed that there are points = of inter-operability between SL, OpenSim
and Croquet/Qwaq. Surely we can find others. To say: "let us split th= e working group up from the start
into SL-compatible and incompatible w= orlds" assumes that we can find no common ground at all.




I think that is the wrong way to go.
=

Lawson








____________________________= ___________________
mmox mailing list
mmo= x@ietf.org
https://www.ietf.org/mailman/listinfo/mmox


--001485f85a94cb77ec0463ed82f6-- From dyerbrookme@juno.com Fri Feb 27 14:14:06 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6578C3A69FE for ; Fri, 27 Feb 2009 14:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=0.797, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0xE6n-SvyWT for ; Fri, 27 Feb 2009 14:14:05 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 106DD3A684C for ; Fri, 27 Feb 2009 14:14:04 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail10.vgs.untd.com [10.181.12.150]) by smtpout01.vgs.untd.com with SMTP id AABE4S3P8ARYQDA2 for (sender ); Fri, 27 Feb 2009 14:14:22 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNuiF2VV2jWbsYwM2kttkNug== Received: (from dyerbrookme@juno.com) by webmail10.vgs.untd.com (jqueuemail) id PAFKUZ6C; Fri, 27 Feb 2009 14:13:42 PST Received: from [10.181.11.37] by webmail10.vgs.untd.com with HTTP: Fri, 27 Feb 2009 22:13:24 GMT X-Originating-IP: [10.181.11.37] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Fri, 27 Feb 2009 22:13:24 GMT To: Chris.Down@alcor.co.uk X-Mailer: Webmail Version 4.0 Message-Id: <20090227.171324.14645.0@webmail10.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 6:3:2452713247 X-UNTD-Peer-Info: 10.181.12.150|webmail10.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: mmox@ietf.org, dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 22:14:06 -0000 >I do not intend to carry on this thread as (a) It does not really belong on this list (b) You are obviously not interested in anyone's point of view but your = = own. >I have given you some friendly advice and you choose to criticise and = ignore it. You twist peoples replies and are deliberately obtuse Chris, I made a short comment to Zha's (David Levine's) demand to untether the = terms avatar, identity, etc. and move to generalities -- which I felt ac= complished the job of stripping out commerce and IP that the AWGroupies = keep doing. That's all. I've been having this same debate with them for = a year or more. I felt it was necessary merely to put down a marker: "He= re is where they go off the map and depart from contextual definitions i= n the name of 'expediency' to get their way again". That's all. In fact,= if I were the non-Lindens on this list, from their set of interests, I'= d also put a flag down on that and say to myself, "Here's where they ins= ist on setting the generalities themselves so as to claim them for their= own set of specifics later." You chose to give me a huge lecture and diatribe defending your opensour= ce way of life. That's fine, but it simply fails to persuade me. Basically, this debate plays out over and over again, and not only with = me, as surely you are aware, in a very typical and irrational pattern --= irrational, because it is premised on an intolerant view that sees and = claims falsely intolerance in others precisely because it cannot conceiv= e of co-existence and pluralism: 1. Opensource proponent insists that everything be opensource and that p= references always go to opensource in every endeavour, whether social me= dia (laconic), websites (Drupal), educational sites (Moodle), virtual wo= rlds (OpenSim), etc. Browbeaten, those involved go along, though they fi= nd the software difficult, wonky, non-user-friendly, like Linux. 2. If they criticize a single thing about any of this, or say a single t= hing in defense of proprietary code or "walled gardens," they are lectur= ed and reminded that "the entire Internet" was founded on the opensource= concept and "they owe their very blog or world to opensource" and "shou= ld be grateful" -- although *criticism* or *demand for plurality* isn't = the same thing at all as rejecting the role of opensource in the buildin= g of the Internet, or rejecting someone's choice for opensource. These a= re all acknowledge and all understood, but they are *criticized* as not = being viable, and therefore *choice* is needed. 3. Having encountered a rebuff to their zealotry, the opensource propone= nt then pushes further, more shrilly, and more hysterically. Now, the pe= rson who merely began with a criticism of non-usefulness, or a demand fo= r *choice* is told that they are "obtuse" or "stupid" or "Anne Coulter" = or a "right-whinger" or "refuse to concede others' points of views" -- b= y which is actually meant, "You refuse to come round to our cultic point= of view" by this time. 4. If the thoroughly browbeaten and bullied critic of opensource continu= es to hold fast, now they are told "You are preventing other people from= having a point of view" (obviously a false proposition) or "you are del= iberately dense" or some other state is impugned to them which amounts t= o this: "you refuse to come round and join the hive mind collective on t= his". Well, no, I don't. I refuse. And that's normal. Nothing I've seen about = opensource in the four years I've had to see it very up close and person= al has done a thing to persuade me that it is a viable system that leave= s choice of systems. None of its propositions and claims are true for vi= rtual worlds that I can see ("bugs are visible and fixable to a thousand= eyes") etc. Whatever the usefulness of Apache or Gimb or whatever, so w= hat? It's not the answer for everything; it isn't user friendly; it does= n't *work*. I can't be forced to believe in software religion in defianc= e of the evidence of my own experience. I'm sorry, but I don't give into emotional blackmail ("I gave you friend= ly advice and you refused to heed it" =3D "You refused to come round to = our point of view") or concede your point of view. It's because I disag= ree with its viability. I have proof of its viability, anywhere, anyhow.= You can keep citing "The Internet" or "this guy I know who makes money = from Creative Commons" or whatever you like but none of it is *persuasiv= e* as a *system for everybody, that is free, and enables choices*. That = isn't the same thing as *acknowledging your right to have this point of = view* or accepting that *for you, this religion is helpful*. = That's all, it's about choice. I realize that for whatever reason even t= hose decidedly four-square for closed worlds and proprietary code and ro= bust IP protect, for reasons that continue to remain obscure to me, embr= ace the opensource shtick (free labour? free R&D budget?). In any event,= I have no requirement to argue about this or debate it further on this = particular list, which is obviously largely engaged in technical standar= d-making. However, if you attack me and lecture me and hector me with th= e extremist opensource point of view, I will simply defend my perspectiv= e on this which I believe is a mainstream consumer perspective on virtua= l worlds. ____________________________________________________________ Click here to save cash and find low rates on auto loans. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLaWySIWwBcxnL7KFaUZFu= wEZEOqrpk9Xm94tzdK2DHyWmqezkin2/ From belxjander@gmail.com Fri Feb 27 14:26:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED3A53A69A6 for ; Fri, 27 Feb 2009 14:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[AWL=-1.156, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, MIME_QP_LONG_LINE=1.396, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xU0HYxS48Gp3 for ; Fri, 27 Feb 2009 14:26:44 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 4F9C53A684C for ; Fri, 27 Feb 2009 14:26:44 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1482833wfd.31 for ; Fri, 27 Feb 2009 14:27:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=V3ZPM44pR7Ks7rmenKCjy9CgmJWQNH39F/CnQT8fkKA=; b=Ee1FD7rfBUyp/+sJAXxB8X+/8bYEt5HheJDHyO7idArYuTXVos+vahCpJORUiX5my/ woyxWeQFNWd/tFEBy6Kk8MgUQP6y6EKvpPnYOZVveUrfC44LUVduTFprB4QQEeQARqPC DqSAN91M+FoqLekPpXw6mUu/uskh4eJRpU4/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=gPg5FEeN0tyBcB5quisQo6MxSuqS7+m1DkfeLOMGlDMCnRDl99whwykBEwfuzMNpUP /olJ/apehCNxJ0Cwe8WwlqFKfH4SdZx/rUbp1fZiQ0XwKiq2AF57ZS1Aym5r73imhFIm 1NoQk9xSRILnN19qlE+VqHMyiMwLmXvOeEr1g= Received: by 10.142.237.20 with SMTP id k20mr1503428wfh.127.1235773627419; Fri, 27 Feb 2009 14:27:07 -0800 (PST) Received: from ?10.2.1.3? (p3159-ipbfp201tottori.tottori.ocn.ne.jp [122.21.102.159]) by mx.google.com with ESMTPS id 22sm7239652wfd.26.2009.02.27.14.27.05 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 14:27:06 -0800 (PST) From: Kajikawa Jeremy To: Chris Down In-Reply-To: <49A81F25.3030702@alcor.co.uk> References: <20090227.105308.6400.0@webmail06.vgs.untd.com> <49A81F25.3030702@alcor.co.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TNv8yH0/vlvarcRIKOd3" Date: Sat, 28 Feb 2009 07:21:42 +0900 Message-Id: <1235773302.6597.41.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: mmox@ietf.org, Prokofy Neva Subject: Re: [mmox] MMOX ...mixed threading... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 22:26:46 -0000 --=-TNv8yH0/vlvarcRIKOd3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I agree with you on this one Chris... "dyerbrookme"/"Pokofy Neva"... I am utterly surprised by how disconnected some of your statements appear to be with regards conversations on this list. TCP/IPv4 supports commerce... does it have any commercial functions inside the protocol?... from my understanding NONE... TCP is limited scope to a reliable transport, UDP is best-effort unreliable, IP and ICMP is framing for the above to work on a commonality... I see this list as endeavouring to provide a TCP or UDP hosted mechanism that is application specific forms of these protocols for allowing objects to have both OSS and Commercial backing... is an object transferred containing "commercial" content? yes/no Whichever... as long as it is transferable or otherwise able to have a money transaction connected for those interested in money. This list is remaining a *technical* discussion and we are trying to remain "option open" with future proofing the protocol in-use... My own proposal to this list was to have any object encoding allow arbitrary extensible attributes attached to an ObjectID... each VW may allow the OID to be remapped as long as the attributes in full remain together. with regards your anti-FOSS commentary... I don't care what you believe in as long as your input is /*constructive*/ or proposing a mechanism that does not detract or otherwise limit the functionality your welcome to participate I don't expect you to read this far or otherwise think about what Ive said, I am treating this message akin to UDP. All: apologies for the long message... so far we have "3d space" for location provided by each system needing "object" creation/deletion/set/get updates... and we have need of "set"ting "motion". I propose the standard have both UDP and TCP style messages in 2 queues the UDP or "throwaway" messages for updating movement. The option for selecting an object as being "Avatar" or representing a person. using extending attributes like this for some machine readable and allowing for records of human readable attributes would then allow us to distill further... What kind of attributes are needed? What kind of attributes are common? Do we need to mandate any "special" handling or leave that to implimentors? Thats it for this braindump... Im just trying to keep up with this list as another amateur with interest... On Fri, 2009-02-27 at 17:13 +0000, Chris Down wrote: > This did not get to the list and therefore I am including your complete=20 > email in my reply and keep my comments short. >=20 > I do not intend to carry on this thread as > (a) It does not really belong on this list > (b) You are obviously not interested in anyone's point of view but your=20 > own. >=20 > I have given you some friendly advice and you choose to criticise and=20 > ignore it. You twist peoples replies and are deliberately obtuse. >=20 >=20 > On 27/02/2009 15:53, dyerbrookme@juno.com wrote: > > I'm going to answer this on the list as I think off-list admonishments = are inappropriate. > > > >> You seem to object to open source and I don't understand why. I use bo= th closed an opensource products and I have no objection to paying for the = closed source products I use as long as I get support for that product. > > > > I object to opensource exclusivity and the collectivist and forced-shar= ing mentality that goes along with it as any kind of norm. It's not a norm.= The overwhelming majority of hundreds of millions of people use Microsoft = or Apple operating systems, not Linux. This is why I often say "open source= =3Dclosed society" -- because of the failure to ensure there is *choice* be= tween collectivist and proprietary software and because of the notion that = a project is "open" merely technically, although usually it is so complex a= nd rigid in its cultural norms that it isn't really open in practice. >=20 > Uhm. MAC OSX is a layer on top of Darwin. "Darwin is an open source=20 > POSIX-compliant computer operating system released by Apple Inc. in=20 > 2000. It is composed of code developed by Apple, as well as code derived=20 > from NEXTSTEP, FreeBSD, and other free software projects". >=20 > >> I am sure that you are aware that without opensource you would not hav= e SecondLife. The viewer that LL wrote comprises a lot of opensource produc= ts. > > > > This notion that you cannot criticize opensource mentality without bein= g lectured with homilies like "Don't you know the Internet wouldn't be here= today" etc. is silly. So what? It's only one form of property, not exclus= ively the norm, nor necessarily desirable. By itself, it does not ensure *t= he choice of commerce*. That's the problem. > > > >> The servers that LL use run on (openssource)Linux machines as does a l= arge portion of the internet. > > > > And...so what? A goodly portion of the Internet *does not* run on Linux= ness too. Without the commerce or the ebays and the amazons, there'd be no = Internet *either*. And a large part of the consumer sector of IT *does not*= run on Linux. So there. There is no need for us to genuflect constantly to= the Linux cult in creating standards for the Metaverse. > > > >> People will always put forward unpopular ideas, it does not mean that > > they will be adopted. Anyone involved in SecondLife, Opensimulator or > > any any other similar product is fully aware of the necessity for a > > system that allows (secure) trading. However there are many use cases > > that this is not necessary and in fact having such a system mandated > > would cause problems. > > > > This is a peculiar proposition indeed. Suddenly, there's an admission = that concepts stripping out trading and commerce might be "unpopular". Say,= there'd be a good reason for that! Because they are not the norm, nor refl= ective of the mass of human activity on the real world planet. The idea tha= t in real life, you would never strip out trading or secure trading from an= y country unless you were way out on the extremes of say, a North Korea, do= esn't seem to mitigate against your extremism. Just because there are purpo= rtedly "use cases" that dictate that trade is "not necessary" is hardly a r= eason to drop commerce completely from a system (I think such use cases wou= ld be in the distinct minority and your claim that there are "many" isn't p= roven). > You choose to deliberately misrepresent what I said. > > > > It surely is odd that I would have to stump for you all to put commerce= , trade, property rights and such into a virtual world system when every si= ngle one of you on this list benefits from commerce in some fashion, if not= directly by working for profit-making companies that function in the real = world in free enterprise systems that make your profit from selling technol= ogy, services, or entertainment -- or from universities that exist either o= n taxpayers' funds generated from commerce or from private foundation grant= s generated from the last centuries' wealth in industries. > > > > So I can only throw that back to you, the way you constantly and specio= usly throw at critics this notion that "OMGODZORZ the entire Internet is ba= sed on opensource and Linux so shut up already". > > > >> What David said was "..... for the moment, I'm going to keep those ter= ms off the table to think about the problem in its more general form." > > > > Yes, a seemingly innocent, innocuous, practical, speculative sort of pr= oposition that is "just for the prototyping" and "just for discussion" and = "just to make it easy to conceptualize". > > > > And yet I point out that it is at this moment that all the tethered ter= ms of avatar=3Dperson, property rights, geographic contiguity (the hatred o= f geographic contiguity by extremists often goes with the hatred of commerc= e for reasons I don't yet understand), etc. all begin to lose their mooring= s and we enter the realm of Extropia or the Bright Future of Communism. I s= o marked the moment. My purpose in so marking the moment wasn't to engage i= n lengthy political debates on a "list just here to talk about technology p= lease" but to point out the particular moments when decisions about social = systems get welded into the technological blueprint. For you, commerce is a= model and an add-on. It isn't for the overwhelming majority of users of Se= cond Life who are utterly unintersted in opensource sandboxing but exist in= a RL versimilitude of consumer creation and commerce. > > > >> To me that does not say these terms and their implications are being > > abandoned. It says we need to think in general terms before we look at > > specifics and I totally agree with this. I am not adopting any ism or > > ideology I am adopting a technique that assists it defining the outline= before adding the detail and complexities that will eventually be necessar= y. > > > > Well, that's "to you" *shrugs*. I don't see it as "moving to general te= rms" but rather a profoundly disruptive, extremist, heavily ideological mov= e, untethering the basic concepts of avatar, space, inventory, etc. from th= eir > > > > You might say, "Good! The internet is about evolution! Embrace the inev= itable! and all the other social Darwinisms we're always forced to endure f= rom extremists. But it's not about having a political discussion. It's prac= tical. It's saying, "Who's going to pay for this carnival ride, dude?" beca= use you've stripped out commerce and invoked wacky notions of everybody gen= erating soup out of stones and profit out of sharing as they goof off from = their big IT jobs where they are paid for other mundane tasks. > > > >> Your arguments do not come across as logical they come across as wordy= and, dare I say, aggressive. My interpretation is that commerce, currency= , property and profit are at a level of abstraction that will be considered= as the standards develop. > > > > Um, I'm awfully glad you have a felt need for detecting and berating ag= gressiveness. This is laudable on a list. I hope you will be an equal-oppor= tunity applier of this laudable goal to the many other aggressive statement= s made on the list by people with decidedly ambitious agendas. > > > > Commerce, currency, property and *gasp* profit (the horrah!) are not ab= stractions, not tack-on modules, not afterthoughts, but should be at the he= art of the system. If they aren't, you no longer have choice. You've scrubb= ed them out of the DNA at the start. That's wrong. The tack-on modules shou= ld be the minority worlds that want to have endless tekkie sandboxing and s= haring. Not a single one of the opensim projects has any viable population;= those that even have any participation have put in some form of commerce, = even with their own internal currency. > > > >> Why would you think I was situated at the extreme? Nothing I said in m= y email suggested that. My point of view is that in this (virtual)world the= re is room for people at the copyleft end of the spectrum and at the "I am = only in it for the money" plus all sahdes in between. I have a potential ap= plication for a virtual world, it will be a completely closed environment a= nd it will not need any currency, trading or IP protection but will require= interop between other instances of the application. I will earn my money/p= rofit from the products I sell that are used with the application. > > > > You are situated at the extreme if you are unwilling to put in a list o= f the basic ingredients of a virtual world at the start the functions of tr= ade, commerce, currency etc. that reflect an inherent proposition of privat= e property. Why is that so scary? It ought to be normal in the course of th= ings. Every single MMORPG designer in the entire universe puts trade and in= ventory and currency into their game without a blink of the eye. What happe= ns to virtual world makers that they get all weird about doing this?! > > > > I fail to see, if you have an application for a closed non-currency, no= n-copyright world that interoperability with other worlds that *do* have cu= rrency and copyright would present any sort of problem, unless of course yo= u were expecting them to pour all their content for free, without permissio= ns, and without payment, into your world. It ought to be obvious from plent= y of real-life examples and from the examples of incidents we already see h= appening with these virtual worlds: if you lay down a system of capitalism,= a system of socialism can fork off from it; if you lay down a system of co= mmunism, a system of capitalism cannot fork off from it. > > > >> I agree with you here and what I am saying is (trying to be diplomatic= ) it is not necessarily what you say that is putting people off it is the w= ay that you say it. It can come across as slightly aggressive and intimidat= ing. I am not trying to offend you I am only trying to express my concern.O= n this list, I suggest that it may be better to put your views forward in a= more succinct and logical manner. > > > > Once again, you're suggesting that there is something inherently illogi= cal or logically fallacious about calling for commerce, currency, capitalis= m. But the illogic comes in fact with demanding the opposite. > > > >> Leave your other views on opensource and techno communism for your blo= g and we will all get along fine :-) > > > > I fail to see why I have to be driven off to my blog as if I've raised = something completely wacky -- like the concept of Extropianism itself overr= epresented on this list. It's very important for someone to speak up at the= outset of the interoperability exercise and point out that choices are bei= ng lost, options are being stripped out, forced marches are being flogged b= ecause of a few who showed up, under the tyranny of those who show up, to i= nsist on their own extremist vision. We're already suffering from that prob= lem with the AWG/OGP which began their work by questioning the viability of= currency in the design documents and raising a storm of questions about in= tellectual property. > > > > It's important to come out of the code cave and realize that virtual wo= rlds are for masses of people. Masses of people don't like living under tec= hnocommunism. It's a closed niche that is attractive only for some. They ar= e entitled to that choice. They should not impose it on everyone else. >=20 >=20 > Chris >=20 > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-TNv8yH0/vlvarcRIKOd3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJqGd2AAoJECHrKutFYVwTrfAP/jjKCQN9r6vE8yM1PyTH3IxP VQ7yUFgRLjjIXBavKBz11o0HxuBo5AGc4WxhiWyLyW4PcktbXOg5OyvvTj5/Ozqd QApdODRI0MzS+8+UmO1jWkVTT5rEFIGVMvSklV8P7Bi70/45zmcnFbWtqfYSZVwv xCBN3a4AhPPqz9ECx8CATWgNFO99MjCkDmpwi2tJNw2jSFxLBMN8ZiOK1OWeZ2Lt NFQ40aMsHDSXyhV3MjdgxLLQYXdqkyryaVb9QZ9OcR/YxtN0Fxz8HDZycBe1jX4n l3hJVIYlThzRpf8L+y7nfQge+PLajNBG4YmEwl5g0dYJPVxIVFEKDMU3m7RJvli/ qj9rpU94cCn9SGyvLDp+5SRe5pE46bTTgy9NyXoqX8b64fSLfbeEUyOuE3vVYIDe 7f80vn48WkAY+IGfEywEQKDpc+3HG3biWtHgcqIcGau53j7BSTsLObrdkeyC5lDy Og55ztLbmz7jwCKyc5A2KJRbDIMzHo+QYh+VVunsYS5Hc+R/IUWCUl27+5Q8B8X+ 5p9qv3ieSoU6zpj6t3CSUDwpYCntW4Ih9D1UZyQvSyNfBFu4ktnclZelwJkbvLm3 KEPctmwgfxxrYr6Ci9Q314oT2sG4yehKFsQZm93M/23a9txXQGydujaVYAM69SRR 1jqvZ8WybLKxy3pLLHf2 =4dC2 -----END PGP SIGNATURE----- --=-TNv8yH0/vlvarcRIKOd3-- From belxjander@gmail.com Fri Feb 27 14:39:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2AE33A68A4 for ; Fri, 27 Feb 2009 14:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8x3Rfs7ZbBZG for ; Fri, 27 Feb 2009 14:39:29 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 6ED5A3A67B6 for ; Fri, 27 Feb 2009 14:39:29 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so1487812wfd.31 for ; Fri, 27 Feb 2009 14:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer; bh=NtPwuVjune8CM1IK31fECGCLUIHojwc85sKItS2VkJU=; b=DxGxM1TduftjQ8vw6bDN8Fl9IF42VHkNe4y3zxzsnxSzD4vZ+q4E3esM6wASg57srD 7WCHeokltpP1bEgSWCxJ5WNAVp5Vx/E1DyMGeHUlojJ4U06vqs2mmHCDAS2lnUfzi62y 5VZIgjHKAOT2dSbpmpurBzTSIwzM4u5EEXjLw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; b=vMoBTPsiXWdBvZ/k6k532bH93ufSNaU6pGtZTGixHHUVmXsTOw3pU8EwvMo7peLQhq OWF+T5Xx6MjSW/35gKGkrPkGgiwVNLvr9RReMxVQA6fjoWl3Vi3EQuJ1pk5an0O3BZq7 WBL+739lD5U+nFiahKoXUYHHtnW98SVk9hKcM= Received: by 10.142.135.16 with SMTP id i16mr1503572wfd.250.1235774392040; Fri, 27 Feb 2009 14:39:52 -0800 (PST) Received: from ?10.2.1.3? (p3159-ipbfp201tottori.tottori.ocn.ne.jp [122.21.102.159]) by mx.google.com with ESMTPS id 30sm9059341wff.7.2009.02.27.14.39.50 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 14:39:51 -0800 (PST) From: Kajikawa Jeremy To: "dyerbrookme@juno.com" In-Reply-To: <20090227.171324.14645.0@webmail10.vgs.untd.com> References: <20090227.171324.14645.0@webmail10.vgs.untd.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-X3DqbybXKjlCZ4STg0tc" Date: Sat, 28 Feb 2009 07:34:26 +0900 Message-Id: <1235774066.6597.52.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Cc: "mmox@ietf.org" Subject: Re: [mmox] (no subject) X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 22:39:30 -0000 --=-X3DqbybXKjlCZ4STg0tc Content-Type: text/plain Content-Transfer-Encoding: quoted-printable You want a specific use case example where the FOSS community provides? The BSD network stack as reworked by Microsoft for Windows Networking to have *any* network functionality in windows... THAT is a commercial introduction of OpenSource into *every* machine with a copy of Windows from Microsoft installed, version 3.1 through latest 2008 and Windows 7... they all still contain elements of that sources. You can check the Windows Developer materials for any reference to the Regents of Berkeley University. a second example to cite would be Caldera Systems and RedHat... without which as an *alternative* (even as user-unfriendly as you claim)... the US Dept of Justice would have had no choice but to break Microsoft as being a monopoly... you can thank open source for existing for giving you continued support of your choice to use Windows in its current form. FOSS is a choice, one you choose to consider as broken or user-unfriendly, my own choice is the other, I find Microsoft OS provision as restrictive and limited, along with its own choices of User-Friendliness, I'll accept some software as needing commercial interest where it is a technical means of supporting an interest that is shared, but to be forced to choose software based on a pre-requisite and not have choice... THAT is where *I* draw my line... Thank you for your time in reading, I also notice you appear to only respond to this list for your own shill and not respond to direct questions to find out further or elicit focus towards what the shared goal here? or am I missing reading messages to this list? Jeremy On Fri, 2009-02-27 at 22:13 +0000, dyerbrookme@juno.com wrote: > >I do not intend to carry on this thread as > (a) It does not really belong on this list > (b) You are obviously not interested in anyone's point of view but your=20 > own. >=20 > >I have given you some friendly advice and you choose to criticise and=20 > ignore it. You twist peoples replies and are deliberately obtuse >=20 > Chris, >=20 > I made a short comment to Zha's (David Levine's) demand to untether the t= erms avatar, identity, etc. and move to generalities -- which I felt accomp= lished the job of stripping out commerce and IP that the AWGroupies keep do= ing. That's all. I've been having this same debate with them for a year or = more. I felt it was necessary merely to put down a marker: "Here is where t= hey go off the map and depart from contextual definitions in the name of 'e= xpediency' to get their way again". That's all. In fact, if I were the non-= Lindens on this list, from their set of interests, I'd also put a flag down= on that and say to myself, "Here's where they insist on setting the genera= lities themselves so as to claim them for their own set of specifics later.= " >=20 > You chose to give me a huge lecture and diatribe defending your opensourc= e way of life. That's fine, but it simply fails to persuade me. >=20 > Basically, this debate plays out over and over again, and not only with m= e, as surely you are aware, in a very typical and irrational pattern -- irr= ational, because it is premised on an intolerant view that sees and claims = falsely intolerance in others precisely because it cannot conceive of co-ex= istence and pluralism: >=20 > 1. Opensource proponent insists that everything be opensource and that pr= eferences always go to opensource in every endeavour, whether social media = (laconic), websites (Drupal), educational sites (Moodle), virtual worlds (O= penSim), etc. Browbeaten, those involved go along, though they find the sof= tware difficult, wonky, non-user-friendly, like Linux. >=20 > 2. If they criticize a single thing about any of this, or say a single th= ing in defense of proprietary code or "walled gardens," they are lectured a= nd reminded that "the entire Internet" was founded on the opensource concep= t and "they owe their very blog or world to opensource" and "should be grat= eful" -- although *criticism* or *demand for plurality* isn't the same thin= g at all as rejecting the role of opensource in the building of the Interne= t, or rejecting someone's choice for opensource. These are all acknowledge = and all understood, but they are *criticized* as not being viable, and ther= efore *choice* is needed. >=20 > 3. Having encountered a rebuff to their zealotry, the opensource proponen= t then pushes further, more shrilly, and more hysterically. Now, the person= who merely began with a criticism of non-usefulness, or a demand for *choi= ce* is told that they are "obtuse" or "stupid" or "Anne Coulter" or a "righ= t-whinger" or "refuse to concede others' points of views" -- by which is ac= tually meant, "You refuse to come round to our cultic point of view" by thi= s time. >=20 > 4. If the thoroughly browbeaten and bullied critic of opensource continue= s to hold fast, now they are told "You are preventing other people from hav= ing a point of view" (obviously a false proposition) or "you are deliberate= ly dense" or some other state is impugned to them which amounts to this: "y= ou refuse to come round and join the hive mind collective on this". >=20 > Well, no, I don't. I refuse. And that's normal. Nothing I've seen about o= pensource in the four years I've had to see it very up close and personal h= as done a thing to persuade me that it is a viable system that leaves choic= e of systems. None of its propositions and claims are true for virtual worl= ds that I can see ("bugs are visible and fixable to a thousand eyes") etc. = Whatever the usefulness of Apache or Gimb or whatever, so what? It's not th= e answer for everything; it isn't user friendly; it doesn't *work*. I can't= be forced to believe in software religion in defiance of the evidence of m= y own experience. >=20 > I'm sorry, but I don't give into emotional blackmail ("I gave you friendl= y advice and you refused to heed it" =3D "You refused to come round to our = point of view") or concede your point of view. It's because I disagree wit= h its viability. I have proof of its viability, anywhere, anyhow. You can k= eep citing "The Internet" or "this guy I know who makes money from Creative= Commons" or whatever you like but none of it is *persuasive* as a *system = for everybody, that is free, and enables choices*. That isn't the same thin= g as *acknowledging your right to have this point of view* or accepting tha= t *for you, this religion is helpful*.=20 >=20 > That's all, it's about choice. I realize that for whatever reason even th= ose decidedly four-square for closed worlds and proprietary code and robust= IP protect, for reasons that continue to remain obscure to me, embrace the= opensource shtick (free labour? free R&D budget?). In any event, I have no= requirement to argue about this or debate it further on this particular li= st, which is obviously largely engaged in technical standard-making. Howeve= r, if you attack me and lecture me and hector me with the extremist opensou= rce point of view, I will simply defend my perspective on this which I beli= eve is a mainstream consumer perspective on virtual worlds. >=20 >=20 > ____________________________________________________________ > Click here to save cash and find low rates on auto loans. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLaWySIWwBcxnL7KFaUZFuw= EZEOqrpk9Xm94tzdK2DHyWmqezkin2/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --=-X3DqbybXKjlCZ4STg0tc Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iQIcBAABAgAGBQJJqGpyAAoJECHrKutFYVwTjPQQALBs93ofb3nEf7ZtiTLbidlg 4JEjOj2aa5d4W9WlJpCVmXMlKI/dbzAei60jq76qymZZ0Mm/rHG6jJEzS7pXg7OW Lzj6cfoc9oHebrRpl5W2UOS679om6aJUtgF2+BBHslW7wVoaj2E+NkC05QbhAsKP nmtPoNSkNYz9Inwd3Y2/0EhJL6mB5tBAu5v2SEl8bRqiJ8wYiZ+++hXGJEydNGQN XQDbSu3z0kPBx0ZGjCtHxnX0IY6d0kC5HKfl2QJc3Q9LGTX1t8Db7diC7E8Eojws BEFSbYsY7vJHcm2qXg57gBvp0/BUpwrEBKpfRm2FXDGIDxYzzaXgzLGyyjQSe3v5 uGE34ykChs6UWGwfNrq31Xrthzh6J1/CPCiSk2EaMSYWBF6O92kU/KJ7Cde16uK1 VDxzbvMzkcXIUzAMo1fh6KnoojaTxpJ7fB/YgmredDaNUYX5BiOGGX27GEy5eQIB qn+TAM12JaKsOJRMEH83zzXvbcQx2npqT+7sC3xX+RN3xxaubQpU75Or5S0L6KoV jHxd1jDAwdPDfhNjP3T3aMpTwQZ+JEeyRTxwq/AyrjG3oQ7+PB3TL8m1pcD8LQtG JwcGiksqSbFwhtZlqnGqPDQaTCecxz1wHGdh3Mm5iHay1Ev77BmPp3bSJO61frdO VKK3wF0dicACrkx1cvOv =rMUl -----END PGP SIGNATURE----- --=-X3DqbybXKjlCZ4STg0tc-- From adam@deepthink.com.au Fri Feb 27 15:53:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95F763A676A for ; Fri, 27 Feb 2009 15:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2QrnWITBXzN for ; Fri, 27 Feb 2009 15:53:09 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 73D943A6B4F for ; Fri, 27 Feb 2009 15:53:02 -0800 (PST) Received: from ntxedgeus01.exchange.xchg (ntxedgeus01.lxa.perfora.net [172.23.130.34]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1LdCWC3ICZ-0000vZ; Fri, 27 Feb 2009 18:53:25 -0500 Received: from ntxhubus03.exchange.xchg (172.23.130.36) by ntxedgeus01.exchange.xchg (172.23.130.34) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 27 Feb 2009 18:45:19 -0500 Received: from winxbeus19.exchange.xchg ([172.23.130.79]) by ntxhubus03.exchange.xchg ([172.23.130.36]) with mapi; Fri, 27 Feb 2009 18:53:14 -0500 From: "Frisby, Adam" To: Jon Watte Date: Fri, 27 Feb 2009 18:52:53 -0500 Thread-Topic: [mmox] Chartering for requirements only Thread-Index: AcmZJAY6Nx82kq21RNSUH9jvWh/E+wAETkcg Message-ID: <63FAD4F222230A4EA79DE9E8BE6647350578302F@winxbeus19.exchange.xchg> References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <49A80BE4.7000206@cox.net> <49A85DC9.2020501@gmail.com> In-Reply-To: <49A85DC9.2020501@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Provags-ID: V01U2FsdGVkX1+4S4cBlGYAXY+nyeX2PfNtXYU5yCObbDTvTGs /AC17b8OBlTK3dpflFiL1TKaNTm/798W7uuBan8KSHGJ7djdE Cc: "mmox@ietf.org" Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 23:53:10 -0000 Honestly, I think going back to the original use cases, and seeing what we need works= best. I also think that in the case of revising this - we need to revisit some of= the central complaints. While OGP has been added to OpenSim (because it wa= s relatively easy to do so and hence the barrier to entry was low), there's= a number of serious technical flaws with the standard, and it only handles= a tiny number of possible use cases properly at the moment. I have a strong personal preference to attempting to reinvent as few standa= rds as possible - leveraging outside sources where possible. IE - using say= Kerberos for authentication, standard URI's (with a preference for HTTP) f= or use of asset delivery, etc. The reasoning being that most of these are in production already and are we= ll tested - right now almost all the virtual world standards have serious i= ssues on a number of levels, from caching and multicasting, to complete dis= regard for security practices. For that reason, I think we should go back to the original use cases, then = think about them in the contexts of security, portability, ease of implemen= tation, as well as the original design goals. Regards. Adam > -----Original Message----- > From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of > Jon Watte > Sent: Friday, 27 February 2009 1:40 PM > To: Morgaine > Cc: lenglish5@cox.net; mmox@ietf.org > Subject: Re: [mmox] Chartering for requirements only > > Morgaine wrote: > > > > 1. Work in two streams, one explicitly OGP which is very targetted > > at a specific solution, and the other explicitly MMOX which is > > much wider, with people contributing to one or both. If MMOX > > identifies other possible solutions then additional workgroups > > could be created to handle them. > > 2. Remove the constraints (expressed as an intention > > archive/web/mmox/current/msg00627.html>) > > imposed by LL on the solution space, so that MMOX can find > > common ground among VW architectures and then seek solutions > > without being placed in a straightjacket by Linden-only issues. > > Notice that this may even lead to OGP being identified as a > good > > solution. > > 3. Unpack the OGP proposal in all its glory into all the > > {problem,solution} pairs that led up to it, and describe the > > details in a marathon session of explanation/indoctrination so > > that there can be broad buy-in to that technology from a large > > proportion of MMOX participants. If they agree that LLSD/OGP > > can solve the interop problem for their own worlds equitably, > > then we might be onto a winner. > > > > While this seems like possible ways to structure the groups, I still > don't know what the groups are supposed to do. > What problem are we solving? Which requirements do we need to fill? > What > use cases led to those requirements? > > > > > Something needs to be done, or the lack of even a rough consensus > > might impact badly on our ability to form a workgroup after the BoF, > > let alone actually get good work done. I don't mind which path we > > take, as long as it provides a means of cooperation in place of > > outright conflict. (A bit of conflict is of course both inevitable > > and useful.) > > From my point of view, OGP seems to attempt to solve a problem that is > not applicable to vendor-neutral interoperability. It tries to solve > the > problem of "entity X wants to instantiate an authoritative copy of > object Y into server Z." I believe that instantiating authoritative > objects (as opposed to showing ghost copies of them) is necessarily > technology specific, and thus necessarily outside the scope of a > vendor- > and technology neutral interoperability protocol. > > However, I don't know if that comment is even applicable, because we > don't have any requirements yet. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From dcolivares@gmail.com Fri Feb 27 16:03:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 006E03A687B for ; Fri, 27 Feb 2009 16:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CT1aYIRQCdup for ; Fri, 27 Feb 2009 16:03:48 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 1C39D3A676A for ; Fri, 27 Feb 2009 16:03:47 -0800 (PST) Received: by bwz26 with SMTP id 26so1255686bwz.37 for ; Fri, 27 Feb 2009 16:04:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vSc+HRGOgzBgl6mxwYbfwHb5hUXQ5BgGnnBUVmPuPak=; b=H7w80P+2bT6IjUDM2sqvEhymsPVRPf366a7MIe2Y0Pe5itWHKtHdeMCrJnCNW71B3l 8DdpD2H5+asCd9yL5G09hcTOCTAOC52I3YvDCL1g+IQQ9k52FxeUoVhACUNPDzB0wlh9 IM25uYrg2c2oLGltfVeM9S86L2aCjOCTNf3iw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=IHaQeLPtycAL+BH5bbFHHlfyegYT/w23sEo+45MJbJiLrhqctiL3Y7r3m2/liA0nXW AXFKzBnZbyXTVRyfhi1lSD3pPvbbhEf78Uf9Riuya3mPrTSnmmNA5wRfEV/hCpdhD01H UAOiwMmbJ6ImLWFJSanH2x5CJ/ql3ZcrFwJb4= MIME-Version: 1.0 Received: by 10.103.175.9 with SMTP id c9mr1601017mup.3.1235779449760; Fri, 27 Feb 2009 16:04:09 -0800 (PST) In-Reply-To: <20090227.171324.14645.0@webmail10.vgs.untd.com> References: <20090227.171324.14645.0@webmail10.vgs.untd.com> Date: Fri, 27 Feb 2009 19:04:09 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org, Chris.Down@alcor.co.uk Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 00:03:50 -0000 One little nit picky thing here is about an argument that I don't really understand what you're trying to say based on the wording: "Whatever the usefulness of Apache or Gimb or whatever, so what? It's not the answer for everything; it isn't user friendly; it doesn't *work*." If you mean, "It's not the answer for everything", agreed, there's also IIS(closed source), Sun's Java System Web Server(partially open source), IBM WebSphere(open source), Abyss Web Server(closed source), NCSA(open source), C# Webserver(open source), and others. If you mean, "It's not user friendly, therefore it doesn't work", then I disagree. Really, this depends on the intended audience. If the intended audience is 'linux server administrators', their idea of a good user interface is vastly different from an end user. (this is one thing that we'll have to consider in the MMOX charter... Intended Audience) If you mean, it didn't work for you, therefore it doesn't work, then this is an opinion statement. You really don't mean 'it doesn't function'. If we go by simply web server usage statistics, Apache has ~48% of the market share based on the monthly netcraft web server survey. (Ref: http://news.netcraft.com/archives/web_server_survey.html ) If it didn't meet the expectations of the target audience then it wouldn't have market share. Historically, I do agree with the assertion that Open Source software has tended to be less user friendly. Though, recently, some open source programs have learned that if the target audience is end users, they'll need to taylor their user interface to the expectations of that audience. (Ref: Ubuntu/Open Office/FireFox/Google Chrome) Can you clarify your statement? Thanks Daniel Olivares On Fri, Feb 27, 2009 at 5:13 PM, dyerbrookme@juno.com wrote: >>I do not intend to carry on this thread as > (a) It does not really belong on this list > (b) You are obviously not interested in anyone's point of view but your > own. > >>I have given you some friendly advice and you choose to criticise and > ignore it. You twist peoples replies and are deliberately obtuse > > Chris, > > I made a short comment to Zha's (David Levine's) demand to untether the t= erms avatar, identity, etc. and move to generalities -- which I felt accomp= lished the job of stripping out commerce and IP that the AWGroupies keep do= ing. That's all. I've been having this same debate with them for a year or = more. I felt it was necessary merely to put down a marker: "Here is where t= hey go off the map and depart from contextual definitions in the name of 'e= xpediency' to get their way again". That's all. In fact, if I were the non-= Lindens on this list, from their set of interests, I'd also put a flag down= on that and say to myself, "Here's where they insist on setting the genera= lities themselves so as to claim them for their own set of specifics later.= " > > You chose to give me a huge lecture and diatribe defending your opensourc= e way of life. That's fine, but it simply fails to persuade me. > > Basically, this debate plays out over and over again, and not only with m= e, as surely you are aware, in a very typical and irrational pattern -- irr= ational, because it is premised on an intolerant view that sees and claims = falsely intolerance in others precisely because it cannot conceive of co-ex= istence and pluralism: > > 1. Opensource proponent insists that everything be opensource and that pr= eferences always go to opensource in every endeavour, whether social media = (laconic), websites (Drupal), educational sites (Moodle), virtual worlds (O= penSim), etc. Browbeaten, those involved go along, though they find the sof= tware difficult, wonky, non-user-friendly, like Linux. > > 2. If they criticize a single thing about any of this, or say a single th= ing in defense of proprietary code or "walled gardens," they are lectured a= nd reminded that "the entire Internet" was founded on the opensource concep= t and "they owe their very blog or world to opensource" and "should be grat= eful" -- although *criticism* or *demand for plurality* isn't the same thin= g at all as rejecting the role of opensource in the building of the Interne= t, or rejecting someone's choice for opensource. These are all acknowledge = and all understood, but they are *criticized* as not being viable, and ther= efore *choice* is needed. > > 3. Having encountered a rebuff to their zealotry, the opensource proponen= t then pushes further, more shrilly, and more hysterically. Now, the person= who merely began with a criticism of non-usefulness, or a demand for *choi= ce* is told that they are "obtuse" or "stupid" or "Anne Coulter" or a "righ= t-whinger" or "refuse to concede others' points of views" -- by which is ac= tually meant, "You refuse to come round to our cultic point of view" by thi= s time. > > 4. If the thoroughly browbeaten and bullied critic of opensource continue= s to hold fast, now they are told "You are preventing other people from hav= ing a point of view" (obviously a false proposition) or "you are deliberate= ly dense" or some other state is impugned to them which amounts to this: "y= ou refuse to come round and join the hive mind collective on this". > > Well, no, I don't. I refuse. And that's normal. Nothing I've seen about o= pensource in the four years I've had to see it very up close and personal h= as done a thing to persuade me that it is a viable system that leaves choic= e of systems. None of its propositions and claims are true for virtual worl= ds that I can see ("bugs are visible and fixable to a thousand eyes") etc. = Whatever the usefulness of Apache or Gimb or whatever, so what? It's not th= e answer for everything; it isn't user friendly; it doesn't *work*. I can't= be forced to believe in software religion in defiance of the evidence of m= y own experience. > > I'm sorry, but I don't give into emotional blackmail ("I gave you friendl= y advice and you refused to heed it" =3D "You refused to come round to our = point of =A0view") or concede your point of view. It's because I disagree w= ith its viability. I have proof of its viability, anywhere, anyhow. You can= keep citing "The Internet" or "this guy I know who makes money from Creati= ve Commons" or whatever you like but none of it is *persuasive* as a *syste= m for everybody, that is free, and enables choices*. That isn't the same th= ing as *acknowledging your right to have this point of view* or accepting t= hat *for you, this religion is helpful*. > > That's all, it's about choice. I realize that for whatever reason even th= ose decidedly four-square for closed worlds and proprietary code and robust= IP protect, for reasons that continue to remain obscure to me, embrace the= opensource shtick (free labour? free R&D budget?). In any event, I have no= requirement to argue about this or debate it further on this particular li= st, which is obviously largely engaged in technical standard-making. Howeve= r, if you attack me and lecture me and hector me with the extremist opensou= rce point of view, I will simply defend my perspective on this which I beli= eve is a mainstream consumer perspective on virtual worlds. > > > ____________________________________________________________ > Click here to save cash and find low rates on auto loans. > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTLaWySIWwBcxnL7KFaUZFuw= EZEOqrpk9Xm94tzdK2DHyWmqezkin2/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From charles.krinke@gmail.com Fri Feb 27 16:29:42 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577163A676A for ; Fri, 27 Feb 2009 16:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JmjjlGtRYI8 for ; Fri, 27 Feb 2009 16:29:41 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by core3.amsl.com (Postfix) with ESMTP id ED2803A6B28 for ; Fri, 27 Feb 2009 16:29:40 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so685839wag.5 for ; Fri, 27 Feb 2009 16:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=4Tu7FwOAm5p3HMPZwozNJ3o6ZJQnADAh1/GOMoCRYt0=; b=l0CZmPO4lg2Al/mg5IN1xP+tCKRxCHFh2/JubEaZiVnwfHbNAUUjtLOmK++QEtLiz5 TXpNt5QAnezeaSqmyJ9Nuxdv4Dkj5eRGV9LBUEGSzXYXYwM3wC7ZSEJFA1QGQHUiijaO 1lDW494SGTBlKUPSrbhTA3VkuaQ8OaA9XJWv8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=m9zcRVj/z5sLmVMjcHY1KZyUEHJUO3TEqtwwmQf0Mwk0QkcUpvqEdcQEAx5fWa0zl6 8jNfj0cs7j5893Eeueri3n35UJY4Mb92YdSCYTucWm0M2cn6Cr8Y6Y58gpo2V/6H9K93 mAbqLBM8960fglMiukHWywFhHHdDQSvgacUWc= MIME-Version: 1.0 Received: by 10.114.174.2 with SMTP id w2mr1398404wae.195.1235781004030; Fri, 27 Feb 2009 16:30:04 -0800 (PST) In-Reply-To: <63FAD4F222230A4EA79DE9E8BE6647350578302F@winxbeus19.exchange.xchg> References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <49A80BE4.7000206@cox.net> <49A85DC9.2020501@gmail.com> <63FAD4F222230A4EA79DE9E8BE6647350578302F@winxbeus19.exchange.xchg> Date: Fri, 27 Feb 2009 16:30:03 -0800 Message-ID: From: Charles Krinke To: "mmox@ietf.org" Content-Type: multipart/alternative; boundary=0016364571b0c3f4e20463efaf67 Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 00:30:28 -0000 --0016364571b0c3f4e20463efaf67 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit One of the use cases for which most of us are familiar with is indeed the SL use case. And it has other interop ramifications. As we have others make compatible sim servers to the SL client, such as OpenSim, we also have additional clients, such as Hippo, Xenkii, Rex, OpenViewer, IdealistViewer to name a few. One of the things I am concerned about is minimizing the changes to those server and client interfaces to encourage the greatest interoperability between the similar and "vendor neutral" sim servers and clients as we move forward in trying to define some semblance of "interop" Charles Krinke OpenSim Core Developer OSGrid Director On Fri, Feb 27, 2009 at 3:52 PM, Frisby, Adam wrote: > Honestly, > > I think going back to the original use cases, and seeing what we need works > best. > > I also think that in the case of revising this - we need to revisit some of > the central complaints. While OGP has been added to OpenSim (because it was > relatively easy to do so and hence the barrier to entry was low), there's a > number of serious technical flaws with the standard, and it only handles a > tiny number of possible use cases properly at the moment. > > I have a strong personal preference to attempting to reinvent as few > standards as possible - leveraging outside sources where possible. IE - > using say Kerberos for authentication, standard URI's (with a preference for > HTTP) for use of asset delivery, etc. > > The reasoning being that most of these are in production already and are > well tested - right now almost all the virtual world standards have serious > issues on a number of levels, from caching and multicasting, to complete > disregard for security practices. > > For that reason, I think we should go back to the original use cases, then > think about them in the contexts of security, portability, ease of > implementation, as well as the original design goals. > > Regards. > > Adam > > > -----Original Message----- > > From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of > > Jon Watte > > Sent: Friday, 27 February 2009 1:40 PM > > To: Morgaine > > Cc: lenglish5@cox.net; mmox@ietf.org > > Subject: Re: [mmox] Chartering for requirements only > > > > Morgaine wrote: > > > > > > 1. Work in two streams, one explicitly OGP which is very targetted > > > at a specific solution, and the other explicitly MMOX which is > > > much wider, with people contributing to one or both. If MMOX > > > identifies other possible solutions then additional workgroups > > > could be created to handle them. > > > 2. Remove the constraints (expressed as an intention > > > > archive/web/mmox/current/msg00627.html>) > > > imposed by LL on the solution space, so that MMOX can find > > > common ground among VW architectures and then seek solutions > > > without being placed in a straightjacket by Linden-only issues. > > > Notice that this may even lead to OGP being identified as a > > good > > > solution. > > > 3. Unpack the OGP proposal in all its glory into all the > > > {problem,solution} pairs that led up to it, and describe the > > > details in a marathon session of explanation/indoctrination so > > > that there can be broad buy-in to that technology from a large > > > proportion of MMOX participants. If they agree that LLSD/OGP > > > can solve the interop problem for their own worlds equitably, > > > then we might be onto a winner. > > > > > > > While this seems like possible ways to structure the groups, I still > > don't know what the groups are supposed to do. > > What problem are we solving? Which requirements do we need to fill? > > What > > use cases led to those requirements? > > > > > > > > Something needs to be done, or the lack of even a rough consensus > > > might impact badly on our ability to form a workgroup after the BoF, > > > let alone actually get good work done. I don't mind which path we > > > take, as long as it provides a means of cooperation in place of > > > outright conflict. (A bit of conflict is of course both inevitable > > > and useful.) > > > > From my point of view, OGP seems to attempt to solve a problem that is > > not applicable to vendor-neutral interoperability. It tries to solve > > the > > problem of "entity X wants to instantiate an authoritative copy of > > object Y into server Z." I believe that instantiating authoritative > > objects (as opposed to showing ghost copies of them) is necessarily > > technology specific, and thus necessarily outside the scope of a > > vendor- > > and technology neutral interoperability protocol. > > > > However, I don't know if that comment is even applicable, because we > > don't have any requirements yet. > > > > Sincerely, > > > > jw > > > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > -- --0016364571b0c3f4e20463efaf67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One of the use cases for which most of us are familiar with is indeed the S= L use case. And it has other interop ramifications.

As we have other= s make compatible sim servers to the SL client, such as OpenSim, we also ha= ve additional clients, such as Hippo, Xenkii, Rex, OpenViewer, IdealistView= er to name a few.

One of the things I am concerned about is minimizing the changes to tho= se server and client interfaces to encourage the greatest interoperability = between the similar and "vendor neutral" sim servers and clients = as we move forward in trying to define some semblance of "interop"= ;

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Fri, Feb 27, 2009 at 3:52 PM, Frisby, Adam <adam@deepthink.com= .au> wrote:
Honestly,

I think going back to the original use cases, and seeing what we need works= best.

I also think that in the case of revising this - we need to revisit some of= the central complaints. While OGP has been added to OpenSim (because it wa= s relatively easy to do so and hence the barrier to entry was low), there&#= 39;s a number of serious technical flaws with the standard, and it only han= dles a tiny number of possible use cases properly at the moment.

I have a strong personal preference to attempting to reinvent as few standa= rds as possible - leveraging outside sources where possible. IE - using say= Kerberos for authentication, standard URI's (with a preference for HTT= P) for use of asset delivery, etc.

The reasoning being that most of these are in production already and are we= ll tested - right now almost all the virtual world standards have serious i= ssues on a number of levels, from caching and multicasting, to complete dis= regard for security practices.

For that reason, I think we should go back to the original use cases, then = think about them in the contexts of security, portability, ease of implemen= tation, as well as the original design goals.

Regards.

Adam

> -----Original Message-----
> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of
> Jon Watte
> Sent: Friday, 27 February 2009 1:40 PM
> To: Morgaine
> Cc: lenglish5@cox.net; mmox@ietf.org
> Subject: Re: [mmox] Chartering for requirements only
>
> Morgaine wrote:
> >
> > =A0 =A01. Work in two streams, one explicitly OGP which is very t= argetted
> > =A0 =A0 =A0 at a specific solution, and the other explicitly MMOX= which is
> > =A0 =A0 =A0 much wider, with people contributing to one or both. = =A0If MMOX
> > =A0 =A0 =A0 identifies other possible solutions then additional w= orkgroups
> > =A0 =A0 =A0 could be created to handle them.
> > =A0 =A02. Remove the constraints (expressed as an intention
> > =A0 =A0 =A0 <http://www.ietf.org/mail-
> archive/web/mmox/current/msg00627.html>)
> > =A0 =A0 =A0 imposed by LL on the solution space, so that MMOX can= find
> > =A0 =A0 =A0 common ground among VW architectures and then seek so= lutions
> > =A0 =A0 =A0 without being placed in a straightjacket by Linden-on= ly issues.
> > =A0 =A0 =A0 Notice that this may even lead to OGP being identifie= d as a
> good
> > =A0 =A0 =A0 solution.
> > =A0 =A03. Unpack the OGP proposal in all its glory into all the > > =A0 =A0 =A0 {problem,solution} pairs that led up to it, and descr= ibe the
> > =A0 =A0 =A0 details in a marathon session of explanation/indoctri= nation so
> > =A0 =A0 =A0 that there can be broad buy-in to that technology fro= m a large
> > =A0 =A0 =A0 proportion of MMOX participants. =A0If they agree tha= t LLSD/OGP
> > =A0 =A0 =A0 can solve the interop problem for their own worlds eq= uitably,
> > =A0 =A0 =A0 then we might be onto a winner.
> >
>
> While this seems like possible ways to structure the groups, I still > don't know what the groups are supposed to do.
> What problem are we solving? Which requirements do we need to fill? > What
> use cases led to those requirements?
>
> >
> > Something needs to be done, or the lack of even a rough consensus=
> > might impact badly on our ability to form a workgroup after the B= oF,
> > let alone actually get good work done. =A0I don't mind which = path we
> > take, as long as it provides a means of cooperation in place of > > outright conflict. =A0(A bit of conflict is of course both inevit= able
> > and useful.)
>
> =A0From my point of view, OGP seems to attempt to solve a problem that= is
> not applicable to vendor-neutral interoperability. It tries to solve > the
> problem of "entity X wants to instantiate an authoritative copy o= f
> object Y into server Z." I believe that instantiating authoritati= ve
> objects (as opposed to showing ghost copies of them) is necessarily > technology specific, and thus necessarily outside the scope of a
> vendor-
> and technology neutral interoperability protocol.
>
> However, I don't know if that comment is even applicable, because = we
> don't have any requirements yet.
>
> Sincerely,
>
> jw
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox



--

--0016364571b0c3f4e20463efaf67-- From dyerbrookme@juno.com Fri Feb 27 17:17:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBD5A28C1E0 for ; Fri, 27 Feb 2009 17:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.081 X-Spam-Level: X-Spam-Status: No, score=-0.081 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, FRT_PROFILE2=1.981, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mGkJ6Yybld8 for ; Fri, 27 Feb 2009 17:17:37 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id D8A6F28C1D1 for ; Fri, 27 Feb 2009 17:17:37 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail03.vgs.untd.com [10.181.12.143]) by smtpout06.vgs.untd.com with SMTP id AABE4TEEVAM2M4MA for (sender ); Fri, 27 Feb 2009 17:17:07 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNvZqtnnIaemeimEPZj/Ryyg== Received: (from dyerbrookme@juno.com) by webmail03.vgs.untd.com (jqueuemail) id PAFWCJA9; Fri, 27 Feb 2009 17:16:56 PST Received: from [10.181.11.32] by webmail03.vgs.untd.com with HTTP: Sat, 28 Feb 2009 01:16:52 GMT X-Originating-IP: [10.181.11.32] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 28 Feb 2009 01:16:52 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090227.201652.10068.0@webmail03.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 11:5:1584713533 X-MAIL-INFO: 424915e9757515696969490c810c94c4e4c5c0050540fda08075d4a541c99059695990bd29e069d1d90459716991bd250d X-UNTD-Peer-Info: 10.181.12.143|webmail03.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 177 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 01:17:39 -0000 Message: 1 Date: Sat, 28 Feb 2009 07:21:42 +0900 From: Kajikawa Jeremy Subject: Re: [mmox] MMOX ...mixed threading... >I am utterly surprised by how disconnected some of your statements appe= ar to be with regards conversations on this list. My contributions are pertinent to the larger issues at hand, and your em= otions seem inconsistent with a scientific project. Whatever. >TCP/IPv4 supports commerce... does it have any commercial functions inside the protocol?... from my understanding NONE... Whenever I see all caps, I see religion, not science. It's your notion t= hat TCP/IPv4 "supports commerce" on the first iteration of the Internet.= Great! How does it do that? By transmitting for the most part electroni= c data about payments for real items in the real world which are shipped= by real roads in trucks to people who buy them, say, a vacuum cleaner o= r "The Cult of the Amateur" by Andrew Keen on amazon.com. To be sure, it= also transmits digital information like mp3s which are constantly pirat= ed and prompts copyleftists to say, oh, we should be forced to share eve= rything because everything is rippable and we can't have micropayments t= hey don't work blah blah. Except...the vacuum cleaners and "The Cult of = the Amateur" keeps coming on the trucks...So TCP/IPV4 supports commerce = even without little gremlins inside it ensuring anything but the securit= y of bank transactions...oops, that might be what you WOULD call "suppor= ts commerce" if it enabled it. BUT in virtual worlds, the vacuum cleaners and the books are made of pix= els, so they become rippable like the music. That's why we want c/m/t on= them. That's all. Very simple. We've been over this. The second iterati= on of the Internet doesn't *have* to be like the first unless your mind = is closed. >TCP is limited scope to a reliable transport, UDP is best-effort unreliable, IP and ICMP is framing for the above to work on a commonalit= y... I have no idea. Do you enjoy showing off jargon and also telling everyon= g you're an amateur? I'm fairly conversant in technology issues, and fai= rly well-read, but I have no idea if this statement is true, or what all= the elements mean. And I'm not required to, and don't have to be called "disconnected" or "= obtuse" if I don't have an IT degree. I could say, oh, Russians will be = the third largest users of the Internet in a year or two, why don't you = translate this entire group's messages into Russian, and then I could of= fer this magic "positive proposal" without which you cannot conceive of = any framing of any discussion by saying "Here's my translation, or here'= s my plan to get help with terminology, etc". People have different area= s of expertise; life may be increasingly digitalized, but coders do not = define all of human expertise. >I see this list as endeavouring to provide a TCP or UDP hosted mechanis= m that is application specific forms of these protocols for allowing obj= ects to have both OSS and Commercial backing... One would hope...but that isn't affirmed whatsoever. It's your notion an= d you aren't worry if it doesn't hold fully true, evidently, or you woul= dn't feel the need to bang on me. Forterra's CTO has indicated this, but= neither Linden or IBM or AWGroupies or others on the list have said the= y concede the idea of having the metadata support permissions. In fact, = I see a hesitancy from them. >is an object transferred containing "commercial" content? yes/no Whichever... as long as it is transferable or otherwise able to have a= money transaction connected for those interested in money. It's not like they have leprosy; most people *are* interested in money a= nd getting paid and paying; they require this to survive. And again, you= 're conceiving of currency as an add-on module that somebody tacks on, w= hereas there is every reason to conceive of it as wired in from the star= t, to make it an option to turn off, but not have to require exceptional= extra coding, modules, separate agreements, etc. to turn on. This list is remaining a *technical* discussion and we are trying to remain "option open" with future proofing the protocol in-use... Technology rapidly doesn't "remain" technical the minute that some of th= e coders weld their worldview into the code from the start, forcing the = tools on all of us, without choice. So I reject that notion. = >My own proposal to this list was to have any object encoding allow arbitrary extensible attributes attached to an ObjectID... each VW may = allow the OID to be remapped as long as the attributes in full remain to= gether. a) I don't hear others support this b) I'd have to see how this played o= ut to understand if it does the trick. >with regards your anti-FOSS commentary... I don't care what you believe= in as long as your input is /*constructive*/ or proposing a mechanism t= hat does not detract or otherwise limit the functionality your welcome t= o participate This is typical of the kind of controlling, belittling comment that one = gets when questioning opensource projects in any way -- which this is es= sentially in culture and spirit, whatever the cursory nods to proprietar= y platforms. Once again, my comment isn't "anti-FOSS" as I said that I r= eject *the imposition" of OS on people and want *choice* and I *criticiz= e* OS because of its inherent contradictions, and some of its fraudulent= claims as I've observed them. = I've already noted that this work culture of "you can only make a constr= uctive proposal" is for the birds. It's not a normal function of a norma= l democratic discourse in real life or online communities. It's an artif= act of a geek culture that creates a Spartan-like regime of brutally rej= ecting any criticism or negativity or dissent by insisting on salmon swi= mming upstream to create a hypothetical "positive proposal" to support t= heir critique -- which is merely a cover to aggressively privilege the d= ominant narrative and agenda. Non-technical people can't be expected to = mount proposals of this nature. The technicians on the list, in IRC type= fashion, are anything but constructive in their scathing and brutal com= ments *to each other*. So you're welcome to keep nattering on about "con= structive" proposals, but I'm simply going to reserve the right to make = comments as I see fit on this *public list*. If it's *not* a public list, and nary a discouraging word can be heard a= gainst opensouce or the dominant culture of those on the list, and it tr= uly is *not* open to the public, and only very narrowly technically-prof= icient types need apply, of course you can say so. But that's not the la= bel on the can. ____________________________________________________________ Click to get free auto insurance quotes from top companies. http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTImHbZrUYUD7NJVyQ6fo6T= isSZGoff1pF5pgsJEFMlcRD7FL3dBhW/ From dyerbrookme@juno.com Fri Feb 27 17:29:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4502028C13C for ; Fri, 27 Feb 2009 17:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7QAh2gBBmCr for ; Fri, 27 Feb 2009 17:29:09 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 6114E3A68DD for ; Fri, 27 Feb 2009 17:29:09 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail03.vgs.untd.com [10.181.12.143]) by smtpout06.vgs.untd.com with SMTP id AABE4TE5VAWK96X2 for (sender ); Fri, 27 Feb 2009 17:29:23 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNbaj2RiGykCTrrl0CfXe5Ng== Received: (from dyerbrookme@juno.com) by webmail03.vgs.untd.com (jqueuemail) id PAFWZM7K; Fri, 27 Feb 2009 17:28:28 PST Received: from [68.161.198.3] by webmail03.vgs.untd.com with HTTP: Sat, 28 Feb 2009 01:27:20 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 28 Feb 2009 01:27:20 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090227.202720.10068.1@webmail03.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 6:3:2507794421 X-UNTD-Peer-Info: 10.181.12.143|webmail03.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 171 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 01:29:10 -0000 I think that's putting the cart before the horse. The use cases define = what we actually need to work towards. If there is no use case for a = feature, that means there's no reason to implement it, because nobody = will use it. Meanwhile, if you don't have use cases, then you can't = tease out what things you actually ought to be building. Note that use cases are all about *what* you build, though -- not *how* = = you build it, which I feel is what you're trying to get at. De-coupling and separability (as you describe) are all very useful = traits in a technical design, but are all about the "how," not the = "what." Sincerely, Jon, I agree that you need to cite a robust list of use cases before you star= t building interoperability; it's this abstraction, and decoupling of in= teroperability from authentic uses that rapidly leads to destruction of = existing authentic uses. However, I didn't understand your list of use cases as "uses". They seem= ed to me like "function cases". I realize there may be some very narrow = technical understanding of what a "use case" is. But when you listed the= m, I couldn't see their actual *purpose* with an agent, an action, and a= n outcome -- a use. For example, you talked about the *functionality* of being able to come = into a world and track an avatar's movements. But what is this *use*? Wh= at is is *for*? Is it for enabling a state's military or intelligence se= rvices to gain access to multiple virtual worlds easily and track people= 's behaviour, with an aim to preventing terrorism, let's say? Or it is f= or someone to decide where the hot spots are on their grid to lay out th= e traffic better and make sure avatars don't face obstacles in their tra= vels or whatever. In other words, the enabling an entity to track avatar= s across multiple worlds is a function, not a use because the purpose is= n't explicit. By the same token, the man who ports the scene into another man's world = to show him. He could be a pirate sucking the content out of a world wit= h original content and showing it to others to sell, or he could be maki= ng the blueprint of a hospital emergency room and showing it to doctors = on another platform in another country for their input. That is, functio= nality has different uses -- you could call usage stripped of content an= d meaning a "use case" but it's worth being explicit, because if the bas= ic reason we're all getting together here to interoperate and merge worl= d capacities is for governments to make it easier to engage in surveilla= nce where people increasingly spend their time, why are we making that e= asier as a technical proposition without some due process and democratic= deliberation about why that might need some check gates on it? Or the s= ame with the pirating. Why make a system that endlessly ports back and f= orth "scenes" (which are artwork and content, after all) and sucks all t= he content out of worlds where people produce original work, and merely = hand it over to others to sell in other worlds -- again, with no technic= al check gate. Prokofy Neva ____________________________________________________________ Solve paternity questions with expert DNA testing. Click now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTKPABlBom8isv5wEaJAKVG= uY1dMnsVKDHHj7Zt3gQlldPvRJMXhss/ From dyerbrookme@juno.com Fri Feb 27 19:05:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862003A6982 for ; Fri, 27 Feb 2009 19:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=-0.629, BAYES_05=-1.11, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1kdRUbziSmE for ; Fri, 27 Feb 2009 19:05:30 -0800 (PST) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id AEFD03A6934 for ; Fri, 27 Feb 2009 19:05:30 -0800 (PST) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail06.vgs.untd.com [10.181.12.146]) by smtpout01.vgs.untd.com with SMTP id AABE4TLQNANTK3SA for (sender ); Fri, 27 Feb 2009 19:04:44 -0800 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNOa7OMaGhRcIzKuzFeOV7bw== Received: (from dyerbrookme@juno.com) by webmail06.vgs.untd.com (jqueuemail) id PAF4GJF4; Fri, 27 Feb 2009 19:03:58 PST Received: from [68.161.198.3] by webmail06.vgs.untd.com with HTTP: Sat, 28 Feb 2009 03:03:50 GMT X-Originating-IP: [68.161.198.3] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Sat, 28 Feb 2009 03:03:50 GMT To: mmox@ietf.org Cc: mmox@ietf.org X-Mailer: Webmail Version 4.0 Message-Id: <20090227.220350.19825.0@webmail06.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 2:2:756433355 X-MAIL-INFO: 0e4155c0151581250ced04f50c35fd00f50d45edf4118954 X-UNTD-Peer-Info: 10.181.12.146|webmail06.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Subject: Re: [mmox] mmox Digest, Vol 1, Issue 178 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 03:05:31 -0000 From: Dan Olivares Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163 I stand by my statement about opensouce being non-user-friendly, and ult= imately about closed societies of coders who aren't accountable to the g= eneral public and sometimes operate outside of restraints of liberal dem= ocracy in ways that are often destructive (promoting hacker culture and = crime). I don't at all feel compelled to have to provide some lengthy exegesis o= n why this is true about every single one of the types of software you i= ndicate although I could write pages. A really good example is Firefox, = which harasses you constantly asking you if you want to save your passwo= rd forever or for this session or never, based on the misguided concept = that people just love the idea of all those options constantly shoved at= them with only an opt-out, that they just are dying to have the option = to always save their log-ons -- although of course, that creates securit= y problems especially on multi-user computers which are *most* computers= . It's the sort of hilarious "solution" that came about because of peopl= e complaining in both directions and opensourcery then providing all the= se choices and add-ons. To get rid of it, all you have to do (which you can't "just know" until = you finally find it) is go to tools/options/security/uncheck remember pa= ssword (but it keeps falling out and needs redoing after each update). I= f you google this issue, you will see many frustrated people, and many g= eeks offering hilarious and contorted ways to get rid of it. But...if yo= u have checked off a box saying "remember passwords" why can't it just d= o that, and not keep offering you choices each time? It's an example of = the wonky non-usefulness of geekitude that the average person simply fin= ds stupid and annoying but can't escape.Firefox constantly hangs and sta= lls, it constantly crashes and has to remember itself. Yet we're all fro= g-marched into using it or told we're not cool and starving little babie= s or something if we use IE. ____________________________________________________________ Put your loved ones in good hands with quality senior assisted living. C= lick now! http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTJkoM1onFG7s0PvKMwppvx= ViHUBQ9bpM2Tunrdy0gf6BiD5x1Cr7q/ From dcolivares@gmail.com Fri Feb 27 20:35:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8B73A67B2 for ; Fri, 27 Feb 2009 20:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aciQfPKdTGMF for ; Fri, 27 Feb 2009 20:35:48 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 45B303A69FF for ; Fri, 27 Feb 2009 20:35:48 -0800 (PST) Received: by fxm24 with SMTP id 24so1329453fxm.37 for ; Fri, 27 Feb 2009 20:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=4fK0n2NXkt5D0F0kXp7+vkE2iwQgN0Xk1ABd9cDHBe0=; b=tf/CYyhu0F+7gKZKk+te86VAcBAcM24TjMbnbg8vS+UVNqh83D7iVgF+xxPBBbAAEm 4yCyv+vl5/2afQWKjVYV3t43qCZbMnbjT/K39XMZdhdzyVCghe+uMxbFEhqjkVAV0QiR reB+1+0gjkrwkbgiUWtfBpkA87vdg2q8i/T0w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=thr9mS6s65rxk40uY8RoAAyHvWZcVErMd1GPTXgNui/zHePvGh+HnFydTDe33aPgmS tkoWGgpYtTorf0HvhqGF3mIMu7Df/irw4r9DD8zU11aFhzIGBQfrKTrGYjJ/sVxLEtgE gq7xBfg5d0mkLvAHu1t6r6lJv8H2MP8iJpa2o= MIME-Version: 1.0 Received: by 10.103.251.3 with SMTP id d3mr1689237mus.72.1235795769025; Fri, 27 Feb 2009 20:36:09 -0800 (PST) Date: Fri, 27 Feb 2009 23:36:08 -0500 Message-ID: From: Dan Olivares To: "dyerbrookme@juno.com" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mmox@ietf.org Subject: [mmox] Target audience X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 04:35:50 -0000 "I stand by my statement about opensouce being non-user-friendly, and ultimately about closed societies of coders who aren't accountable to the general public and sometimes operate outside of restraints of liberal democracy in ways that are often destructive (promoting hacker culture and crime).", And, that's your opinion. My point in the last e-mail was asking for clarification on your statement. You didn't really clarify it, instead, you chose to make another statement. So, lets break it down, point by point. "I don't at all feel compelled to have to provide some lengthy exegesis on why this is true about every single one of the types of software you indicate although I could write pages" Good, because this is really off topic. I don't feel compelled to have to provide some lengthy exegesis on how hacker culture and crime have nothing to do with open source development.. since it's an obvious red herring. According to w3schools.com, FireFox currently has 45.5% of the browser market share. It's obviously meeting the expectations of /some/ users. (Ref: http://www.w3schools.com/browsers/browsers_stats.asp ) Additionally, the bug that you reported is just one of several hundred bugs found relating to 'save password'. Some of them ask to redesign the save password dialog, some of them say, "Save password prompt is gone; no passwords could be saved in preferences ", which contradicts what you suggested is happening. On the firefox bugtracker, I didn't see the specific bug you mentioned, however, I did see lots of bugs (Ref: https://bugzilla.mozilla.org/buglist.cgi?query_format=3Dspecific&order=3Dre= levance+desc&bug_status=3D__open__&product=3DFirefox&content=3Dsave+passwor= d ) On the Internet Explorer 8 bugtracker (microsoft doesn't have a public bugtracker for non-beta versions) , I also see a lot of bugs ( Ref: https://connect.microsoft.com/IE/feedback/SearchResults.aspx?FeedbackOvervi= ewType=3D6 ) There's pages and blog posts that contain gripes about firefox: (ex: http://boonyew.com/interaction/2008/12/01/usability-gripes-with-firefoxs-do= wnload-feature/ ) There's pages and blog posts that contain gripes about Internet Explorer: ( ex: http://www.pcmag.com/article2/0,2817,2156566,00.asp ) As far as 'security' goes... Steve Gibson ( hosts the Security Now Podcast and computer security researcher ref: http://en.wikipedia.org/wiki/Steve_Gibson_(computer_programmer) ) uses FireFox with the NoScript and clickhijack addon because he feels it's more secure then Internet Explorer. (he expresses this on the Security Now podcast. Also, there are other people discussing it on: http://forum.ie7pro.com/viewtopic.php?id=3D99 ). Often, Steve is criticized for 'security over usability'. We each choose our own poison when it comes to browsers as well as software in general. Some of us prefer IE, some of us prefer FireFox, some of us prefer Safari. It really is a big deal, however, that January's browser statistics say FX(firefox)'s market share is 45.5% and if you add up the three versions of IE represented on that table, and you get 44.8%. Just because more people have chosen to use firefox in the month of January, doesn't necessarily mean that open source software is better. It just means that more people have chosen to use firefox in January. (for the record, this e-mail was written in the gmail web interface with Internet Explorer) Sincerely Daniel Olivares On Fri, Feb 27, 2009 at 10:03 PM, dyerbrookme@juno.com wrote: > From: Dan Olivares > Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163 > > I stand by my statement about opensouce being non-user-friendly, and ulti= mately about closed societies of coders who aren't accountable to the gener= al public and sometimes operate outside of restraints of liberal democracy = in ways that are often destructive (promoting hacker culture and crime). > > I don't at all feel compelled to have to provide some lengthy exegesis on= why this is true about every single one of the types of software you indic= ate although I could write pages. A really good example is Firefox, which h= arasses you constantly asking you if you want to save your password forever= or for this session or never, based on the misguided concept that people j= ust love the idea of all those options constantly shoved at them with only = an opt-out, that they just are dying to have the option to always save thei= r log-ons -- although of course, that creates security problems especially = on multi-user computers which are *most* computers. It's the sort of hilari= ous "solution" that came about because of people complaining in both direct= ions and opensourcery then providing all these choices and add-ons. > > To get rid of it, all you have to do (which you can't "just know" until y= ou finally find it) is go to tools/options/security/uncheck remember passwo= rd (but it keeps falling out and needs redoing after each update). If you g= oogle this issue, you will see many frustrated people, and many geeks offer= ing hilarious and contorted ways to get rid of it. But...if you have checke= d off a box saying "remember passwords" why can't it just do that, and not = keep offering you choices each time? It's an example of the wonky non-usefu= lness of geekitude that the average person simply finds stupid and annoying= but can't escape.Firefox constantly hangs and stalls, it constantly crashe= s and has to remember itself. Yet we're all frog-marched into using it or t= old we're not cool and starving little babies or something if we use IE. > > > ____________________________________________________________ > Put your loved ones in good hands with quality senior assisted living. Cl= ick now! > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTJkoM1onFG7s0PvKMwppvxV= iHUBQ9bpM2Tunrdy0gf6BiD5x1Cr7q/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From dcolivares@gmail.com Fri Feb 27 21:43:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 355B63A6996 for ; Fri, 27 Feb 2009 21:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaKPyVhOM+p2 for ; Fri, 27 Feb 2009 21:43:00 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id A00773A685E for ; Fri, 27 Feb 2009 21:42:40 -0800 (PST) Received: by fxm24 with SMTP id 24so1337648fxm.37 for ; Fri, 27 Feb 2009 21:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=Wki00N9Kenoo0inUw9pQGW9geFATAPGQ24mPEax2NQA=; b=lz4OhTr48bH5yXCECnIYBaE1OVvz3zKPIRuU+inTR573oSYKicq/yXX11ALe/eCcu1 5ievJS8CV7pIBV6d1ZQhJ0NUpyAcqHcL3Ux58wEhPXnWczmPzR4dbLIUY+HatXilTgxc uDUfhcfLpe1CCl+zBNYPcwkcv96Rua98lgO3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=QkPuFoNizBAdlJ1++YG8izNbeDwraHmhQOBVgTMFcUgU8d62I7Y+ayfKt+aPh022HR IQFZ6U3hz3kuqduxV1Sy4brh4CT+rwWbh2ZtipAihC9clakQ6UVIvr0XYgoExOz00tES IinWnIxAybIwjTugCifG1liR9kSlZpUzZN9hE= MIME-Version: 1.0 Received: by 10.103.90.17 with SMTP id s17mr1704615mul.93.1235799783269; Fri, 27 Feb 2009 21:43:03 -0800 (PST) Date: Sat, 28 Feb 2009 00:43:03 -0500 Message-ID: From: Dan Olivares To: mmox@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [mmox] Which Target Audience X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 05:43:02 -0000 So, As far as the draft charter and deliverables go.. it doesn't sound like we've expressed a definate target audience for them. As, I've stated in previous correspondance, target audience makes a big difference when it comes to writing documents. (for example, we would highlight use cases more for businesses and features and flexibility for application developers) By looking at the documents, it /appears/ as if it's for the application developer, however, some finite clarity would be good. Multiple audiences is fine so long as we can isolate which we are writing the standard for. Ideally, we should have the target audience in mind in everything we write and directly printed on the charter and in the text of each deliverable. A few potential target audiences: 1. Application Developer 2. Virtual World Integrator 3. Middleware Developer 4. End User 5. Companies 6. IETF??? 7. Media?? Best Regards Daniel Olivares On Fri, Feb 27, 2009 at 11:36 PM, Dan Olivares wrote= : > "I stand by my statement about opensouce being non-user-friendly, and > ultimately about closed societies of coders who aren't accountable to > the general public and sometimes operate outside of restraints of > liberal democracy in ways that are often destructive (promoting hacker > culture and crime).", And, that's your opinion. =A0 My point in the last > e-mail was asking for clarification on your statement. =A0You didn't > really clarify it, instead, you chose to make another statement. > > So, lets break it down, point by point. > > "I don't at all feel compelled to have to provide some lengthy > exegesis on why this is true about every single one of the types of > software you indicate although I could write pages" > > Good, because this is really off topic. > > I don't feel compelled to have to provide some lengthy exegesis on how > hacker culture and crime have nothing to do with open source > development.. =A0 since it's an obvious red herring. > > According to w3schools.com, FireFox currently has 45.5% of the browser > market share. =A0 =A0It's obviously meeting the expectations of /some/ > users. (Ref: http://www.w3schools.com/browsers/browsers_stats.asp ) > > Additionally, the bug that you reported is just one of several hundred > bugs found relating to 'save password'. =A0Some of them ask to redesign > the save password dialog, some of them say, "Save password prompt is > gone; no passwords could be saved in preferences ", which contradicts > what you suggested is happening. > > On the firefox bugtracker, I didn't see the specific bug you > mentioned, however, I did see lots of bugs (Ref: > https://bugzilla.mozilla.org/buglist.cgi?query_format=3Dspecific&order=3D= relevance+desc&bug_status=3D__open__&product=3DFirefox&content=3Dsave+passw= ord > ) > > On the Internet Explorer 8 bugtracker (microsoft doesn't have a public > bugtracker for non-beta versions) , I also see a lot of bugs ( Ref: > https://connect.microsoft.com/IE/feedback/SearchResults.aspx?FeedbackOver= viewType=3D6 > ) > > There's pages and blog posts that contain gripes about firefox: (ex: > http://boonyew.com/interaction/2008/12/01/usability-gripes-with-firefoxs-= download-feature/ > ) > > There's pages and blog posts that contain gripes about Internet > Explorer: ( ex: http://www.pcmag.com/article2/0,2817,2156566,00.asp ) > > As far as 'security' goes... =A0 Steve Gibson ( hosts the Security Now > Podcast and computer security researcher ref: > http://en.wikipedia.org/wiki/Steve_Gibson_(computer_programmer) ) uses > FireFox with the NoScript and clickhijack addon because he feels it's > more secure then Internet Explorer. (he expresses this on the Security > Now podcast. =A0Also, there are other people discussing it on: > http://forum.ie7pro.com/viewtopic.php?id=3D99 ). =A0Often, Steve is > criticized for 'security over usability'. > > We each choose our own poison when it comes to browsers as well as > software in general. =A0Some of us prefer IE, some of us prefer FireFox, > some of us prefer Safari. > It really is a big deal, however, that January's browser statistics > say FX(firefox)'s market share is 45.5% and if you add up the three > versions of IE represented on that table, and you get 44.8%. =A0 Just > because more people have chosen to use firefox in the month of > January, doesn't necessarily mean that open source software is better. > =A0It just means that more people have chosen to use firefox in January. > (for the record, this e-mail was written in the gmail web interface > with Internet Explorer) > > Sincerely > > Daniel Olivares > > > > > > > On Fri, Feb 27, 2009 at 10:03 PM, dyerbrookme@juno.com > wrote: >> From: Dan Olivares >> Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163 >> >> I stand by my statement about opensouce being non-user-friendly, and ult= imately about closed societies of coders who aren't accountable to the gene= ral public and sometimes operate outside of restraints of liberal democracy= in ways that are often destructive (promoting hacker culture and crime). >> >> I don't at all feel compelled to have to provide some lengthy exegesis o= n why this is true about every single one of the types of software you indi= cate although I could write pages. A really good example is Firefox, which = harasses you constantly asking you if you want to save your password foreve= r or for this session or never, based on the misguided concept that people = just love the idea of all those options constantly shoved at them with only= an opt-out, that they just are dying to have the option to always save the= ir log-ons -- although of course, that creates security problems especially= on multi-user computers which are *most* computers. It's the sort of hilar= ious "solution" that came about because of people complaining in both direc= tions and opensourcery then providing all these choices and add-ons. >> >> To get rid of it, all you have to do (which you can't "just know" until = you finally find it) is go to tools/options/security/uncheck remember passw= ord (but it keeps falling out and needs redoing after each update). If you = google this issue, you will see many frustrated people, and many geeks offe= ring hilarious and contorted ways to get rid of it. But...if you have check= ed off a box saying "remember passwords" why can't it just do that, and not= keep offering you choices each time? It's an example of the wonky non-usef= ulness of geekitude that the average person simply finds stupid and annoyin= g but can't escape.Firefox constantly hangs and stalls, it constantly crash= es and has to remember itself. Yet we're all frog-marched into using it or = told we're not cool and starving little babies or something if we use IE. >> >> >> ____________________________________________________________ >> Put your loved ones in good hands with quality senior assisted living. C= lick now! >> http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTJkoM1onFG7s0PvKMwppvx= ViHUBQ9bpM2Tunrdy0gf6BiD5x1Cr7q/ >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > From jwatte@gmail.com Fri Feb 27 22:36:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6E33A6AD0 for ; Fri, 27 Feb 2009 22:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFKMweAo-LpZ for ; Fri, 27 Feb 2009 22:36:49 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.232]) by core3.amsl.com (Postfix) with ESMTP id 8710E3A6A5F for ; Fri, 27 Feb 2009 22:36:49 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1338283rvb.49 for ; Fri, 27 Feb 2009 22:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ypYcNuYh34wI0744ICzer8Sj4yYNenP+QKZRMKdNyxc=; b=HZRhuIsiE6NF6bN1YShuCWiJ88C/JU3urc+PF53M2JSUUDBdLAfFIx1ru3VbSVpi2s 9x6P62mm0sKSfhnjTiok80rlpmkN3ZQ3p1aUviHM0zGPruHufGZKzgAqOEP9WIZ/yIhJ MRgXHIWisMNgec7IhtK8F5CKDzwttbym5CIJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=O6CY3nRWGTCxIiNtLE8CYeCB95DGxPC/iU+XC62ouYugBo0444jm2FM2kaHiEjut92 EZRBrRq3f32VZFwQuTQyFW2a9Bs8jlh9/FxKi88MuCJbwCgcaig08gNOJVqooj+nPxgR jqR6ChON+8RSUiys+6ByvsDde08UsMod6fCFQ= Received: by 10.141.122.1 with SMTP id z1mr1632717rvm.49.1235803032932; Fri, 27 Feb 2009 22:37:12 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b39sm4243103rvf.9.2009.02.27.22.37.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 22:37:12 -0800 (PST) Message-ID: <49A8DB97.4000005@gmail.com> Date: Fri, 27 Feb 2009 22:37:11 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Charles Krinke References: <5f303cb80902251309p48e4bc3p7496abdc7ac699a4@mail.gmail.com> <53cd6c2e0902270323y7516dbd2kf8780822edecf96e@mail.gmail.com> <49A7DC37.1050002@cox.net> <49A80BE4.7000206@cox.net> <49A85DC9.2020501@gmail.com> <63FAD4F222230A4EA79DE9E8BE6647350578302F@winxbeus19.exchange.xchg> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] Chartering for requirements only X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 06:36:50 -0000 Charles Krinke wrote: > One of the things I am concerned about is minimizing the changes to > those server and client interfaces to encourage the greatest > interoperability between the similar and "vendor neutral" sim servers > and clients as we move forward in trying to define some semblance of > "interop" Is it your assertion that a client, or server, that interoperates based on the Second Life protocol, and are largely based on the open sourced SL client, or the reverse-engineered protocol library, is "vendor neutral"? If that is the case, I would have to respectfully disagree with your use of the term. Sincerely, jw From jwatte@gmail.com Fri Feb 27 22:48:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEEB23A67E9 for ; Fri, 27 Feb 2009 22:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4luGlPU1lv0g for ; Fri, 27 Feb 2009 22:48:18 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id AEB6C3A659B for ; Fri, 27 Feb 2009 22:48:18 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1341770rvb.49 for ; Fri, 27 Feb 2009 22:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pcDlTeJRY/uUiD8gi6CheYJYteM38MIg90vegJ2aRCk=; b=T/tiiETYuHQEblt2ML3kEdZRmrsKbsd+EYF/t/c4zevNk3ixEVFB00KVQN2yFV4+mC Q+XWzdkL9zjapnH33FZ32ari6Wd3xdkg7+uGihUwR3ZBtmO+GrBdJqr5jNYwwQXYqvaa YgeGcJbictm+f8ycXPuuAazSQ8ppTJNycVxE4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=R8tDHnvCNevWrZv3EpgKfnJ5kHejYUCB7sVF2GKwSNrQ7Mc+ia13NRaOyPKFTDn9dg XpcwAe1H65kfx6tQUnbytr/NhRV5FWV2GXXP9Y0UGh4V/5DWYCymSVRIpGT/x+2BJqdm 6JbudXXhadTtov5//ByFL+sSzH4iy9+sMtRsc= Received: by 10.141.20.6 with SMTP id x6mr1630417rvi.159.1235803721243; Fri, 27 Feb 2009 22:48:41 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id g22sm3965851rvb.0.2009.02.27.22.48.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 22:48:40 -0800 (PST) Message-ID: <49A8DE47.2030104@gmail.com> Date: Fri, 27 Feb 2009 22:48:39 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: "mmox@ietf.org" References: <20090227.202720.10068.1@webmail03.vgs.untd.com> In-Reply-To: <20090227.202720.10068.1@webmail03.vgs.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [mmox] mmox Digest, Vol 1, Issue 171 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 06:48:20 -0000 dyerbrookme@juno.com wrote: > However, I didn't understand your list of use cases as "uses". They see= med to me like "function cases". I realize there may be some very narrow = technical understanding of what a "use case" is. But when you listed them= , I couldn't see their actual *purpose* with an agent, an action, and an = outcome -- a use. > > =20 I actually think I'm pretty clear in what the use is in each case. Quoting from the use case page (http://www.interopworld.org/mmox-use-case= s): Use case "Friend invite": "User A wants user B to visit him/her in system/world A" This means that the use of interoperability is that user A gets a visit=20 from user B who uses a different world -- it's a social interaction.=20 Presumably, user A values the interaction with user B. Use case "Collborative Training": "company A and city B agree to connect their worlds for a defined=20 duration to conduct a training excercise" This means that the use of interoperability is that two different=20 organizations can collborate for a defined benefit (training in a=20 geo-specific locale) that could not be done without interoperability.=20 The value is the increase in readiness and disaster preparedness. Use case "Scene Transfer": "user decides to donate that prototype to an organization that uses=20 virtual world system B" This means that the use of interoperability is that development work=20 done in one world is re-used in another world, assuming permissions=20 allow it. The value of this use is increased leverage of work, and the=20 converse lowered cost of the output of work. Use case "Analysis": "The product from ISV A can be connected to any virtual world " This means that the use of interoperability is that software can be=20 developed and re-used on many worlds. The value is the increased=20 leverage of work, and the converse lowered cost of the output of work. Use case "Data Logger" "the data logger tool can be seen as a separate "virtual world peer"=20 and connected to by any virtual world " The use case here is that I can present data recorded from one virtual=20 world to any virtual work user, regardless of platform. The value is the = ability to analyze virtual world interactions post-facto, as well as=20 preserve historical records. For the definition of "leverage of work," "social interaction," "value"=20 etc, I defer to classical economics, online dictionaries, general=20 education etc. Sincerely, jw > For example, you talked about the *functionality* of being able to come= into a world and track an avatar's movements. But what is this *use*? Wh= at is is *for*? Is it for enabling a state's military or intelligence ser= vices to gain access to multiple virtual worlds easily and track people's= behaviour, with an aim to preventing terrorism, let's say? Or it is for = someone to decide where the hot spots are on their grid to lay out the tr= affic better and make sure avatars don't face obstacles in their travels = or whatever. In other words, the enabling an entity to track avatars acro= ss multiple worlds is a function, not a use because the purpose isn't exp= licit. > > By the same token, the man who ports the scene into another man's world= to show him. He could be a pirate sucking the content out of a world wit= h original content and showing it to others to sell, or he could be makin= g the blueprint of a hospital emergency room and showing it to doctors on= another platform in another country for their input. That is, functional= ity has different uses -- you could call usage stripped of content and me= aning a "use case" but it's worth being explicit, because if the basic re= ason we're all getting together here to interoperate and merge world capa= cities is for governments to make it easier to engage in surveillance whe= re people increasingly spend their time, why are we making that easier as= a technical proposition without some due process and democratic delibera= tion about why that might need some check gates on it? Or the same with t= he pirating. Why make a system that endlessly ports back and forth "scene= s" (which are artwork and content, after al > l) and sucks all the content out of worlds where people produce origin= al work, and merely hand it over to others to sell in other worlds -- aga= in, with no technical check gate. > > Prokofy Neva > > ____________________________________________________________ > Solve paternity questions with expert DNA testing. Click now! > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTKPABlBom8isv5wEaJAKV= GuY1dMnsVKDHHj7Zt3gQlldPvRJMXhss/ > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > =20 From morgaine.dinova@googlemail.com Sat Feb 28 00:33:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359C53A691E for ; Sat, 28 Feb 2009 00:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ41vUJrcqVF for ; Sat, 28 Feb 2009 00:33:42 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 191493A6893 for ; Sat, 28 Feb 2009 00:33:41 -0800 (PST) Received: by bwz26 with SMTP id 26so1327937bwz.37 for ; Sat, 28 Feb 2009 00:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WNqONHywLaDEqZwr6PmmA/UGxduXK3wlSLcQts2rjD4=; b=uKpAa/zGlyrl1RlO3a/8o1UBUUaBRlXzUhY1du9g9F6Ab8Xnqm+llLFZkw2vpYyVFt bWWJW1u9I1PQA2Sio1uk49rDGg5P+nx0Z2BkjsqUhCpwfxN05CP6sPLDVEZduQ3zVMtJ LFJSpmxZkuPFJFxxt/EJ66pdJbnVFV2yVBJjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wlgDcG/qsDqFdcCrpTdGh3cQIsYdYhhZPrZlYFKHKNPa7zdTgQC38w8KvvZa0o0Gpt HysEU7/8XtseYSLO6FN532HK4Sy2d/vykiPXXD4c1iVSS6RU48b3SItiMUEpcVOV48Q2 iVW2MpZ32+LT8R9JLSJ2xxUVDcLK9UT4UVbTo= MIME-Version: 1.0 Received: by 10.181.240.10 with SMTP id s10mr1207568bkr.62.1235810044680; Sat, 28 Feb 2009 00:34:04 -0800 (PST) In-Reply-To: References: Date: Sat, 28 Feb 2009 08:34:04 +0000 Message-ID: From: Morgaine To: Dan Olivares Content-Type: multipart/alternative; boundary=001636c5a826b9191c0463f67229 Cc: mmox@ietf.org Subject: Re: [mmox] Which Target Audience X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 08:33:45 -0000 --001636c5a826b9191c0463f67229 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 28, 2009 at 5:43 AM, Dan Olivares wrote: > So, > > As far as the draft charter and deliverables go.. it doesn't sound > like we've expressed a definate target audience for them. > Dan, it's a good idea to define the target audience as you suggest, for completeness. By default though, the target audience for the final deliverables is inevitably the same one as for pretty much every other IETF protocol standard and workgroup: everyone who is interested in the design, implementation, deployment and use of the protocols. It's a very broad target audience. It's worth noting that while the target audience is broad, the level of detail in IETF standards is of course that required for successful unambiguous implementation of a protocol, and hence the specifications are necessarily technical in nature. Broad audience does not imply "dumbing down". The target audience for the charter is rather narrower than that of the deliverables, since a central purpose of a charter is to provide a helpful framework for cooperation between the people in the workgroup. I find that this Internet draft gives remarkably good insights into our initial target audiences within the process of IETF protocol standardization, namely during BoF and WG formation time: http://tools.ietf.org/html/draft-narten-successful-bof-04 . Morgaine. On Sat, Feb 28, 2009 at 5:43 AM, Dan Olivares wrote: > So, > > As far as the draft charter and deliverables go.. it doesn't sound > like we've expressed a definate target audience for them. As, I've > stated in previous correspondance, target audience makes a big > difference when it comes to writing documents. (for example, we would > highlight use cases more for businesses and features and flexibility > for application developers) By looking at the documents, it /appears/ > as if it's for the application developer, however, some finite clarity > would be good. Multiple audiences is fine so long as we can isolate > which we are writing the standard for. Ideally, we should have the > target audience in mind in everything we write and directly printed on > the charter and in the text of each deliverable. > > A few potential target audiences: > > 1. Application Developer > 2. Virtual World Integrator > 3. Middleware Developer > 4. End User > 5. Companies > 6. IETF??? > 7. Media?? > > Best Regards > > Daniel Olivares > > > > On Fri, Feb 27, 2009 at 11:36 PM, Dan Olivares > wrote: > > "I stand by my statement about opensouce being non-user-friendly, and > > ultimately about closed societies of coders who aren't accountable to > > the general public and sometimes operate outside of restraints of > > liberal democracy in ways that are often destructive (promoting hacker > > culture and crime).", And, that's your opinion. My point in the last > > e-mail was asking for clarification on your statement. You didn't > > really clarify it, instead, you chose to make another statement. > > > > So, lets break it down, point by point. > > > > "I don't at all feel compelled to have to provide some lengthy > > exegesis on why this is true about every single one of the types of > > software you indicate although I could write pages" > > > > Good, because this is really off topic. > > > > I don't feel compelled to have to provide some lengthy exegesis on how > > hacker culture and crime have nothing to do with open source > > development.. since it's an obvious red herring. > > > > According to w3schools.com, FireFox currently has 45.5% of the browser > > market share. It's obviously meeting the expectations of /some/ > > users. (Ref: http://www.w3schools.com/browsers/browsers_stats.asp ) > > > > Additionally, the bug that you reported is just one of several hundred > > bugs found relating to 'save password'. Some of them ask to redesign > > the save password dialog, some of them say, "Save password prompt is > > gone; no passwords could be saved in preferences ", which contradicts > > what you suggested is happening. > > > > On the firefox bugtracker, I didn't see the specific bug you > > mentioned, however, I did see lots of bugs (Ref: > > > https://bugzilla.mozilla.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Firefox&content=save+password > > ) > > > > On the Internet Explorer 8 bugtracker (microsoft doesn't have a public > > bugtracker for non-beta versions) , I also see a lot of bugs ( Ref: > > > https://connect.microsoft.com/IE/feedback/SearchResults.aspx?FeedbackOverviewType=6 > > ) > > > > There's pages and blog posts that contain gripes about firefox: (ex: > > > http://boonyew.com/interaction/2008/12/01/usability-gripes-with-firefoxs-download-feature/ > > ) > > > > There's pages and blog posts that contain gripes about Internet > > Explorer: ( ex: http://www.pcmag.com/article2/0,2817,2156566,00.asp ) > > > > As far as 'security' goes... Steve Gibson ( hosts the Security Now > > Podcast and computer security researcher ref: > > http://en.wikipedia.org/wiki/Steve_Gibson_(computer_programmer)) uses > > FireFox with the NoScript and clickhijack addon because he feels it's > > more secure then Internet Explorer. (he expresses this on the Security > > Now podcast. Also, there are other people discussing it on: > > http://forum.ie7pro.com/viewtopic.php?id=99 ). Often, Steve is > > criticized for 'security over usability'. > > > > We each choose our own poison when it comes to browsers as well as > > software in general. Some of us prefer IE, some of us prefer FireFox, > > some of us prefer Safari. > > It really is a big deal, however, that January's browser statistics > > say FX(firefox)'s market share is 45.5% and if you add up the three > > versions of IE represented on that table, and you get 44.8%. Just > > because more people have chosen to use firefox in the month of > > January, doesn't necessarily mean that open source software is better. > > It just means that more people have chosen to use firefox in January. > > (for the record, this e-mail was written in the gmail web interface > > with Internet Explorer) > > > > Sincerely > > > > Daniel Olivares > > > > > > > > > > > > > > On Fri, Feb 27, 2009 at 10:03 PM, dyerbrookme@juno.com > > wrote: > >> From: Dan Olivares > >> Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163 > >> > >> I stand by my statement about opensouce being non-user-friendly, and > ultimately about closed societies of coders who aren't accountable to the > general public and sometimes operate outside of restraints of liberal > democracy in ways that are often destructive (promoting hacker culture and > crime). > >> > >> I don't at all feel compelled to have to provide some lengthy exegesis > on why this is true about every single one of the types of software you > indicate although I could write pages. A really good example is Firefox, > which harasses you constantly asking you if you want to save your password > forever or for this session or never, based on the misguided concept that > people just love the idea of all those options constantly shoved at them > with only an opt-out, that they just are dying to have the option to always > save their log-ons -- although of course, that creates security problems > especially on multi-user computers which are *most* computers. It's the sort > of hilarious "solution" that came about because of people complaining in > both directions and opensourcery then providing all these choices and > add-ons. > >> > >> To get rid of it, all you have to do (which you can't "just know" until > you finally find it) is go to tools/options/security/uncheck remember > password (but it keeps falling out and needs redoing after each update). If > you google this issue, you will see many frustrated people, and many geeks > offering hilarious and contorted ways to get rid of it. But...if you have > checked off a box saying "remember passwords" why can't it just do that, and > not keep offering you choices each time? It's an example of the wonky > non-usefulness of geekitude that the average person simply finds stupid and > annoying but can't escape.Firefox constantly hangs and stalls, it constantly > crashes and has to remember itself. Yet we're all frog-marched into using it > or told we're not cool and starving little babies or something if we use IE. > >> > >> > >> ____________________________________________________________ > >> Put your loved ones in good hands with quality senior assisted living. > Click now! > >> > http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTJkoM1onFG7s0PvKMwppvxViHUBQ9bpM2Tunrdy0gf6BiD5x1Cr7q/ > >> _______________________________________________ > >> mmox mailing list > >> mmox@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmox > >> > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --001636c5a826b9191c0463f67229 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 28, 2009 at 5:43 AM, Dan Olivares <dcolivares@gmai= l.com> wrote:
So,

As far as the draft charter and deliverables go.. =A0 =A0it doesn't sou= nd
like we've expressed a definate target audience for them.


Dan, it's a good idea to define the target a= udience as you suggest, for completeness.=A0 By default though, the target = audience for the final deliverables is inevitably the same one as for prett= y much every other IETF protocol standard and workgroup:=A0 everyone who is= interested in the design, implementation, deployment and use of the protoc= ols.=A0 It's a very broad target audience.

It's worth noting that while the target audience is broad, the leve= l of detail in IETF standards is of course that required for successful una= mbiguous implementation of a protocol, and hence the specifications are nec= essarily technical in nature.=A0 Broad audience does not imply "dumbin= g down".

The target audience for the charter is rather narrower than that of the= deliverables, since a central purpose of a charter is to provide a helpful= framework for cooperation between the people in the workgroup.

I find that this Internet draft gives remarkably good insights into our ini= tial target audiences within the process of IETF protocol standardization, = namely during BoF and WG formation time:=A0 http://tools.ietf.org/html/draft-nar= ten-successful-bof-04 .


Morgaine.








On Sat, Feb 28, 2009 at 5:43 AM, Dan Olivares <dcolivares@gmail.com> w= rote:
So,

As far as the draft charter and deliverables go.. =A0 =A0it doesn't sou= nd
like we've expressed a definate target audience for them. =A0As, I'= ve
stated in previous correspondance, target audience makes a big
difference when it comes to writing documents. =A0(for example, we would highlight use cases more for businesses and features and flexibility
for application developers) =A0By looking at the documents, it /appears/ as if it's for the application developer, however, some finite clarity<= br> would be good. =A0Multiple audiences is fine so long as we can isolate
which we are writing the standard for. =A0Ideally, we should have the
target audience in mind in everything we write and directly printed on
the charter and in the text of each deliverable.

A few potential target audiences:

1. Application Developer
2. Virtual World Integrator
3. Middleware Developer
4. End User
5. Companies
6. IETF???
7. Media??

Best Regards

Daniel Olivares



On Fri, Feb 27, 2009 at 11:36 PM, Dan Olivares <dcolivares@gmail.com> wrote:
> "I stand by my statement about opensouce being non-user-friendly,= and
> ultimately about closed societies of coders who aren't accountable= to
> the general public and sometimes operate outside of restraints of
> liberal democracy in ways that are often destructive (promoting hacker=
> culture and crime).", And, that's your opinion. =A0 My point = in the last
> e-mail was asking for clarification on your statement. =A0You didn'= ;t
> really clarify it, instead, you chose to make another statement.
>
> So, lets break it down, point by point.
>
> "I don't at all feel compelled to have to provide some length= y
> exegesis on why this is true about every single one of the types of > software you indicate although I could write pages"
>
> Good, because this is really off topic.
>
> I don't feel compelled to have to provide some lengthy exegesis on= how
> hacker culture and crime have nothing to do with open source
> development.. =A0 since it's an obvious red herring.
>
> According to w3scho= ols.com, FireFox currently has 45.5% of the browser
> market share. =A0 =A0It's obviously meeting the expectations of /s= ome/
> users. (Ref: http://www.w3schools.com/browsers/browsers_stats.= asp )
>
> Additionally, the bug that you reported is just one of several hundred=
> bugs found relating to 'save password'. =A0Some of them ask to= redesign
> the save password dialog, some of them say, "Save password prompt= is
> gone; no passwords could be saved in preferences ", which contrad= icts
> what you suggested is happening.
>
> On the firefox bugtracker, I didn't see the specific bug you
> mentioned, however, I did see lots of bugs (Ref:
> https://bugzilla.mozil= la.org/buglist.cgi?query_format=3Dspecific&order=3Drelevance+desc&b= ug_status=3D__open__&product=3DFirefox&content=3Dsave+password<= br> > )
>
> On the Internet Explorer 8 bugtracker (microsoft doesn't have a pu= blic
> bugtracker for non-beta versions) , I also see a lot of bugs ( Ref: > https://connect.microsoft.com= /IE/feedback/SearchResults.aspx?FeedbackOverviewType=3D6
> )
>
> There's pages and blog posts that contain gripes about firefox: (e= x:
> http://boonyew.com/inter= action/2008/12/01/usability-gripes-with-firefoxs-download-feature/
> )
>
> There's pages and blog posts that contain gripes about Internet > Explorer: ( ex: http://www.pcmag.com/article2/0,2817,2156566,00= .asp )
>
> As far as 'security' goes... =A0 Steve Gibson ( hosts the Secu= rity Now
> Podcast and computer security researcher ref:
> http://en.wikipedia.org/wiki/Steve_Gibson_(comp= uter_programmer) ) uses
> FireFox with the NoScript and clickhijack addon because he feels it= 9;s
> more secure then Internet Explorer. (he expresses this on the Security=
> Now podcast. =A0Also, there are other people discussing it on:
> http://forum.ie7pro.com/viewtopic.php?id=3D99 ). =A0Often, Steve = is
> criticized for 'security over usability'.
>
> We each choose our own poison when it comes to browsers as well as
> software in general. =A0Some of us prefer IE, some of us prefer FireFo= x,
> some of us prefer Safari.
> It really is a big deal, however, that January's browser statistic= s
> say FX(firefox)'s market share is 45.5% and if you add up the thre= e
> versions of IE represented on that table, and you get 44.8%. =A0 Just<= br> > because more people have chosen to use firefox in the month of
> January, doesn't necessarily mean that open source software is bet= ter.
> =A0It just means that more people have chosen to use firefox in Januar= y.
> (for the record, this e-mail was written in the gmail web interface > with Internet Explorer)
>
> Sincerely
>
> Daniel Olivares
>
>
>
>
>
>
> On Fri, Feb 27, 2009 at 10:03 PM, dyerbrookme@juno.com
> <dyerbrookme@juno.com&g= t; wrote:
>> From: Dan Olivares <dco= livares@gmail.com>
>> Subject: Re: [mmox] mmox Digest, Vol 1, Issue 163
>>
>> I stand by my statement about opensouce being non-user-friendly, a= nd ultimately about closed societies of coders who aren't accountable t= o the general public and sometimes operate outside of restraints of liberal= democracy in ways that are often destructive (promoting hacker culture and= crime).
>>
>> I don't at all feel compelled to have to provide some lengthy = exegesis on why this is true about every single one of the types of softwar= e you indicate although I could write pages. A really good example is Firef= ox, which harasses you constantly asking you if you want to save your passw= ord forever or for this session or never, based on the misguided concept th= at people just love the idea of all those options constantly shoved at them= with only an opt-out, that they just are dying to have the option to alway= s save their log-ons -- although of course, that creates security problems = especially on multi-user computers which are *most* computers. It's the= sort of hilarious "solution" that came about because of people c= omplaining in both directions and opensourcery then providing all these cho= ices and add-ons.
>>
>> To get rid of it, all you have to do (which you can't "ju= st know" until you finally find it) is go to tools/options/security/un= check remember password (but it keeps falling out and needs redoing after e= ach update). If you google this issue, you will see many frustrated people,= and many geeks offering hilarious and contorted ways to get rid of it. But= ...if you have checked off a box saying "remember passwords" why = can't it just do that, and not keep offering you choices each time? It&= #39;s an example of the wonky non-usefulness of geekitude that the average = person simply finds stupid and annoying but can't escape.Firefox consta= ntly hangs and stalls, it constantly crashes and has to remember itself. Ye= t we're all frog-marched into using it or told we're not cool and s= tarving little babies or something if we use IE.
>>
>>
>> ____________________________________________________________
>> Put your loved ones in good hands with quality senior assisted liv= ing. Click now!
>> http:/= /thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTJkoM1onFG7s0PvKMwppvxViHUBQ9bp= M2Tunrdy0gf6BiD5x1Cr7q/
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
>>
>
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--001636c5a826b9191c0463f67229-- From tommi.s.e.laukkanen@gmail.com Sat Feb 28 00:34:11 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193723A68F3 for ; Sat, 28 Feb 2009 00:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id balCPEg28cWH for ; Sat, 28 Feb 2009 00:34:09 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 8C77D3A6893 for ; Sat, 28 Feb 2009 00:34:08 -0800 (PST) Received: by fxm24 with SMTP id 24so1362987fxm.37 for ; Sat, 28 Feb 2009 00:34:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=fTkWK1FHPkcyeC/oEhaCzBUL3oemv4Vp+SZDOwoRu2s=; b=brgXfln/w6Oao/shy3lpEJHjEmH+riPhVh+uoIIkZ5TEWtkYFh+RfMwiDUHSJU7MRM oCirEy9SYII5Ha7szfkX6m0kCIqEtyHYWjBfEzky+kbuuG7i5IFUjtZjmumH4DViz50Q eLrJTZyVLiT4gqZuRR3293xpAmITBa3x5vIBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=SSK4Sy92rvsQjEqieQJ67J1ldaQh+uQc48aeymPjZLtOioB48k2sJDPaYhjrFBAXDi rGc1Om1d2nXJXqMnHOFENt93YeH8tLOoMjQR5MCZ3jVuXygRc8+huhQUxmWx/QloemNJ mRupjm62ZMJKjFt0JEnxR67eQ21Oia1dp69t4= MIME-Version: 1.0 Received: by 10.181.208.8 with SMTP id k8mr1207809bkq.128.1235810069725; Sat, 28 Feb 2009 00:34:29 -0800 (PST) Date: Sat, 28 Feb 2009 10:34:29 +0200 Message-ID: From: Tommi Laukkanen To: mmox@ietf.org Content-Type: multipart/alternative; boundary=001636c5a48437436c0463f674cb Subject: [mmox] Google Protocol Buffers as MXP extension mechanism X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 08:34:11 -0000 --001636c5a48437436c0463f674cb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit We have applied Hurlimans Google protocol buffers suggestion succesfully in MXP OpenSimulator adoption effort. XML was switched to Google Protocol Buffers to gain easier data manipulation and in wire efficiency. You can read about MXP extension mechanism here: http://www.bubblecloud.org/msd The open simulator specific Google Protocol Buffers schema can be viewed here: http://www.bubblecloud.org/msd/-/wiki/mxml/Open%20Metaverse The work is in process and but the general idea can be easily seen. After using this approach I can report that it is very much practical engineering solution without immediate shortcomings. My opinion is now that XML is suitable for HTTP related messaging due to lower performance requirements but for real time state synchronisation I recommend binary encoding on all layers according to the idea of Google Protocol Buffers. Google Protocol Buffers generated message specific value objects are convenient to use compared to for example DOM tree. The binary encoding / decoding of GPB beats in performance SAX/DOM parsers. I find Stefan Anderssons vision of encoding world content with different parametrisation schemes to MXP extensions very intriguing. For example objects could be parametrised the way SL does primitives or they could contain reference to 3d mesh which can be downloaded from asset server. As stefan argued to me the other day all these different schemes are needed and will continue to exist. The situation is analogous to web with many kind of image formats counting in both bitmap and vector image types. best regards, Tommi Laukkanen --001636c5a48437436c0463f674cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We have applied Hurlimans Google protocol buffers suggestion succesful= ly in MXP OpenSimulator adoption effort.=A0XML was switched to Google Proto= col Buffers to gain easier=A0data=A0manipulation and in wire efficiency.=A0= You can read about MXP extension mechanism here:
=A0
=A0
The open simulator specific Google Protocol Buffers schema can be view= ed here:
=A0
=A0
The work is in process and but the general idea can be easily seen.
=A0
After using this approach I can report that it is very much practical = engineering solution without immediate shortcomings. My opinion is now that= XML is suitable for HTTP related messaging due to lower performance requir= ements but for real time state synchronisation I recommend binary encoding = on all layers according to the idea of Google Protocol Buffers. Google Prot= ocol Buffers generated message specific value objects are convenient to use= compared to for example DOM tree. The binary encoding / decoding of GPB be= ats in performance SAX/DOM parsers.
=A0
I find Stefan Anderssons vision of encoding world content with differe= nt parametrisation schemes to MXP extensions very intriguing. For example o= bjects could be parametrised the way SL does primitives or they could conta= in reference to 3d mesh which can be downloaded from asset server. As stefa= n argued to me the other day all these different schemes are needed and wil= l continue to exist. The situation is analogous to web with many kind of im= age formats counting in both bitmap and vector image types.
=A0
best regards,
Tommi Laukkanen
--001636c5a48437436c0463f674cb-- From morgaine.dinova@googlemail.com Sat Feb 28 02:53:39 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5126F3A6961 for ; Sat, 28 Feb 2009 02:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LATAJtQL2i-t for ; Sat, 28 Feb 2009 02:53:37 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 4B34A3A680C for ; Sat, 28 Feb 2009 02:53:37 -0800 (PST) Received: by bwz26 with SMTP id 26so1354296bwz.37 for ; Sat, 28 Feb 2009 02:53:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VNBoc944cepscZh8CQdzkMGvvGYnSA2zTtETVi1Hh9I=; b=N8JA4xfMf1RtLm9nbM8+e+xgatiKVatmQLOobfQwY0kDTruy2aDMfqHJz6YGipxQPe Sg1e5uzLgvU9eFeHudCJqXgGfmuAe3Rurs9KmvSuE5rGwrVpZHTRcORoLxdQZR2XBaO7 GIeblrulI0eP/z3KF95ZQUhjFdGGXI+AV07dI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GCz6F9UghKCB4jsLQ0NV18wRCvU0UnRZ8vutS8dIizhGJn8dnPduVsABUPNRPYOcFx RPyOw64hBiDmTcvi1UWziIz0tInoWk35iZLGiBdqiOG2ddQ+5Tlrnmv/4BziGTfzP8oq +vVnabaKhOBXvzTkqL4kBCfljJd0EBuxC3AA8= MIME-Version: 1.0 Received: by 10.181.154.16 with SMTP id g16mr1241841bko.179.1235818437420; Sat, 28 Feb 2009 02:53:57 -0800 (PST) In-Reply-To: References: Date: Sat, 28 Feb 2009 10:53:57 +0000 Message-ID: From: Morgaine To: Tommi Laukkanen Content-Type: multipart/alternative; boundary=0016e6d64531f825790463f8664a Cc: mmox@ietf.org Subject: Re: [mmox] Google Protocol Buffers as MXP extension mechanism X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 10:53:39 -0000 --0016e6d64531f825790463f8664a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tommi, the practical engineer in me supports your perspective on this completely. Whatever higher levels of abstraction are used to make the design, management and evolution of a system more effective, at runtime the controlling metric is efficiency (correctness being an implicit requirement and not a metric). The measure of our success or failure will be whether we can reconcile the requirements at the highest and lowest levels of our work while still being helpful to very diverse worlds. I think that we can, because I see that LLSD with its separation of IDL, ADT and serializations has taken a good stab at it already. Improving on the model of LLSD is what we've already started to discuss here, and I think we're making very effective progress. Your work in Opensim provides a sterling example of a viable direction for us to take. I would be very interested to hear how the upper levels of your scheme work, to avoid world programming being coupled to chosen serialization. Morgaine. On Sat, Feb 28, 2009 at 8:34 AM, Tommi Laukkanen < tommi.s.e.laukkanen@gmail.com> wrote: > We have applied Hurlimans Google protocol buffers suggestion succesfully in > MXP OpenSimulator adoption effort. XML was switched to Google Protocol > Buffers to gain easier data manipulation and in wire efficiency. You can > read about MXP extension mechanism here: > > http://www.bubblecloud.org/msd > > The open simulator specific Google Protocol Buffers schema can be viewed > here: > > http://www.bubblecloud.org/msd/-/wiki/mxml/Open%20Metaverse > > The work is in process and but the general idea can be easily seen. > > After using this approach I can report that it is very much practical > engineering solution without immediate shortcomings. My opinion is now that > XML is suitable for HTTP related messaging due to lower performance > requirements but for real time state synchronisation I recommend binary > encoding on all layers according to the idea of Google Protocol Buffers. > Google Protocol Buffers generated message specific value objects are > convenient to use compared to for example DOM tree. The binary encoding / > decoding of GPB beats in performance SAX/DOM parsers. > > I find Stefan Anderssons vision of encoding world content with different > parametrisation schemes to MXP extensions very intriguing. For example > objects could be parametrised the way SL does primitives or they could > contain reference to 3d mesh which can be downloaded from asset server. As > stefan argued to me the other day all these different schemes are needed and > will continue to exist. The situation is analogous to web with many kind of > image formats counting in both bitmap and vector image types. > > best regards, > Tommi Laukkanen > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > --0016e6d64531f825790463f8664a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tommi, the practical engineer in me supports your perspective on this compl= etely.=A0 Whatever higher levels of abstraction are used to make the design= , management and evolution of a system more effective, at runtime the contr= olling metric is efficiency (correctness being an implicit requirement and = not a metric).

The measure of our success or failure will be whether we can reconcile = the requirements at the highest and lowest levels of our work while still b= eing helpful to very diverse worlds.=A0 I think that we can, because I see = that LLSD with its separation of IDL, ADT and serializations has taken a go= od stab at it already.

Improving on the model of LLSD is what we've already started to dis= cuss here, and I think we're making very effective progress. =A0 Your w= ork in Opensim provides a sterling example of a viable direction for us to = take.=A0 I would be very interested to hear how the upper levels of your sc= heme work, to avoid world programming being coupled to chosen serialization= .


Morgaine.









On Sat, Feb 28, 2009 at 8:34 AM, Tommi Laukkanen <tommi.s.e.laukkanen@g= mail.com> wrote:
We have appl= ied Hurlimans Google protocol buffers suggestion succesfully in MXP OpenSim= ulator adoption effort.=A0XML was switched to Google Protocol Buffers to ga= in easier=A0data=A0manipulation and in wire efficiency.=A0You can read abou= t MXP extension mechanism here:
=A0
=A0
The open simulator specific Google Protocol Buffers schema can be view= ed here:
=A0
=A0
The work is in process and but the general idea can be easily seen.
=A0
After using this approach I can report that it is very much practical = engineering solution without immediate shortcomings. My opinion is now that= XML is suitable for HTTP related messaging due to lower performance requir= ements but for real time state synchronisation I recommend binary encoding = on all layers according to the idea of Google Protocol Buffers. Google Prot= ocol Buffers generated message specific value objects are convenient to use= compared to for example DOM tree. The binary encoding / decoding of GPB be= ats in performance SAX/DOM parsers.
=A0
I find Stefan Anderssons vision of encoding world content with differe= nt parametrisation schemes to MXP extensions very intriguing. For example o= bjects could be parametrised the way SL does primitives or they could conta= in reference to 3d mesh which can be downloaded from asset server. As stefa= n argued to me the other day all these different schemes are needed and wil= l continue to exist. The situation is analogous to web with many kind of im= age formats counting in both bitmap and vector image types.
=A0
best regards,
Tommi Laukkanen

_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox


--0016e6d64531f825790463f8664a-- From morgaine.dinova@googlemail.com Sat Feb 28 03:42:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86D013A69E0 for ; Sat, 28 Feb 2009 03:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhzRhTv7duwQ for ; Sat, 28 Feb 2009 03:42:07 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 3898F3A69CE for ; Sat, 28 Feb 2009 03:42:07 -0800 (PST) Received: by fxm24 with SMTP id 24so1398857fxm.37 for ; Sat, 28 Feb 2009 03:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=d1QAGgkpMxqXrMlvv8L5iZNXc9pKVXeqLNvDaGBX21c=; b=ACqSw85so2DBTKIbL59olcRUjqdY6nsFyR8yGRU2LkoYjwdSmPmCPrakkQs1js7kFS Aub5pI0OV2dT92ZBhSV2jykftF4SHQL3+yYdZm8J7q2BBf7lmCg/zDif+gAvKH4B64vx M3zmRk3pljv3giT/2BurJZOvCXwPdCDpJqSsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=k58HBa0MZE02TkmxTMzJrgenl7wf7gRARvJYqXTGFSbIYgRxnuqD9y0Ge9l7/f9alS UI7uAiaeJIbTkaqVmkM7SNfUD/Q2jcxzyqMlYWkOpTuCyhRd1PTnhv71cUSHE3u853YT oN+NPaUilE3iQmv/msFUANvEMPXr8F2sW2D4A= MIME-Version: 1.0 Received: by 10.181.146.14 with SMTP id y14mr1262813bkn.70.1235821349366; Sat, 28 Feb 2009 03:42:29 -0800 (PST) Date: Sat, 28 Feb 2009 11:42:29 +0000 Message-ID: From: Morgaine To: MMOX-IETF Content-Type: multipart/alternative; boundary=001485f7909e88eb5e0463f914ba Subject: [mmox] MMOX Protocol Proposals X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 11:42:08 -0000 --001485f7909e88eb5e0463f914ba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Just a quick note to highlight that we now have three concrete proposals as input to MMOX work. In order of appearance: 1. Open Grid Protocol (OGP Draft 3), extra links here 2. MXP: a universal Metaverse eXchange Protocol 3. 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 Croquetmodels 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. --001485f7909e88eb5e0463f914ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just a quick note to highlight that we now have three concrete proposals as= input to MMOX work.=A0 In order of appearance:

  1. Open Grid Protocol (OGP D= raft 3) , extra links = here
  2. MXP: a universal= Metaverse eXchange Protocol
  3. MMOX Live Entity State Stream (LESS) Protocol<= /li>

Hopefully the Solipsis mo= del often mentioned by Jesrad will be added to this list as a concrete prop= osal 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 re= presentation 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.
--001485f7909e88eb5e0463f914ba-- From jwatte@gmail.com Sat Feb 28 11:20:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51AB3A6A6D for ; Sat, 28 Feb 2009 11:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGvW8eOjsJ4C for ; Sat, 28 Feb 2009 11:20:16 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id AE3373A6869 for ; Sat, 28 Feb 2009 11:20:16 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1535303rvb.49 for ; Sat, 28 Feb 2009 11:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=6ckH/I1LyLoiIH7gSJYRlfLBiZcOhIT9sTD8lpDOerY=; b=p3ievLlV6X7LZbSPVmkQTpVbxJZNt6Wl5f1IzJ6gnWmH+OmQrNqYb1Qk5aazvLm3S6 XFxoqQj5rS1oGfR0pkmP4B7fyyLn8989EuB0r9GTMgkgthyDyYXJx0W+A0yasj9tC6Mk pypZaM2RcTLpvwfu4T1QQ5Z/0BQdbN5d5MYBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=wDrwIi61updzjpqEt+ZMQIbN/fra5Q1DV/NtcLETjXmsGxypLSpmT/ljB4fpXCeS58 syZ2cgF7TpR/0lHt89AtcHAghrHarLFgiFN8qSOOAu7jwJPz9bIJ3Z/n/BtbEUL1rL1J QExHljzykc2KqHSqRdOSNKsK2hS8tjT7wxBIM= Received: by 10.140.201.8 with SMTP id y8mr1926818rvf.208.1235848840639; Sat, 28 Feb 2009 11:20:40 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k2sm12056202rvb.4.2009.02.28.11.20.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Feb 2009 11:20:40 -0800 (PST) Message-ID: <49A98E87.4000500@gmail.com> Date: Sat, 28 Feb 2009 11:20:39 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MMOX-IETF Subject: Re: [mmox] MMOX Protocol Proposals X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2009 19:20:17 -0000 Morgaine wrote: > Just a quick note to highlight that we now have three concrete > proposals as input to MMOX work. In order of appearance: > > 1. Open Grid Protocol (OGP Draft 3) > , extra > links here > 2. MXP: a universal Metaverse eXchange Protocol > > 3. MMOX Live Entity State Stream (LESS) Protocol > > Thanks for collecting this! I don't see how MXP is an interop protocol, though. From reading through the latest version, it seems to be building one kind of server cloud, similar to one Second Life grid, using an open and published protocol. This is no different in approach than the existing OpenSim effort. It doesn't talk at all about how different grids should interoperate. I can see no technology neutral affordances in the protocol -- the only "interop" possible seems to be through a defined 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. Perhaps Tommi can chime in with a clarification of the interop goals of MXP in this context? Sincerely, jw From morgaine.dinova@googlemail.com Sat Feb 28 17:39:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7843A6B08 for ; Sat, 28 Feb 2009 17:39:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZa+BPEJldgF for ; Sat, 28 Feb 2009 17:39:18 -0800 (PST) Received: from mail-bw0-f178.google.com (mail-bw0-f178.google.com [209.85.218.178]) by core3.amsl.com (Postfix) with ESMTP id 9B4E23A67AE for ; Sat, 28 Feb 2009 17:39:17 -0800 (PST) Received: by bwz26 with SMTP id 26so1512203bwz.37 for ; Sat, 28 Feb 2009 17:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mzute9jnuw8wIPhtiyW4ya4gcE8gsSNk5Yr8OGBQd/o=; b=J8mELnj4SUGshgYrjuEbOkPrK/TOz55jKGRl6gXLHcQVeUFVZnA5TbM+1nXLJFn+Y4 d8j+nTBhqGElipws6Au6mHZ35rfd/49rlluvJHN7R9XIt9iC9EQFpvDEy9oBzDG6T1m/ mn7ixxS+eNueTNaT8rmQgccGCpKlVeuz01s7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=k/dpQCBRcBS9juS3BWOZoD2D1qzkwiKX1cG7nZAnrok5abc53xK6NApxUNYs5ADLA9 +ryfsKzlxs7e6QsIwI7BEQ0YWGyVUA8IWD9YmMRvT3r5C7xqAOV2+cteudppOIDBkXJ+ dMYSwSnSqt9S9PI2R3FTItt+dt/+8eFGsRCks= MIME-Version: 1.0 Received: by 10.180.245.20 with SMTP id s20mr1496354bkh.184.1235871579897; Sat, 28 Feb 2009 17:39:39 -0800 (PST) In-Reply-To: <49A98E87.4000500@gmail.com> References: <49A98E87.4000500@gmail.com> Date: Sun, 1 Mar 2009 01:39:39 +0000 Message-ID: From: Morgaine To: Jon Watte Content-Type: multipart/alternative; boundary=001636c5b06581fec2046404c665 Cc: MMOX-IETF Subject: Re: [mmox] MMOX Protocol Proposals X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 01:39:19 -0000 --001636c5b06581fec2046404c665 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 28, 2009 at 7:20 PM, Jon Watte wrote: > > I don't see how MXP is an interop protocol, though. From reading through > the latest version, it seems to be building one kind of server cloud, > similar to one Second Life grid, using an open and published protocol. This > is no different in approach than the existing OpenSim effort. It doesn't > talk at all about how different grids should interoperate. I can see no > technology neutral affordances in the protocol -- the only "interop" > possible seems to be through a defined 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. > Oddly enough, I find MXP to be almost identical to OLIVE, and I see it bearing almost no relationship to Second Life at all. (I'll explain in a second.) From this plus the fact that it seems to be able to handle Opensim-to-Opensim communications despite Opensim being *originally*designed to work like SL seems to be a great testament not only to the flexibility of Opensim but also to the architecture-neutrality of MXP. 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 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. I have no doubt that both of you will disagree with my evaluation since you have the details and I don't, but that's how it looks to me from the explanations I've read. :-) 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. Morgaine. On Sat, Feb 28, 2009 at 7:20 PM, Jon Watte wrote: > Morgaine wrote: > >> Just a quick note to highlight that we now have three concrete proposals >> as input to MMOX work. In order of appearance: >> >> 1. Open Grid Protocol (OGP Draft 3) >> , extra >> links here >> 2. MXP: a universal Metaverse eXchange Protocol >> >> 3. MMOX Live Entity State Stream (LESS) Protocol >> >> >> > Thanks for collecting this! > > I don't see how MXP is an interop protocol, though. From reading through > the latest version, it seems to be building one kind of server cloud, > similar to one Second Life grid, using an open and published protocol. This > is no different in approach than the existing OpenSim effort. It doesn't > talk at all about how different grids should interoperate. I can see no > technology neutral affordances in the protocol -- the only "interop" > possible seems to be through a defined 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. > > Perhaps Tommi can chime in with a clarification of the interop goals of MXP > in this context? > > Sincerely, > > jw > > --001636c5b06581fec2046404c665 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 28, 2009 at 7:20 PM, Jon Watte <jwatte@gmail.com&g= t; wrote:

I don't see how MXP is an interop protocol, though. From reading through the latest version, it seems to be building one kind of server cloud, similar to one Second Life grid, using an open and published protocol. This is no different in approach than the existing OpenSim effort. It doesn't talk at all about how different grids should interoperate. I can see no technology neutral affordances in the protocol -- the only "interop" possible seems to be through a def= ined 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.


Oddly enough, I find MXP to be almost identical t= o OLIVE, and I see it bearing almost no relationship to Second Life at all.= =A0 (I'll explain in a second.)=A0 From this plus the fact that it seem= s to be able to handle Opensim-to-Opensim communications despite Opensim be= ing originally designed to work like SL seems to be a great testamen= t not only to the flexibility of Opensim but also to the architecture-neutr= ality of MXP.

On the similarities between MXP and OLIVE, the two architec= tures look like variations on a theme to me.=A0 In both cases every client = performs the same simulation, this being of a "shared space/room"= in OLIVE and of a "Bubble" in MXP.=A0 In both cases, the communi= cation seems to be a form of P2P, proxy-aided in the case of MXP.=A0 Both a= pproaches seem unable to simulate widely diverse world environments because= simulation is done on every client, which means that the same simulation c= ode has to exist on every client for the simulation to be accurate.=A0 This= would seem to preclude effective interop with different worlds whose simul= ation code is not divulged --- at best some rough feedback telemetry can th= en attempt to reflect something vaguely sensible to "foreign" loc= al simulations.=A0 And in neither case is there a "world-centric"= model as in SL or Opensim, since rooms and bubbles aren't really topol= ogical entities per se.

I have no doubt that both of you will disagree with my evaluation since= you have the details and I don't, but that's how it looks to me fr= om the explanations I've read. :-)

I do agree that the hard ques= tions do not appear to have been answered, but this is true for every propo= sal so far:=A0 the detailed semantics of interop remain to be defined.


Morgaine.









On Sat, Feb 28, 2009 at 7:20 PM, Jon Watte <<= a href=3D"mailto:jwatte@gmail.com">jwatte@gmail.com> wrote:
Morgaine wrote:
Just a quick note to highlight that we now have three concrete proposals as= input to MMOX work. =A0In order of appearance:

=A0 1. Open Grid Protocol (OGP Draft 3)
=A0 =A0 =A0<https://wiki.secondlife.com/wiki/OGP_LLSD_Draft_3&= gt; , extra
=A0 =A0 =A0links here <https://wiki.secondlife.com/wiki/OGP>
=A0 2. MXP: a universal Metaverse eXchange Protocol
=A0 =A0 =A0<http://www.cybertechnews.org/?p=3D499>
=A0 3. MMOX Live Entity State Stream (LESS) Protocol
=A0 =A0 =A0<http://www.interopworld.com/mmox-less-protocol>

Thanks for collecting this!

I don't see how MXP is an interop protocol, though. From reading throug= h the latest version, it seems to be building one kind of server cloud, sim= ilar to one Second Life grid, using an open and published protocol. This is= no different in approach than the existing OpenSim effort. It doesn't = talk at all about how different grids should interoperate. I can see no tec= hnology neutral affordances in the protocol -- the only "interop"= possible seems to be through a defined client/server interface. That doesn= 't solve any of the hard problems, like how to interoperate different o= bjects that are built using different execution environments within the sam= e space.

Perhaps Tommi can chime in with a clarification of the interop goals of MXP= in this context?

Sincerely,

jw


--001636c5b06581fec2046404c665-- From jwatte@gmail.com Sat Feb 28 19:24:36 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C473A68DA for ; Sat, 28 Feb 2009 19:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpWD9Z-pBpsf for ; Sat, 28 Feb 2009 19:24:35 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 07FF53A67C0 for ; Sat, 28 Feb 2009 19:24:34 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id l9so1622218rvb.49 for ; Sat, 28 Feb 2009 19:24:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=9kC75UFmhZBDjlmRzPlbCJeA5uuE8q2/vnWErt/J8N0=; b=WZfgXMsyJNGPducVvLVAp9fi0bZ4R5GnXoGIwZUH9KvOaVz7CB3FVSyk7njV8uwrJW oKHVpWw1qtqi07lSuli4n/pPGRp3Qpb6tolMI3Fk7ah3lWDkPNfBMJlrwi99uhTq0Bxs +Fjwe0SjAtarlettsgFxOAao44PHKeZ/KV2JI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KJSK3DvnxzGWmdcxW6vg2SXV193G1M3hGcqDkGa8i4KxgdeZolGHwFr+K/AEyImLHV i3kB8K4H30/khHzcK8pppeNVEPzixMn4kHVt8UXQV3FygCclhdmYVVYZ88r5/p1ALWIZ bCDKkrgVcQd7sOdlj9oAyCNo0le39jqvOJR0g= Received: by 10.140.193.15 with SMTP id q15mr2126352rvf.78.1235877899311; Sat, 28 Feb 2009 19:24:59 -0800 (PST) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id k41sm3080465rvb.6.2009.02.28.19.24.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 28 Feb 2009 19:24:59 -0800 (PST) Message-ID: <49AA0009.8070402@gmail.com> Date: Sat, 28 Feb 2009 19:24:57 -0800 From: Jon Watte User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Morgaine References: <49A98E87.4000500@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MMOX-IETF Subject: Re: [mmox] MMOX Protocol Proposals X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Mar 2009 03:24:36 -0000 Morgaine wrote: > On Sat, Feb 28, 2009 at 7:20 PM, Jon Watte > 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